![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
I find the current introductory definition, "a feature is a piece of information which is relevant for solving the computational task related to a certain application", to be far too broad and vague. This definition covers more or less any piece of information on any topic in any context. For example, the big O complexity of the computational task of sorting a database table is "a piece of information which is relevant for solving the computational task related to a certain application" , but it is obviously not a feature for the purposes of this article.
In my view the introductory definition should contain the following aspects: 1) the term 'feature' (as intended in this article) relates to images and analogous data structures, 2) the term relates to the content of an image, as opposed to meta-data, 3) a feature is typically (though certainly not always) either present or absent, and 4) a feature is typically (though not always) local.
Accordingly I propose to change the introductory definition to: "a feature is a piece of information about the content of an image, typically about whether a certain region of the image has certain properties". This seems to cover the content of the article quite well. However, I don't consider myself to be expert enough in this field to make the change myself. Could anyone else weigh in? Wikiedit738 ( talk) 09:54, 12 August 2020 (UTC)
From my viewpoint this article is too abstract. Although I count myself as an expert in the field, I have problems to find the article informative. From my viewpoint, the article appears to give a very specific and narrow viewpoint to the notion of features. Moreover, the reference list is too unbalanced. Tpl 12:26, 18 September 2006 (UTC)
I think that this article has become much better after the rewrite. To make it easier to search for this article in the Wikipedia search tool, and to have a better analogy with the companion articles on edge detection, corner detection, blob detection and ridge detection, one suggestion would be to rename this article to feature detection. Then, however, a redirect would have to be changed to the article on feature extraction. (I do not know how to do that.) From my viewpoint, it would be OK to remove the expert tag from this article. Tpl 15:13, 19 September 2006 (UTC)
Still, however, since the article in its current form describes precisely the notion of "feature detection", I think that a corresponding naming would be appropriate.
I do, however, not agree on dropping "detection" for the articles on "edge detection", "corner detection", "blob detection" and "ridge detection". The use of "detection" is well established in the field. Tpl 15:48, 20 September 2006 (UTC)
Concering feature hierarchies I agree that descriptors of different complexity can be constructed by using multiple concepts together. To say that feature hierarchies are well-established in the field, however, I have not been able to find any extensive support for. Tpl 17:27, 21 September 2006 (UTC)
Another aspect that needs to be discussed is the distinction between feature detection and feature extraction or feature estimation. I my view, detection implies a classification process: either the feature is there or not. A feature detector gives you the answer yes or no. Some features however, a more complex and call for a more sophisticated representation than a boolean variable. For example, line/edge features can be described in terms of their orientation, phase and certainty of presence. This information can conveniently be encoded into a matrix or tensor such as the structure tensor. Personally, I would not refer to the process of computing such a description as "detection", but rather as "estimation" or possibly as "extraction". On the other hand, if we use a Canny approach, we get a boolean statement in each pixel about edge presence, hence "detection" is appropriate.
I would suggest removing this page. feature_detection and feature_extraction already exist, and I think that spreading features over three pages is excessive and introduces artificial distinctions. I'm also not convinced that feature detectors are binary. Some of the most common (eg Harris, DoG) are real-valued and are binarized only by thresholding at some point. Others, eg FAST have a threshold built in and are definitely binary. Also, with Harris, the computation of the second moment matrix is required, so the extraction of this comes for free. As such, I think that the extraction of information about the local feature can not be completely separated from the detection process since in some cases they are so closely linked. Another example is edge orientation. This comes "for free" as part of the Canny edge detector, since it has to be computed anyway in order to perform nonmaximal suppression. Therefore this information is already and freely available as part of the detection process. While "estimation" may be a better term, in detection is more commonly understood term. I think it sould be kept.
I think that it would be better to describe feature map in terms of feature detection. I think detection is more natural and obvious as a first step (as well as being an early topic in many CV books). Feature maps are a quite natural generalization and are computed using exactly the same techniques (modulo a threshold).
Serviscope Minor 17:01, 20 September 2006 (UTC)
Suggestion to a compromise: How about developing the notion of feature maps in a separate article to begin with? Then, when it has matured and reached the standards of the feature detection articles, we could try to merge the contents if we find that appropriate. With such a solution we avoid starting the process by messing up articles that today are in quite a reasonable shape. Tpl 17:59, 20 September 2006 (UTC)
As I see it, the outline of this article is as it is now very much focused towards representations like the double angle. Correct? Tpl 18:26, 25 September 2006 (UTC)
![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
I find the current introductory definition, "a feature is a piece of information which is relevant for solving the computational task related to a certain application", to be far too broad and vague. This definition covers more or less any piece of information on any topic in any context. For example, the big O complexity of the computational task of sorting a database table is "a piece of information which is relevant for solving the computational task related to a certain application" , but it is obviously not a feature for the purposes of this article.
In my view the introductory definition should contain the following aspects: 1) the term 'feature' (as intended in this article) relates to images and analogous data structures, 2) the term relates to the content of an image, as opposed to meta-data, 3) a feature is typically (though certainly not always) either present or absent, and 4) a feature is typically (though not always) local.
Accordingly I propose to change the introductory definition to: "a feature is a piece of information about the content of an image, typically about whether a certain region of the image has certain properties". This seems to cover the content of the article quite well. However, I don't consider myself to be expert enough in this field to make the change myself. Could anyone else weigh in? Wikiedit738 ( talk) 09:54, 12 August 2020 (UTC)
From my viewpoint this article is too abstract. Although I count myself as an expert in the field, I have problems to find the article informative. From my viewpoint, the article appears to give a very specific and narrow viewpoint to the notion of features. Moreover, the reference list is too unbalanced. Tpl 12:26, 18 September 2006 (UTC)
I think that this article has become much better after the rewrite. To make it easier to search for this article in the Wikipedia search tool, and to have a better analogy with the companion articles on edge detection, corner detection, blob detection and ridge detection, one suggestion would be to rename this article to feature detection. Then, however, a redirect would have to be changed to the article on feature extraction. (I do not know how to do that.) From my viewpoint, it would be OK to remove the expert tag from this article. Tpl 15:13, 19 September 2006 (UTC)
Still, however, since the article in its current form describes precisely the notion of "feature detection", I think that a corresponding naming would be appropriate.
I do, however, not agree on dropping "detection" for the articles on "edge detection", "corner detection", "blob detection" and "ridge detection". The use of "detection" is well established in the field. Tpl 15:48, 20 September 2006 (UTC)
Concering feature hierarchies I agree that descriptors of different complexity can be constructed by using multiple concepts together. To say that feature hierarchies are well-established in the field, however, I have not been able to find any extensive support for. Tpl 17:27, 21 September 2006 (UTC)
Another aspect that needs to be discussed is the distinction between feature detection and feature extraction or feature estimation. I my view, detection implies a classification process: either the feature is there or not. A feature detector gives you the answer yes or no. Some features however, a more complex and call for a more sophisticated representation than a boolean variable. For example, line/edge features can be described in terms of their orientation, phase and certainty of presence. This information can conveniently be encoded into a matrix or tensor such as the structure tensor. Personally, I would not refer to the process of computing such a description as "detection", but rather as "estimation" or possibly as "extraction". On the other hand, if we use a Canny approach, we get a boolean statement in each pixel about edge presence, hence "detection" is appropriate.
I would suggest removing this page. feature_detection and feature_extraction already exist, and I think that spreading features over three pages is excessive and introduces artificial distinctions. I'm also not convinced that feature detectors are binary. Some of the most common (eg Harris, DoG) are real-valued and are binarized only by thresholding at some point. Others, eg FAST have a threshold built in and are definitely binary. Also, with Harris, the computation of the second moment matrix is required, so the extraction of this comes for free. As such, I think that the extraction of information about the local feature can not be completely separated from the detection process since in some cases they are so closely linked. Another example is edge orientation. This comes "for free" as part of the Canny edge detector, since it has to be computed anyway in order to perform nonmaximal suppression. Therefore this information is already and freely available as part of the detection process. While "estimation" may be a better term, in detection is more commonly understood term. I think it sould be kept.
I think that it would be better to describe feature map in terms of feature detection. I think detection is more natural and obvious as a first step (as well as being an early topic in many CV books). Feature maps are a quite natural generalization and are computed using exactly the same techniques (modulo a threshold).
Serviscope Minor 17:01, 20 September 2006 (UTC)
Suggestion to a compromise: How about developing the notion of feature maps in a separate article to begin with? Then, when it has matured and reached the standards of the feature detection articles, we could try to merge the contents if we find that appropriate. With such a solution we avoid starting the process by messing up articles that today are in quite a reasonable shape. Tpl 17:59, 20 September 2006 (UTC)
As I see it, the outline of this article is as it is now very much focused towards representations like the double angle. Correct? Tpl 18:26, 25 September 2006 (UTC)