NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 1169 - Process-Math-Macro...
Process-Math-Macro...
Status: RESOLVED FIXED
Product: Fiji
Classification: Unclassified
Component: Plugins
unspecified
PC Windows
: P5 critical
Assigned To: ImageJ Bugs Mailing List
Depends on:
Blocks:
 
Reported: 2015-10-02 05:29 CDT by d.krunic
Modified: 2015-10-09 19:07 CDT
2 users (show)

See Also:


Attachments
Picture can say 1000 words. (142.56 KB, image/jpeg)
2015-10-02 05:29 CDT, d.krunic

Description d.krunic 2015-10-02 05:29:09 CDT
Created attachment 263
Picture can say 1000 words.

Can you please help, I wanted to use the Process-Math-Macro... option in FIJI developed based on the Expression plugin, but I cannot get it to work with 16-bit grey images properly. So I wrote the macro for this, but it is much to slow comparing to the Macro... plugin. 
The Process-Math-Macro... works great for 8-bit, but it does some strange calculation when it comes to 16-bit. Simple operation, such as

v=getPixel(x, y)-getPixel(x-1, y-1);

gives funny result with 16-bit.
It appears that the new 16-bit processed image is OK but only for the first 2 rows / columns of pixels. All the other pixels are not OK because I guess the wrong image is targeted; the plugin should target the original image again, but instead it targets the new image to calculate new values from new values. This is obviously wrong; it should get pixels from the original image and after that target the new image and change the values there. Interestingly, it does not do this for the 8-bit.
Just create a simple File-New-Image with 5x5 pxl 16-bit random fill and try it, check the middle pixel and you will see what is the problem. Also, create 8-bit out of the same 16-bit and try the same operation again - you will see that it works.

Would you have any idea how to fix this?
Thank you very much for your help.

Best regards,
Damir
Comment 1 Curtis Rueden 2015-10-02 09:16:42 CDT
What happens is: the Process > Math > Macro... command iterates over every pixel, replacing each value in-place as it goes. By referencing previously processed pixels via getPixel(x-1, y-1) you are subtracting your new pixel values instead of your original ones.

Interesting that it works in 8-bit, but not 16-bit. Looking at the source, this is because there is special case logic for 8-bit and RGB images [1] which copies the pixel buffer before executing in the case where the getPixel function is used [2, 3]. However, no such thing is done for 16-bit [4].

As a workaround, you can instead write:

  v=getPixel(x+1, y+1)-getPixel(x, y);

Which avoids the issue.

I agree that this is a bug, in that the behavior between 8-bit and 16-bit is inconsistent.

[1] https://github.com/imagej/ImageJA/blob/v1.50b/src/main/java/ij/plugin/filter/ImageMath.java#L254-L335
[2] https://github.com/imagej/ImageJA/blob/v1.50b/src/main/java/ij/plugin/filter/ImageMath.java#L277
[3] https://github.com/imagej/ImageJA/blob/v1.50b/src/main/java/ij/plugin/filter/ImageMath.java#L319
[4] https://github.com/imagej/ImageJA/blob/v1.50b/src/main/java/ij/plugin/filter/ImageMath.java#L321-L334
Comment 2 Wayne Rasband 2015-10-09 19:07:42 CDT
This bug is fixed in the latest ImageJ daily build (1.50d11).