Bug Report: Crop 16-bit images with rectangular selection

imagej

#1

Hello,

I have been having this issue for a while, and I could not find previous reports of it.

Since the “Report Bug…” feature in FIJI is not working, I can’t provide full details of my install here. Working in Windows 8.1. I tested it with a freshly downloaded 64-bit Windows FIJI, ImageJ 1.52c and got the same result:

To reproduce bug:

  1. Open the sample image M51 Galaxy (16-bit)

  2. Draw a rectangular selection around a visible feature. The selection should not start in the top left corner.

  3. Crop the image using either Ctrl+Shift+X or using the menu

  4. FIJI crops the image to the size of my selection, but shifts the cropped region to the top left corner. As a result, the selected feature is not in the cropped image. In the galaxy sample file, I end up with a black crop.

This happens with every 16-bit grayscale TIFF image, and has been happening in the current and previous version (1.52b and 1.52c). I am not sure when exactly the bug appeared.

Please let me know if important information is missing, or if I missed a previous report of this issue.

Thank you!


#2

Hi @phig,

I think there is a bug, but not the one you think.

Repeating your protocol, I end up with the right object but the brightness and contrast has been reset in the cropped image. Using the “Auto” mode shows the feature again.

I tested it by doing the following.

1.Create a selection
2. Duplicate the selection only, this is now my reference
3. Use CTRL+SHIFT+X to crop the original
4. Image calculator to subtract the duplicated and the cropped image.

The result of the subtraction is a totally black image , which means there is no difference between the two methods, but the duplicate has the same B&C and the crop has the B&C reset…

Can you please check this and let me know if it’s true?


#3

Hi @oburri,
thank you for the reply and question!
I think the truth lies somewhere in between, and thanks to your efforts, I discovered that the issue is even more weird than I thought.
Let me provide an image that I would actually use here, and show what performing the steps gives:

  1. original image:
  2. initial crop window in FIJI
    Gel_downsized_crop1
  3. image when I open “Brightness & Contrast” or when I save it.
    Gel_downsized_crop_brightness-open

So, the image shown after cropping is clearly wrong, and not just reset in brightness. But the actual image used for the calculation is correct, and somehow ImageJ seems to think it is showing the right image.

Simply opening the brightness & contrast window “snaps” the cropped image to the correct place, so that is a quick workaround for now.
Thank you for your time and for the suggestion!
Cheers,
Philipp


#4

Cool. thanks for the heads up, so it’s a refresh issue.

TBH I have no clue where I can offer a pull request to fix this but perhaps we could get @Wayne in this so he can help us out if he has a bit of time


#5

I think this is just a panel layout problem and not the fault of the crop function. If you use the zoom in/out action or by resizing the frame the effect should be the same (correcting the panel layout). The image data itself should be correct.


#6

Any hints on where this could be corrected in the code?


#7

After the crop function a layout call could be appropriate (ij.plugin.Resizer).

But for me the layout call works correctly (Win 10) with the given example image.

But I could reproduce the analysis (brightness and contrast has been reset) of @oburri which could lead to some confusion.


#8

This regression is fixed in the latest ImageJ daily build (1.52d16). To upgrade, use the Help>Update ImageJ command and select “daily build” from the drop down menu.


#9

Awesome, thank you all for helping out and big thank you to @Wayne !
I downloaded the daily build and now everything works fine.