NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #2008 (closed defect: fixed)

Opened 2013-10-02T13:23:29-05:00

Last modified 2013-10-10T16:21:24-05:00

Brightness / contrast broken for float types

Reported by: hinerm Owned by: bdezonia
Priority: major Milestone: imagej2-b8-analysis
Component: ImgLib2 Version:
Severity: fatal Keywords:
Cc: bdezonia Blocked By:
Blocking: #1457

Description

When running Brightness/Contrast is run on float images it seems to fail with an exception[1] in the imglib2 layer.

To reproduce:
File -> New Image
Type -> 32-bit signed float
Run Brightness/Contrast

I used actual float data as well (attached .fits image) and B/C failed again in the histogram creation when attempting to access bin 256 of 255, I believe.

[1]
imagej.module.MethodCallException: Error executing method: imagej.core.commands.display.interactive.BrightnessContrast#initValues

at imagej.module.MethodRef.execute(MethodRef.java:77)
at imagej.module.AbstractModule.initialize(AbstractModule.java:86)
at imagej.plugin.InitPreprocessor.process(InitPreprocessor.java:65)
at imagej.module.ModuleRunner.preProcess(ModuleRunner.java:107)
at imagej.module.ModuleRunner.run(ModuleRunner.java:159)
at imagej.module.ModuleRunner.call(ModuleRunner.java:129)
at imagej.module.ModuleRunner.call(ModuleRunner.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)

Caused by: java.lang.reflect.InvocationTargetException

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at imagej.module.MethodRef.execute(MethodRef.java:73)
... 11 more

Caused by: java.lang.IllegalArgumentException: invalid Real1dBinMapper: nonpositive data range specified

at net.imglib2.histogram.Real1dBinMapper.<init>(Real1dBinMapper.java:87)
at imagej.core.commands.display.interactive.BrightnessContrast.computeDataMinMax(BrightnessContrast.java:282)
at imagej.core.commands.display.interactive.BrightnessContrast.viewChanged(BrightnessContrast.java:212)
at imagej.core.commands.display.interactive.BrightnessContrast.initValues(BrightnessContrast.java:200)

Attachments

vogtstar.fits (1.7 MB) - added by hinerm 2013-10-02T13:23:42-05:00.

Change History

Changed 2013-10-02T13:23:42-05:00 by hinerm

comment:1 Changed 2013-10-03T11:02:19-05:00 by bdezonia

This is actually two separate bugs.

The bug that happens with the provided file is due to a roundoff error. That has been fixed with imglib commit b196c1acc86b1b00e36fd497631685dc076b98c4.

After fixing that bug the new float image bug can happen if the Fill With parameter of the New Image dialog is set to Min or Max. Ramp and Zero work fine. In the failure cases its because you're defining a bin mapper on an interval extent of zero. We need some logic to catch this. Not sure why Fill With Zero works.

comment:2 Changed 2013-10-03T11:02:45-05:00 by bdezonia

  • Blocking 1457 added

comment:3 Changed 2013-10-03T11:03:04-05:00 by bdezonia

  • Milestone changed from imagej2-unscheduled to imagej2-b8-analysis

comment:4 Changed 2013-10-03T13:16:27-05:00 by bdezonia

I have made a change to imglib with commit f4cbd1e147d323bdfedcb0155feb28b11fc7ec7e that allows 0 width bin range in Real1dBinMappers. This is part of a fix for the new float image issue. I can't test it in IJ2 yet because imglib and ij2 are at different stages of merging their nonlinear-goodies branches. Once IJ2 is up to date I will need to test this fix.

The additional piece to fixing this might be to make the DefaultAutoscaleMethod safely return a nonzero width data range when an image is all one pixel value. The code that is present only works for Zero and not Min or Max. Min and Max are special because slightly bumping range fails due to precision loss. The bumped min/max values of data range are the same afterwards. But all this might not be necessary if the imglib commit above works. Note that autoscale method bumping was added to fix various display range calc bugs.

comment:5 Changed 2013-10-07T11:03:55-05:00 by bdezonia

I think we need to allow AutoscaleMethods to return 0 as a possible display range extent. It will be the job of consumers to test that situation. This will reopen #1431 and #1880 (while #1948 will stay fixed). We will need to capture the display range of zero issue elsewhere. (The mentioned commands are the ones that required some hackery in DefaultAutoscaleMethod that I'm proposing to go away)

comment:6 Changed 2013-10-07T14:24:31-05:00 by bdezonia

After discussion with ctrueden we've decided that the default autoscale method should detect when min == max and return an interval that is [typeMin, typeMax].

comment:7 Changed 2013-10-07T14:55:08-05:00 by bdezonia

With commit 2c5e74e754d4788a4ae385df0a4452282221d485 the typeMin,typeMax code is in place. Still waiting for IJ2 nonlinear-goodies to be merged before I can fully test that this ticket is fully addressed.

comment:8 Changed 2013-10-10T16:21:24-05:00 by bdezonia

  • Status changed from new to closed
  • Resolution set to fixed

With commit 7540a6f5bd26512e9f5018d2ceb0bef7110e2952 the last of the hangups with B&C working with float images has been handled. Closing.