Changing IJ1 image type -> IJ2 command keeps the old image

[NicoKiaru (Nicolas Chiaruttini)]

Hi,

I noticed this weird bug (all macros are groovy):

Just make an image in 16-bits:

#@ImageJ ij
import ij.IJ;

imp = IJ.createImage("TestImg16b", "16-bit ramp", 512, 512, 1);

Now launch this dummy groovy script:

#@ImgPlus img
#@OUTPUT ImgPlus img

This duplicates the ramp image. So far so good.
Now :

• close the extra image,
• change the TestImg16b to 32-bits (run("32-bits");)
• crop a rectangle anywhere to modify the image
• relaunch the dummy groovy script

Surprise! The old unmodified 16 bits image shows up. And this is due to the change in bit depth. This is annoying because it can lead to incomprehensible bugs.

Best,

Nicolas

[imagejan (Jan Eglinger)]

Similiar (or at least related) issues were discussed in this thread:

@ Parameter issue ImagePlus versus Dataset versus Img

Hey guys, I’m experiencing some weird behaviour when working with the @ Parameter stuff from jython scripts. I have some scripts generating ImagePlusses and some others creating Imgs. Now, I would like to combine these images in another script and get the images as parameters; ideally as Datasets. The pulldowns in the dialog are build in a weird way. This is my minimal code example for creating these images: #@UIService ui #@OpService ops from ij.gui import NewImage from net.imglib2.util impo…

Note in particular this comment by @ctrueden:

@ Parameter issue ImagePlus versus Dataset versus Img

There is a lot of magic going on to translate these things back and forth in ImageJ Legacy. The magic is known to be incomplete in some circumstances, so it is not too surprising that there are issues when you really exercise it like this—e.g. by mixing and matching.

@stelfrich has put some effort in improving the way how this translation IJ1<->IJ2 is done in a way that updates of the data are transparent to each respective other layer:

Fix duplicate entries in image selections

I don’t know if this helps, but it might shade some light on the issue…

[imagejan (Jan Eglinger)]

#@ImageJ ij
import ij.IJ;

imp = IJ.createImage("TestImg16b", "16-bit ramp", 512, 512, 1);

Note that your example worked well for me when I used IJ2 structures exclusively, i.e. created an Img instead of an ImagePlus:

#@ImageJ ij
import net.imglib2.type.numeric.real.DoubleType

img = ij.op().run("create.img", [100, 100] as int[], new DoubleType())

and switched to “modern mode”, i.e. the experimental IJ2 Swing UI (that has a few other issues when displaying an all-zeros image and trying to draw, but duplicating of the modified image worked fine).

[NicoKiaru (Nicolas Chiaruttini)]

Ok… This looks like a well intricated problem.

Also to give some thought to this problem - it’s not only conversion to 32 bits which is problematic:

• if I change the name of the image, it’s not updated
• if I changed pixel size (Image>properties), it’s not updated
• (but if the data is changed without type conversion, it is updated)

(and indeed keeping all in IJ2 style is ok)

[ctrueden (Curtis Rueden)]

The old unmodified 16 bits image shows up. And this is due to the change in bit depth. This is annoying because it can lead to incomprehensible bugs.

There are currently bugs in the legacy translation (or lack thereof) when a legacy image changes type or structure in some scenarios. @maarzt is hopefully going to make some improvements soon to the ImageJ Legacy layer’s image wrapping. Perhaps as part of that work we can explore how to overcome these issues. I will talk to him about it soon.