Bug 421 – Image values of zero not correctl in Image Calculator when binarized image is calculated with a non-binarized one on 64-bit Mac FIJI ImageJ 1.46j with JAVA 1.6.0_29

Bug 421 - Image values of zero not correctl in Image Calculator when binarized image is calculated with a non-binarized one on 64-bit Mac FIJI ImageJ 1.46j with JAVA 1.6.0_29


Summary:	Image values of zero not correctl in Image Calculator when binarized image is...

Status:	RESOLVED FIXED

Product:	Fiji
Classification:	Unclassified
Component:	Other
Version:	unspecified
Hardware:	Macintosh Mac OS

Importance:	P2 major
Assigned To:	ImageJ Bugs Mailing List

URL:	http://www.zshare.ma/6yctogzseq5p

Depends on:
Blocks:

Reported:	2012-04-27 15:16 CDT by Jussi Kenkkilä
Modified:	2012-06-07 10:38 CDT
CC List:	0 users

See Also:

Attachments
Macro to test for the bug (551 bytes, application/octet-stream) 2012-05-14 15:07 CDT, Jussi Kenkkilä
Results showing the bug in effect (836 bytes, application/vnd.ms-excel) 2012-05-14 15:09 CDT, Jussi Kenkkilä
Results when the bug is not in effect (728 bytes, application/vnd.ms-excel) 2012-05-14 15:09 CDT, Jussi Kenkkilä

Description Jussi Kenkkilä 2012-04-27 15:16:19 CDT

Using FIJI (updated 19.4.2012) ImageJ 1.46j with JAVA 16.0_29 on a 64-bit Mac the image value of zero (0) was not calculated as zero in Image Calculator. When .zvi images with 12-bit image dynamics (shown as 16-bits) were imported and one of them was thresholded and binarized (and converted automatically to 8-bit) and the calculated to another (in original 16-bit format)the results of AND or multiplication or subtraction at areas of zero value on the binarized were spurious. In the AND & multiplication results the areas had non-zero values and in the subtracted results the values were lower then on the non-binarized image (like a positive value had been subtracted from them). 

The same process was tested on an older version of ImageJ on the same computer and on two other computers (64-bit Win7 FIJI ImageJ 1.46j JAVA 1.6.0_24 and 32-bit WinXP FIJI ImageJ 1.46j JAVA 1.6.0_20) and was not reproduced on those. It was reproduced on the original test version after software restart.

Comment 1 Johannes Schindelin 2012-04-27 15:45:27 CDT

Could you please provide a macro reproducing the issue? It should be enough to generate two 1x1 images and use the Set... function to force the values in your original images.

It would be greatly appreciated!

Comment 2 Johannes Schindelin 2012-05-12 06:21:51 CDT

This report is not valid until the time when an easy to reproduce macro is provided. Otherwise it would be asking the developers to go on a wild goose chase, which would be unreasonable given that they have so much more they need to do. In other words, this developer uses communication and feedback as an indicator just how badly someone needs a fix.

Comment 3 Jussi Kenkkilä 2012-05-14 15:07:36 CDT

Created attachment 58
Macro to test for the bug

"Test1.ijm" is a macro recording of the workflow that is affected by the bug.

Comment 4 Jussi Kenkkilä 2012-05-14 15:09:19 CDT

Created attachment 59
Results showing the bug in effect

"Results1.xls" shows the results of the process when the bug is in effect (measurements close to zero).

Comment 5 Jussi Kenkkilä 2012-05-14 15:09:53 CDT

Created attachment 60
Results when the bug is not in effect

"Results_manual1.xls" show the results of the process when it was manually repeated on a different machine (measurements as expected).

Comment 6 Jussi Kenkkilä 2012-05-14 15:15:52 CDT

Macro, link to an image used when the bug appears and results from correct and incorrect measurements added.
Also when the macro was run on another computer (32-bit WinXP) from the original (64-bit Mac) where the bug was first encountered the same faulty results appeared. Recreating the workflow manually had correct results. Running the macro only to the the point before "Image Math" and then running that process manually still resulted in the bug showing up.

Comment 7 Johannes Schindelin 2012-06-07 10:38:56 CDT

First of all, please make things easier in the future. I had to fiddle for half an hour until I had all the files and all the correct settings. No metadata, Split Channels, no Autoscale, and Legacy ImageJ Stack were the settings for Bio-Formats that I used.

Your issue appears to be fixable by changing the order of the operands of the AND operation.

Since you report a breakage for 1.46j on MacOSX but none on 1.46j on Windows, I suspect that the test was performed with differing operand orders.

But I suspect a much bigger problem there: since the second channel is converted to a mask, which is no longer 16-bit but instead 8-bit, the AND operation is likely not doing what you think it should do. (And that is the reason why the otherwise commutative AND operation is not commutative in your case.)

Much more robust than relying on ImageJ 1.x trying to guess what it should do about the type mismatch would be to convert the mask to 16-bit, dividing it by 255 and the multiplying the first channel with it. That way you do not leave room for ImageJ to guess what you want.