Image>scale produces NullPointerException

I have a few .tif binary 8 bit masks (hyperstacks) which I need to resize, so I’ve been using the image>scale function. They are all produced via ImageJ and in the same way. Many scale with no problem, however some do not. Instead I get an exception window with the following information:

(Fiji Is Just) ImageJ 2.0.0-rc-43/1.51a; Java 1.8.0_91 [64-bit]; Mac OS X 10.10.5; 128MB of 7191MB (1%)

at ij.plugin.Scaler.createNewStack(
at ij.IJ.runPlugIn(
at ij.Executer.runCommand(

Changing scaling parameters does not restore function.
I have tried to do this on a mac and then a windows machine but it gives the same exception. I have sent these images to other people and they are also unable to resize this image and get the same exception.

I am able to duplicate the hyperstack without problem, but the duplicate still wont scale. Nevertheless duplicating a single frame from one channel of the hyperstack will allow me to scale that single frame.

Does anyone know what this problem could be? and how to fix it?
I have tried to upload this image via “Help>Upload sample image” to share it but I get an error. It’s not too big (8.4 Mb) so if anyone knows how to upload it that would also help, as the .tif extension is not authorised to upload in this forum.

I hope all the info I’ve given is enough, but I would be happy to supply any further info if required.



Looking at that code, it appears the image you are trying to scale might have an overlay?

@Wayne I do not understand why the index i-1 is passed to overlay.get when i is the slice index of the loop.

You are right!
If I do Image>overlay>remove overlay, I am now able to scale.

I have no idea how this overlay is introduced or why its only on some images given that the ones I am able to scale are generated via the same macro. Also trying overlay>show overlay or hide overlay or even overlay manager does not detect any

Thank you for the input, I never would have guessed the problem.

1 Like

Great, glad this works!

Of course, this is a workaround—there is a bug here, which will hopefully be fixed in a future version of ImageJ.

I agree, its only a workaround.
I’ll be happy to see this fixed in future versions.

This bug is fixed in the latest ImageJ daily build (1.51b8).


Stacks use one-based indexes and overlays use zero-based indexes.

Thanks. What I meant was: overlay.get(int) “returns the ROI with the specified index or null if the index is invalid” which makes sense since Overlay is a bag of Rois. But I see no one-to-one correlation between the number of ROIs in the overlay, versus the number of slices in the image. The i here is the image’s slice index, so I didn’t understand why it was valid to use that same (adjusted) index into the image’s overlay. Sorry if I missed something there.

Thanks! For the technically inclined, the fix can be seen here.

You are correct. There is no one-to-one correlation between the number of ROIs in the overlay versus the number of slices in the stack. In the latest daily build (1.51b9), the images in the overlay are scaled in a separate loop.

1 Like


And thanks again.

I understand what the issue was now.