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


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.



1 Like

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

Note in particular this comment by @ctrueden:

@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:

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


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).


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)


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.