vips_colourspace error upon calling vips_hough_line

[ewelot]

I'd like to learn about hough transformation and use vips_hough_line() for that. The goal is to use vips functionality to identify (and remove) satellite trails in astrophotography images which gets increasingly annoying due to StarLink and similar missions.
But any call to hough_line() on a grayscale image fails, e.g.:

vips hough_line satellites.pgm hough_votes.pgm

throws an error message

vips_colourspace: no known route from 'matrix' to 'b-w'

Do I need to prepare the input image in a specific way?
Thanks for help,
Thomas

[jcupitt]

Hi @ewelot,

You need to use a format that supports int32 pixels, so perhaps:

$ vips hough_line mono.jpg x.v
$ vips hough_line mono.jpg x.pfm
$ vips hough_line mono.jpg x.tif
$ vips hough_line mono.jpg x.csv
$ vips hough_line mono.jpg x.mat

nip2 can be handy for exploring the hough transforms:

[ewelot]

Ah, it's some restriction on the output image format! So, maybe you could add a note on that to the documentation ... :)
Thanks for providing the solution so quickly!

[ewelot]

I'm having problems to understand the output of vips_hough_line(). While it works fine with my images and produces expected number of peaks clearly in the "votes" image, I am not able to translate the peak coordinates to a function representing the line(s), although the API documentation is quite clear on that matter.

Could you please describe an example on how to translate peak coordinates to a linear function equation (or simply r and alpha) taking into account the size of the parameter space and the size of the input image?

Another strange observation - at least to my current knowledge - comes from another experiment. Lets have an image A containing a straight line resulting in a single peak in the votes image at Xa,Ya. Then I remove some columns on the right side of A producing an image B which now has a somewhat smaller width. It should still contain the line unmodified, which means both the distance to the origin of the image (upper left corner) and the angle between line and x-axis have not changed. Surprisingly the peak in the votes image of B is off in both coordintes (Xb != Xa, Yb != Ya). What am I missing?

[jcupitt]

Here's a workspace that demos hough_line:

http://www.rollthepotato.net/~john/hough.ws

It looks like this:

So it draws a line, takes the Hough transform, then recovers the line position from the transform. You can adjust the parameters and see all the images change.

[ewelot]

Thank you very much, I'll play with it (good opportunity to learn nip2 ...) and see how I can recover the line parameters.

[ewelot]

Sorry for re-opening this issue ...
I'am stll having problems to correctly recover line parameters from peak coordinates in the parameter space. Even in your workspace demo there seems to be odd results. Here is what I did:

• modify input image line angle to 60
• verify recovered line parameters being close to the input
• modify image width to 400 (which does not make any change to the line)
• find recovered line parameters to be off by unexpected amount

Are you sure the workspace is using the correct formulae to recover the line parameters?

[jcupitt]

You're right, it seems to work for non-square parameter space, but not for a non-square input image. I'll have a look.