Talk:Corner detection

message: Does anyone know of references to corner detection:
a) Corner detector for a binary image
b) Corner detection using chain codes or thinning/convex hull  —Preceding unsigned comment added by 98.199.213.54 (talk) 04:33, 2 August 2008 (UTC)
thread_title:  Binary corner detectors / Chain Codes 

message: I have created an infobox for all pages related to corner/edge/blob/feature/interest point detection: User:Keeganmann/Corner Detection Navagation.  I think it would help with navigation.
Should I add it and is it a good idea?
Keeganmann (talk) 00:46, 17 February 2008 (UTC)
thread_title:  Possible Infobox 

message: Did some minor editing here and there, but most importantly squared the trace term in the expressions for M_c to make them consistent with the literature. --KYN 13:22, 6 May 2006 (UTC)
thread_title:  Recent changes 

message: I suggest that the article is moved to the heading "Interest point".  The reason is that it is generally accepted that all the methods which is described here detect general interest points rather than corners specifically.  There is no reason why Wikipedia must add to this confusion by presenting these methods under the heading "Corner detection".  Also, the heading "Interest point" is more general than "Interest point detection" and can include apects of interest points other than detection, e.g., tracking or other applications which use the detected points.  --KYN 18:04, 31 August 2006 (UTC)
thread_title:  Requested move 

message: In the computer vision literature, there are several blob detectors, for example the scale normalized Laplacian, the scale-normalized determinant of the Hessian as well as a hybrid operator "Hessian-Laplace" which uses the determinant of the Hessian for spatial selection and the scale-normalized Laplacian for scale selection. The appropriate section to put these operators would be under the heading "blob detection" which is referred to from the page "scale-space". This page has, however, not been written yet. 
If the current page on "corner detection" is moved to "interest point", then the scope of the article would have to be extended substantially from the current scope based on the Harris operator. Tpl 13:47, 2 September 2006 (UTC)
replies: text: That is my intention.  This article started with only the Harris operator, but given its current content is seems more appropriate to present a discussion about what interest points are (there is something on this already) and how they are used.  In particular, a new heading can cover different ways of extracting the image coordinate (x,y) for an interest point.  Also, the difference between point and blob can be discussed.  The aspect of transformation from image gray values (typically) to a set of image coordinates should be discussed.  For example, if we only threshold the response from Harris, we get a blob of pixels.  If we instead try to estimate the local maxima we get a pixel coordinate, perhaps even with sub-pixel accuracy if certain measures have been taken.  Non-max suppression should also be mentioned.  Then there can also be a list of detection methods, more or less like in the current article.  Alternatively, there could be one (shorter) article for each specific method and only links from the new page.  --KYN 17:23, 2 September 2006 (UTC)

text: Note that some of the now mentioned methods have applications in different areas.  For example, the Tomasi-Kanade or Shi-Tomasi stuff was originally used for stereo image registration, but has also been used for tracking a region in an image sequence, and can of course also be used for finding interest points in one single image.  From that perspective, it could make sense to develop each individual method on a page of their own, describing various details and their applications.  There can also be survey articles, like "interest point" which describes the concept from a general point of view, presents a list of methods which can be used, and refer the reader to the page of each specific method for the details.  --KYN 17:23, 2 September 2006 (UTC)
thread_title:  There are other interest point operators than those who can be referred to as corner detectors 

message: I don't want to contaminate the article with my views before discussion has taken place on this.
With the typical implementation of the Affine adapted interest points, especially Harris-affine points, the resulting detector is not affine invariant. This is because a search through affine space (unlike scale space) is too expensive.
Any successfully detected points are invariant to affine transformations, in that the affine ellipse which can be drawn around them will more or less cover the same part of the image even after affine transformations. However, the implementation relies on multiscale feature detection, followed by iterative affine adaption. The normal Harris detector is not particularly invariant (or repeatable) under affine transformations of the image. Since this is the first step, it puts an upper bound on the `affine invariantness' of the overall algorithm. That is, under affine transformations, many points will not be detected repeatably. Serviscope Minor 15:51, 5 September 2006 (UTC)
thread_title:  Affine invariance (or not) 

message: Do you think it's reasonable on a page like this to have some external links to implementations? 
Here's my thoughts, since I'm not in the business of endorsing anyone's code in particular.
Some detectors have sample implementations by the authors, eg SUSAN, DoG (in SIFT), Harris-Laplace. These take precedence, since they may have details not exactly present in the paper and all results _should_ be reproducable with these implementations.
Other detectors (eg Harris, Shi-Tomasi) have very stable implementations in certain libraries, eg intel OpenCV and these libraries are sufficiently widely used that they're not going to be disappearing anytime soon.
If you concur that this section is reasonable, then I'll start adding links, noting whether they are they authors' sample implementations or not.
Serviscope Minor 16:56, 8 September 2006 (UTC)
thread_title:  Implementation 

message: I marked this article some time ago for moving its title to something like "interest point".  Given that there now is an article also on "blob detection", I would like to bring some order to the overall presentation.  Here is my proposals:
* Parts of the content of this article (Corner detection) is moved to new article "Interest point" which is intended to give a general introduction to this topic, describe applications for interest points and also provide a list of methods for detecting interest points.  This list would probably include most of those which now are found in the "Corner detection" article.  My proposal is that they are presented at a general level, technical details are not presented in this list of methods.
* The technical details of each of the interest point detection methods are put into separate articles, one article per method.
* The relation between "blobs" and "interest points" needs to be sorted out.  Personally, I don't know if they should be kept separate or if they should be presented in the same article.  Any ideas?  Either way, the distinctions or similarities need to be discussed.
* I also propose that the current article "Blob detection" is renamed to "Blob (computer vision)".  Detection is only one aspect of blobs which should be discussed in that article.  Applications and general rationale for why we should worry about blobs are other aspects which also should be presented.  Detection of blobs should rather be a section in that article.
--KYN 20:50, 14 September 2006 (UTC)
thread_title:  Move, etc 

message: I summarize the discussion so far as follows:
* Regarding moving a larger part of this article to a new name "Interest point", I havn't seen any major objections.  I will make this move within short, unless someone can provide a good reason not to.  The motivation for the move is that, even if the corresponding methods classically are referred to as "corner detectors", this label not correct since they also detect other types of "interest points".  This realization is also reflected in some of the recent literature.  However, I don't know if all of the recently added methods in the "Corner detection" article can be referred to as methods for interest points detection or if they should go into blob detection.  
* The issue of moving the more technical content of the various methods into separate articles appears not to be approved at this stage.  I may advocate for this strategy later on. 
* About the relation between interest points and blobs, this needs to be explained in the corresponding articles.  Right now, the "Corner detection" (soon to be "Interest point") article does provide some intuitive and conceptual definition of an interest point.  I would like to see a similar presentation of a "blob" in the "Blob detection" article.  This should hopefully shed some light on the difference between the two concepts.
* The question of renaming the "Blob detection" is related to the proposed extension (see previous point) of that article.  However, I remove this issue from the discussion on this talk page and move it to the "Blob detection" Talk page.
My contribution to this discussion are as follows:
* A (interest) point can only be characterized in terms of a position or image coordinate, possibly together with the specific feature on which the detection method is based.  A blob, on the other hand, consist in general of a region, i.e., a set of points.  This set may be small, in some cases even consisting of a single point.  This observation implies that a blob detection method must provide a set of points as output rather than a single point, which is what we get from an interest point detector.  This is the difference between the two concepts.
* The resulting point set from a blob detector can often be condensed into a single point, e.g., by computing its center of gravity (mean).  This is then a type of interest point.  Also, in some cases we can get an interest point by finding local maximum/minimum of the corresponding "feature strength" function that is used for blob detection.  Here we have some relations between the two concepts.
* About an overview article on features, this is a good idea, but please note the existing article Feature (Computer vision).  That article could benefit from additional work. 
--KYN 21:49, 17 September 2006 (UTC)
thread_title:  Summary and more arguments 

message: Well, I have a major objection against moving this article to "interest point". Moreover, I do not agree on the distinction between interest points and blob detectors that you present. If you define "interest point" as a point in the image domain, which has a clear (mathematical and operational) definition and can be robustly detected (which I think is a good definition both in terms of usefulness and the interest point operators that exist today), then each one of the five blob detectors defined in the article on blob detection also satisfy the requirement of an "interest point operator". From this viewpoint, I would find it better to have an overview article on interest point detectors which then refers to the two articles on corner detection and blob detection concerning specific approaches. The overview article could also describe why these features are used at all, for which there are many similarities between corner detectors and blob detectors. A main distinction I see between a corner detector and a blob detector, is if you look at these concepts from viewpoint of CAD-like object models, which are to be tracked over time and/or recognized in complex scenes. If one aims at using the physical corners of the CAD-model as features, then only a corner detector will satisfy the relevant requirements, since a corner detector will respond to the physical corners while a blob detector will respond to the object as a whole or parts of the object. Another main distinction is in terms of structure from motion. If one wants to compute point-correspondences over time or in a stereo pair, then the expected better localization of corner features may be an advantage in many situations. Nonwithstanding this, blob features can also be used for tracking and recognition, although the localization may not always be as precise. Tpl 12:49, 18 September 2006 (UTC)
thread_title:  Objections ... 

message: In an attempt to clarify how I think that the notion of interest points should be defined, I have written an outline of an article on interest point detection that includes criteria that an interest point should satisfy as well as how this notion relates to previous notions of corner detectors, blob detectors and regions of interest. I do not claim that this article (which has been written up rather fast) is an ultimate solution. My opinion is however that it makes it easier to have an informed discussion. Intentionally, I chose a different name for the article than for the suggestion for a move. My personal suggestion is that it would be better to rename the new article interest point detection to interest point than the current article on corner detection.  Tpl 14:42, 18 September 2006 (UTC)
thread_title:  Differences and similarities between interest points, corners and blobs 

message: Think that the new interest point detection better describes general features in general (it would be more complete with the addition of edges). I think interest point refers to point like features as opposed to blobs, ridges or regions of interest.
Serviscope Minor 17:29, 18 September 2006 (UTC)
thread_title:  Feature vs. Interest point 

message: In this article, the Hessian matrix and the Autocorrelation matrix (=Harris matrix) are
mixed up: In section "The Harris & Stephens / Plessey corner detection algorithm", the matrix A
is denoted as Hessian. However, it is writen  I_x^2 (square of the first derivative)
and not I_xx (second derivative). 129.143.13.82 17:42, 4 June 2007 (UTC)
thread_title:  Hessian or Autocorrelation matrix? 

message: How to decide the threshhold of the harris corner detector? if the intensity of image is within 0~255,the threshhold of cornerness measure is about 1500,then we can get enough corners.However,if the grayvalue of the  image is below 60,the same threshhold cannot get the corner. what is the relation between threshhold and image intensity range? Can we determine the threshhold automatically?
Thank you?Aaron.me (talk) 14:55, 22 November 2008 (UTC)
thread_title:  how to decide the threshhold of the Harris corner detector 

message: I would like to re-examine KYN's suggestion that the detection algorithms be broken off into their own separate articles.  The current list of detectors is incomplete.  While I am not suggesting that it should be complete, I believe it is reasonable to assume that it may still grow as research in this field continues.  As it stands, the article reads like a list of these detectors.
Some of the detector sections, like Shi and Tomasi, could use expansion.  However, the Harris & Stephens detector section looks large enough that it might warrant its own article.  I don't have the technical knowledge to do this, and I'm new to Wikipedia, but keeping a survey of the detectors and their approach while including links to those where significant information is available seems like a good approach.  Just as a possible example, the section on the Wang and Brady corner detection algorithm looks like a good balance between being concise and giving a feel for the detector.
Looking through the article, I'm confused by the order that the algorithms are given.  Is it chronological?  I think a brief explanation would be helpful.  If not chronological, some of the detectors look like they follow more from others, such as the Affine-adapted interest point operator coming after the Harris operators.  I'm going to take the liberty to change the order in this case.
:It is chronological in the sense that  they're roughly in the order that they were added. How about a grouping like local SSD methods (Moravec, Harris, Forstner), local dericative methods (LoG, DoG, DoH, Wang&Brady), direct pixel methods (SUSAN, Trejkivoc& Hedley, FAST) and learned detectors. Perhaps a chronology at the beginning would be useful too. It also seems to be missing entirely the edge based techniques, like curvature scale space and much earlier techniques. Serviscope Minor (talk) 19:42, 19 October 2010 (UTC)
replies: text: >>The reason why the affine-adapted interest point operators follow a bit later in the article, is because affine shape adaptation can be combined with several types of interest point detectors, such as the Laplacian and the determinant of the Hessian (examples can be found e.q. encyclopedia article by Lindeberg (2008). Tpl (talk) 15:53, 21 October 2010 (UTC)

text: >>There were more references before, that however seem to have been lost in edits by others. Tpl (talk) 15:55, 21 October 2010 (UTC)

text: >>>Some went missing during my edits. Also some seemed to be irrelevant (e.g. 3 nearly identical citations for the same thing), and some I couldn't match to anywhere in the article.Serviscope Minor (talk) 19:39, 25 October 2010 (UTC)

text: I've fixed up the citations into a proper reference list. Some may have gone missing, but some were not all that relevant.Serviscope Minor (talk) 19:42, 19 October 2010 (UTC)

text: Good point. However, it runs the risk of becoming a list of almost every corner detector ever. What kind of criteria should we use to filter them?Serviscope Minor (talk) 19:42, 19 October 2010 (UTC)
thread_title:  Proposals for further changes 

message: I've gone through the article and cleaned up the references. If you are going to add references, I request that you do the following:
* Do not use author-year citations. The current style of the article is just numeric ones, and mixing styles looks ugly. I actually don't mind what kind of citations are used as long as they are consistent. So if anyone feels very strongly and wants to change the entire article in one go, I won't object.
* Do not hand format references. All references are currently automatically formated (see entries in the references section). If you hand-format references, they have inconsistent styles and make the reference list look ugly. Als
* Define references in the references section at the end not inline. This makes it easier to manage the references which is important as the reference list is getting quite big.
Serviscope Minor (talk) 23:46, 2 December 2010 (UTC)
thread_title:  Use of references 

message: One of the recent changes seems to be the AGAST corner detector. The article seems interesting, but I do not think it is (yet?) suitable for inclusion in an this article. It is currently a brand new technique, is completely unproven and has garnered no citations whatsoever. The majority of other references have generally hundreds to thousands of citations, making them well known established techniques. The main exception is the GP based corner detector. I think it is worth keeping it as it is probably the best known / most cited article in the relatively new topic of mechanically generated corner detectors. I don't think FAST and AGAST count in that category as they're more along the lines of using coding theory to make a human-designed corner detector run fast. If no one objects, I'm going to prune this reference.
Also on a different note, two of the "Lindeberg" references seem to have very similar titles (detection for one and tracking for the other). Given that the article is about detection not tracking, the tracking reference seems rather peripherally related. I don't know that particular work well, so can anyone else here comment?
Serviscope Minor (talk) 23:48, 2 December 2010 (UTC)
replies: text: Additionally, optimal, binary decision trees are computed instead of a greedy, ternary tree. Hence, AGAST outperforms FAST and comes with no drawbacks. However, the computation of the optimal decision tree is expensive and for large r an approximation using a greedy algorithm, such as ID3, is inevitable.
I don't see how the tree can be optimal as it claims almost straight away that they have to use an approximate (i.e. not optimal) algorithm. I think the optimal tree for the 20 questions problem is NP-hard. This claim seems to simply mirror the paper. I had a look at the paper, and it does not shed any light on the matter.
Serviscope Minor (talk) 00:00, 3 December 2010 (UTC)

text: >> AGAST always builds optimal trees. Of course the computation of such trees is computationally complicated, but it is feasible even for the mask used in FAST. You only get into trouble if r is too large (because of the problem's complexity as you noted) - but, large masks do not preserve the locality constraint and should be avoided. There is no approximation used to build the AGAST tree. However, I agree that AGAST is brand-new and it is probably worth waiting and watching its impact before adding it to the article. Oel mi (talk) 12:49, 8 December 2010 (UTC)

text: The Bretzner and Lindeberg article on feature tracking shows the good stability of the corner features under scale changes, which may not be as easy to grasp from the Lindeberg 1998 article or the book from 1994. The tracking article also shows how scale information from the scale-adaptive corner detector can be used in an advantageous manner when matching such corner features between different images. Tpl (talk) 16:43, 2 December 2010 (UTC)
replies: text:  Fair enough. I'll leave it in.Serviscope Minor (talk) 23:48, 2 December 2010 (UTC)
thread_title:  Proliferation of techniques and references 

message: There's the following line in the article: 
:In practice, most so-called corner detection methods detect interest points in general, rather than corners in particular.[citation needed] 
As far as I can tell, corner detectors started as methods to detect corners on curves. Naturally because they are a low-level thing, they have always been incapable of detecting corners of objects. But the name stuck and so things like Harris (and everything else in the article) get labelled as corner detectors. I believe that "corner" is a bit of a red herring. However, can anyone here think of a citation to back this up? I'm drawing a bit of a blank.
Serviscope Minor (talk) 00:09, 3 December 2010 (UTC)
thread_title: Citation needed

message: Hello fellow Wikipedians,
I have just modified one external link on Corner detection. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20110717210134/http://cienciascomp.cicese.mx/evovision/olague_EC_MIT.pdf to http://cienciascomp.cicese.mx/evovision/olague_EC_MIT.pdf
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 21:08, 18 September 2017 (UTC)
thread_title:  External links modified