NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 802 - Voxel depth info lost when opening hyperstack with SCIFIO (plus brightness/contrast issue)
Voxel depth info lost when opening hyperstack with SCIFIO (plus brightness/co...
Status: RESOLVED FIXED
Product: ImageJ
Classification: Unclassified
Component: SCIFIO
unspecified
PC Windows
: P4 normal
Assigned To: ImageJ Bugs Mailing List
Depends on:
Blocks:
 
Reported: 2014-06-19 16:28 CDT by Keith Siew
Modified: 2015-04-06 15:49 CDT
3 users (show)

See Also:

Description Keith Siew 2014-06-19 16:28:32 CDT
When using drag and drop on a .TIFF hyperstack file with the SCIFIO active, the following two things occur:

1. The file opens with a new brightness and contrast setting that shows the image extremely saturated (i.e. it shrinks the histogram from 0-255 to 0-20). I have to manually reset the brightness and contrast to bring it back to the original. How do I disable this?

2. I noticed that when I go into image properties that the voxel depth is lost and reset to 1

Information about your version of Java:

  os.arch => amd64
  os.name => Windows NT (unknown)
  os.version => 6.2
  java.version => 1.6.0_24
  java.vendor => Sun Microsystems Inc.
  java.runtime.name => Java(TM) SE Runtime Environment
  java.runtime.version => 1.6.0_24-b07
  java.vm.name => Java HotSpot(TM) 64-Bit Server VM
  java.vm.version => 19.1-b02
  java.vm.vendor => Sun Microsystems Inc.
  java.vm.info => mixed mode
  java.awt.graphicsenv => sun.awt.Win32GraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.6
  sun.cpu.endian => little
  sun.desktop => windows
  file.separator => \

The up-to-date check says: REMIND_LATER

Information relevant to JAVA_HOME related problems:

  JAVA_HOME is set to: C:\Users\Keith\Desktop\Fiji.app/java/win64/jdk1.6.0_24//jre
  imagej.dir => C:\Users\Keith\Desktop\Fiji.app

Information about the version of each plugin:

Activated update sites:
ImageJ: http://update.imagej.net/ (last check:20140619220447)
Fiji: http://fiji.sc/update/ (last check:20140618210039)
Comment 1 Curtis Rueden 2014-06-20 23:58:08 CDT
Thanks for the bug report.

For issue 1: SCIFIO always autoscales, regardless of the input data type. This behavior differs from ImageJ 1.x, which does not initially autoscale 8-bit images. That said, SCIFIO should not be narrowing the display range beyond that of the input data itself -- so if you're seeing 0-20, is it true that 20 is the largest intensity value in your image? If not, that may be a bug.

For issue 2: I was able to reproduce the bug by opening MRI Stack, setting the unit to "micron" and voxel depth to "5", saving as a TIFF, then reopening. The unit is preserved but voxel depth is lost. There _is_ code in SCIFIO to preserve it though, so chances are the bug will be something simple to fix.

In the meantime, you can work around both issues by disabling SCIFIO (Edit > Options > ImageJ2).
Comment 2 Curtis Rueden 2014-06-21 01:00:28 CDT
The calibration issue is fixed on the SCIFIO master branch now:
https://github.com/scifio/scifio/commit/8e439102b5f0c854afeb673a5a62cd9c6b2c880e

Just needs a little more testing, release and upload. We'll do that on Monday.
Comment 3 Curtis Rueden 2014-06-23 15:27:02 CDT
I uploaded a new SCIFIO which fixes issue (2).

Feel free to follow up on issue (1) if you like, if the autoscaling behavior is too annoying and/or unexpected.
Comment 4 Keith Siew 2014-06-24 02:34:39 CDT
Hi Curtis,

Thanks a million for resolving issue 2, I've just tested it on my stacks and works great.

Regarding issue 1, I've done a bit of checking in the stack to see what might be going on and it appears that it's autoscaling on only the first image in the hyperstack, which indeed does have a 0-20 8bit range. However there are values of 255 in later stack slices (in fact the majority) so the overall stack becomes complete saturated looking and unworkable with the autoscaling currently as it is.

Would it be useful for me to upload the image file I'm working with so you can replicate what I'm seeing and attempt to resolve the bug, so it autoscales based on the whole stack rather than the first slice alone.


Kind Regards,
Keith
Comment 5 Curtis Rueden 2014-06-24 08:09:51 CDT
> Would it be useful for me to upload the image file I'm working with so
> you can replicate what I'm seeing and attempt to resolve the bug, so
> it autoscales based on the whole stack rather than the first slice
> alone.

Thanks for the offer, but in this case we do not need additional sample images. The behavior you describe (autoscaling based on the first plane) is completely expected.

The problem is basically that we want to support really, really huge datasets in a scalable way. One of the coolest things about the new SCIFIO support is that it will transparently use a virtual stack -- i.e., not read in all the image planes in advance -- when the data is large, so that you can get started visualizing and analyzing the data sooner.

However, that approach comes with a price: we do not yet know all the pixel values, and hence do not know the global data min/max values at the time the first image plane is displayed.

So my question to you is: keeping in mind the above, how would you prefer it behave?

1) We can certainly read all the pixels in advance and then autoscale. But then you have to wait longer for the image to pop up, as with ImageJ 1.x. It would be the return of the loading progress bar.

2) We could show the first plane immediately, and keep loading planes in the background and adjust the autoscale later. But then your image would appear to "dim" over time as additional planes are read, which strikes me as scary and unintuitive.

3) We could provide an option. But our current approach is to make File>Open display _no_ options (i.e., behave with only defaults), and for File>Import>Image... to have all the options if you need to tweak them. So even if we provide nice autoscaling options, we will still need to decide on a default.

4) We could keep the current behavior, and then you'll need to run Image>Adjust>Brightness/Contrast after the fact to adjust the display min/max as you desire.

5) We could special case the behavior for unsigned 8-bit integer data to always use 0-255, which is IIRC what ImageJ 1.x does. But that would not solve the problem for other data types such as 12-bit or 16-bit. Another downside of that approach is that for people whose data really does have a small dark range (e.g., 0-20 through the entire dataset), the image will appear black. That situation is actually very common when in low signal scenarios, so lots of new users have historically complained about their data being "missing" when really it's just a display scaling issue. It is even the first question in the ImageJ FAQ: http://wiki.imagej.net/FAQ#The_image_I_loaded_is_displayed_all_black.21_But_it_is_not_black.21

6) Some other brilliant solution? :-)

So current thinking is that autoscaling based on the first plane (option 4 above) is the "lesser of all evils" here. But if you have any better ideas, they would be very welcome!