Anonymous user
Talk:Hough transform: Difference between revisions
→Scaling?
| (18 intermediate revisions by 6 users not shown) | |||
Line 55:
:::::::::: Is the TCL implementation correct in the first place? I've tested my MATLAB code against other test inputs like the one given on the wikipedia page for the hough transform and my output was correct in those cases. But, the output from my MATLAB code and the TCL code disagree for the pentagon. --[[User:Cferri|Chris Ferri]]
::::::::::: Based on your output image alone, I can see that your MATLAB code iterates a half-circle and has both negative and positive rho. The TCL implementation (mistakenly) iterates two full circles (only one is needed), and only positive rho. The output image is a plot of theta on the X and rho on the Y, with the top-left corner being 0,0. Obviously your implementation's output wouldn't match the TCL implementation. Does that mean that the TCL is wrong? Or is the MATLAB wrong? Or are they different ways of doing the same basic thing, with correspondingly different outputs? --[[User:Coderjoe|Coderjoe]] 01:17, 10 August 2010 (UTC)
:::::::::::: Hm. Well, it's a sinusoidal function, so I think it means the Tcl output image is only twice as wide as necessary. It'd be like mapping sin(theta) from zero to 4pi, instead of -pi to pi. You're correct in that that makes it incompatible as a comparison without including theta range and pixel mapping details in the task description. In this case, I think that falls somewhere akin to specifying input/output file formats. It doesn't change the core logic, but it does change interpretation of the thing. --[[User:Short Circuit|Michael Mol]] 01:29, 10 August 2010 (UTC)
:::::::::::: Except the TCL output image isn't twice as wide. The TCL output is only 360 wide, and as far as I can tell, the extra 360 pixels added to "row" are discarded by tkimg. --[[User:Coderjoe|Coderjoe]] 01:33, 10 August 2010 (UTC)
::::::::::::: My problem with the TCL code is not how it outputs the image or what ever...it's the algorithm it uses to "tally the votes." The MATLAB code iterates through each of the original image pixels and bins all of the sinusoids for "edge" pixels (aka the votes). From what I can tell the TCL implementation iterates over each of the pixels in the hough space to construct the transform. But, I can not for the life of me figure out how the original image pixels cast votes for rho and theta values in the hough space in the algorithm implemented by the TCL code. --[[User:Cferri|Chris Ferri]]
:::::::::::: The Tcl code uses the ranges ''ρ''∈[0…''R'' ] and ''θ''∈[0…2''π'' ] (where ''R'' is a “radius” that is “sufficiently large”). It also uses an origin in the middle of the image. Saying that the ranges should instead be [−''R''…''R'' ] and [−''π''…''π'' ] respectively is just nit-picking, as is picking any other origin. All it does is change the offsets of (and possibly cyclically rotate, due to the sinusoidal repetition) the output. –[[User:Dkf|Donal Fellows]] 08:54, 10 August 2010 (UTC)
::::::::::::: The TCL code, as written, actually runs ''θ''∈[0…4''π'' ), and I had a question about that below. (720/180 = 4) --[[User:Coderjoe|Coderjoe]] 09:11, 10 August 2010 (UTC)
:::::::::::::: Actually, it runs to 2''π''; it's proceeding by ''half'' degrees. If it was going twice round, it would have double the number of spots in the generated image. –[[User:Dkf|Donal Fellows]] 14:03, 12 August 2010 (UTC)
:::::::::::::: I was wrong. I just had a bug that was being hidden by the fact that I'd configured the size of the image first. Oops! :-) –[[User:Dkf|Donal Fellows]] 14:19, 12 August 2010 (UTC)
::::::::::::: I'd like to point out this paragraph from the page describing how to add a new programing task. [[Help:Adding_a_new_programming_task]] "The criteria you set should not be so tight as to be language-specific. After all, that defeats the founding point of Rosetta Code. However, the criteria should not be so vague as to have multiple interpretations. Removing code from the wiki would be the tragic result. Situations where the appropriateness of a programming example hinges on the interpretation of the tasks' criteria should be avoided as much as possible." [[User:Cferri|Chris Ferri]] 03:20, 12 August 2010 (UTC)
:::::::::::::: I wrote that. I've also learned a lot about creating tasks since then--to the point where I haven't tried doing it myself in a long time. I'll see about refining that later. --[[User:Short Circuit|Michael Mol]] 13:05, 12 August 2010 (UTC)
===Scaling?===
: The above pseudo-code has: <lang>and y axis is rho from -sqrt(width^2+height^2) to sqrt(width^2+height^2) in pixels.</lang> But is width and height the width and height of the png (like the J and Matlab implementations)? Or is it the width and height of the contained geometry (like the C and TCL implementations)? Or am I mis-interpreting those images? --[[User:Rdm|Rdm]] 12:50, 16 September 2010 (UTC)
::Those are the width and height in pixels of the image that is being transformed[[User:Cferri|Chris Ferri]] 18:33, 16 September 2010 (UTC)
==PNG Image==
Line 78 ⟶ 100:
: Being a type of transform, I suppose I'd try to use it as part of image fingerprinting. Just a rough idea, one could run the transform, find the median value M, max everything there and above M, drop everything below M, find center points and store their relative positions. (I'd probably go back and adjust M until I had a certain fixed number of center points, or as close to it as possible.) --[[User:Short Circuit|Michael Mol]] 18:22, 19 May 2010 (UTC)
I must be missing something. Is there a reason the tcl implementation (the only one at this time) is looping theta through two complete circles? --[[User:Coderjoe|Coderjoe]] 17:04, 22 July 2010 (UTC)
:Because it had a dumb bug. A think-o. –[[User:Dkf|Donal Fellows]] 14:20, 12 August 2010 (UTC)
== Semantic MediaWiki ==
▲I'm going to use this task as a guinea pig for the new Semantic MediaWiki features. --[[User:Short Circuit|Michael Mol]] 10:07, 27 July 2010 (UTC)
| |||