im_maxpos_avg can fail

[jcupitt]

See https://github.com/jcupitt/libvips/issues/245 ... some images can trigger the message:

 (vips:50975): GLib-GObject-WARNING **: value "nan" of type 'gdouble' is invalid or out of range for property 'out' of type 'gdouble'
avg: parameter out not set

[jcupitt]

Dropbox link to image: https://www.dropbox.com/s/t074pl8ccphohd9/COR-241-top-left.tif?dl=0

If I look at the image in nip2 I can see pixel (0,0) is NaN (not a number, the ieee float value for error).

Operations like max are NaN-avoiding: they interpret NaN as a 'hole' in the image and ignore it:

$ vips max COR-241-top-left.tif 
0.998478

im_maxpos_avg() is older code written by Tom and is missing the NaN avoiding stuff. I'll see if I can add it without too much pain.

I suppose the NaN is somehow being generated by spcor. Do you have some sample images which trigger this?

[jcupitt]

I've added NaN-avoiding to im_maxpos_avg():

jcupitt@09b81b7

I now see:

$ vips im_maxpos_avg COR-241-top-left.tif 
21
32
0.998478

It would be good to find out where the NaNs are coming from too.

[PaulHowson]

John,

In the following dropbox folder are the two images which are fed into spcor to produce COR-241-top-left.tif. They are ANAL-241-top-left.tif and REF-241-top-left.tif

https://www.dropbox.com/sh/9ywn5n79ostbh34/AACVOGb2cM4CWy94PP_GGoDha?dl=0

Paul

[jcupitt]

Hi again, I think git master should work better now. vips_spcor() could divide by zero in some cases ... it outputs a 0 now (ie. uncorrelated) instead.

I'll do the vips-8 release and include this fix.

[PaulHowson]

Hi John,

I seem to have helped find and flush out one more bug.

A couple of questions if I may:

When im_maxpos_avg was crashing, I resorted to using the Ruby vips function, i.maxpos(n), where n is the number of maxima to be returned in an array.

This didn't crash.

I requested 9 maxima (n = 9) and then averaged the x and y values. This produced accurate results on tests correlating two symmetrical images (an offset black dot created in Photoshop). In other words, the detected offsets were the same as I had manually created in Photoshop.

For non-symmetrical cases, the detected offset was in error by a fraction of a pixel. I presume this is because the maxima in the correlated image were no longer symmetrically arranged around the highest correlation point.

Can you explain how im.maxpos(n) works? Does it return the n highest value pixels in the image? Are they sorted in order of descending values? i.e. is the first pixel in the array the highest value pixel in the image?

I have noticed that the pixels in these correlation images
close to the "peak" might look the same in Photoshop, but they can have fractionally different (floating point) values.

Regarding the (now fixed) im_maxpos_avg, what exactly does it average? The source documentation says:

"Function to find the maximum of an image. Returns coords and value at double precision. In the event of a draw, returns average of all drawing coords."

Given that the double precision pixel values are seldom exactly the same, is a draw ever likely? Or it is just returning the maximum pixel most of the time?

Paul Howson

[PaulHowson]

John,

One more question about the vips-8 release which you mentioned.

What is the status of the Ruby interface? Is the Ruby interface different for vips-8? Are there improvements in vips-8 versus earlier versions?

Paul

[jcupitt]

Ruby: I've tried twice now. I've done a vips8 binding using gir_ffi:

https://github.com/jcupitt/gir_ffi-vips

It works well, but it has fairly severe memory leaks. gir_ffi does not handle finalization of gobjects well. I've opened a couple of issues for things I've found, I'm hopeful it'll improve.

I've done another one using gobject-introspection:

https://github.com/jcupitt/ruby-vips8

This doesn't leak, but they don't seem to implement array arguments to boxed types, so obvious things don't work. I should open some issues on this as well, but I've not got around to it.

Both are very close to the vips8 Python interface, so they are written in pure Ruby, they are generated at runtime by introspection, they have a full set of operator overloads, they support optional arguments, and they support the new image load API.

The Python page covers the new features in more detail:

http://www.vips.ecs.soton.ac.uk/supported/current/doc/html/libvips/using-from-python.html

The two Ruby bindings are exactly like that, modulo small syntax differences.

[jcupitt]

I meant to add, the new vips8 ruby is really nice, it's a good improvement over the current ruby-vips, and it's frustrating that it's blocked like this :-(

[PaulHowson]

On 9 Apr 2015, at 6:11 pm, John Cupitt notifications@github.com wrote:

I meant to add, the new vips8 ruby is really nice, it's a good improvement over the current ruby-vips, and it's frustrating that it's blocked like this :-(

I read about how gobject-introspection works and how it automatically generates an interface into the GObject based vips. Neat stuff. Obviously easier to maintain and add to.

For now ruby-vips is working OK for me (with the workaround for im_maxpos_avg).

I will keep an eye on the vips blog and look out for progress on the new version.

Thanks for your assistance (did you see my other message about im.maxpos?)

Paul

---

Paul Howson
Warwick Qld Australia
e: paul@tdgq.com.au mailto:paul@tdgq.com.au w: tdgq.com.au http://tdgq.com.au/
GRAPHIC DESIGN WEB SITE DESIGN WEB APPLICATIONS

[jcupitt]

Yes, sorry, I'll try to get back to this next week.