Ticket #1809 (closed defect: moved)

Opened 6 years ago

Last modified 6 years ago

Brightness/Contrast min/max fields are not respected

Reported by: bdezonia Owned by: curtis
Priority: major Milestone: imagej2-b8-analysis
Component: Analysis Plugins Version:
Severity: serious Keywords:
Cc: schmid@… Blocked By:
Blocking: #1100

Description (last modified by bdezonia) (diff)

Create a black float image 1000 x 1000
Run Process > Math Equation
Use this data for input to dialog: [x, y], (x + y) / 1000
This makes a ramp 0 to 2 by thousandths
Now open B&C and set min to 0.001 and max to 0.008
Tabbing out of the fields will not use entered values but some calculated values instead.

This ticket based on an email from Michael Schmid

Change History

comment:1 Changed 6 years ago by bdezonia

  • Owner changed from aivar to bdezonia
  • Status changed from new to assigned

comment:2 Changed 6 years ago by bdezonia

  • Description modified (diff)

comment:3 Changed 6 years ago by bdezonia

Micahel's original text:

Image>Adjust/Brightness overrides the input if one has a small range for a 32-bit image (e.g. if I want to see the range 0 to 0.0001 in an image with range -10 to 10). Then, if I want to set the minimum, it also destroys my previous maximum setting, and other way round.

comment:4 Changed 6 years ago by bdezonia

  • Description modified (diff)

comment:5 Changed 6 years ago by hinerm

Just wanted to add some extra info:

  • Confirmed this happens with other pixel types, but the threshold for the auto-adjustment seems like it could be pixel-type dependent.

e.g. in an uint8 image I can set max to 5 and min to -5 with no problem. If I try to do the same in a float image, the min/max get reset to to -185.559 -175.418.. which has almost the same range, except that it's added a value close to 1 and distributed it oddly between the two values.

  • Noticed odd automatic adjustments adjusting the minimum one step at a time, when changing sign.

e.g. if I take my uint8 image and set the min to -5 and max to 5, and then increment (arrow up) the min 6 times, I now have a min of 1.121 and a max of 5.791 (same weird rounding error where it added about 1 unit)

comment:6 Changed 6 years ago by bdezonia

It appears the contrast value is exceeding the 0-100 range and the B&C plugin then recalcs all values. This is because the formula for determining contrast returns values outside [0.0,1.0]. If you set MAX_POWER to 8 from 4 this problem is less apparent.

I cannot find documentation for where the contrast unit normalization code comes from to see if it is correctly implemented.

Last edited 6 years ago by bdezonia (previous) (diff)

comment:7 Changed 6 years ago by bdezonia

  • Milestone changed from imagej2-b7-ndim-data to imagej2-b8-analysis

comment:8 Changed 6 years ago by bdezonia

Recent chat log:

bdezonia
ctrueden do you have some kind of citation for the log()/exp() calcs in the B&C plugin? Or was that code written by Grant?

ctrueden
You mean the stuff with Math.exp and the MAX_POWER constant? I wrote that.
No citation.
I was hoping my comments would be enough to make it possible to puzzle out.

bdezonia
I am getting cases where contrast is going outside [0,1].

ctrueden
Probably because minUnit & maxUnit are outside [0, 1], probably because min < dataMin, or min > dataMax, or some such? Just a guess.

bdezonia
I don't think its a data range issue. I debugged this a while ago though. See ticket #1809 if you want. I'll look more carefully at the code after vaca

ctrueden
Other edge cases include dataMin & dataMax being near floating point range limits, or very near one another, or...

comment:9 Changed 6 years ago by bdezonia

  • Owner changed from bdezonia to curtis
  • Status changed from assigned to reviewing

The problem arises in this line:

final double cUnit = (Math.log(m) + MAX_POWER) / (2 * MAX_POWER);

This is only between 0 and 1 if:

e(-MAX_POWER) <= m <= eMAX_POWER

In our current code MAX_POWER = 4 and thus valid slope ranges are between 0.018 and 54.6.

Nowhere in previous calcs is this enforced. The slope can be wildly outside this range. CTR I think you have a bad assumption in your math. Can we discuss?

Last edited 6 years ago by bdezonia (previous) (diff)

comment:10 Changed 4 years ago by curtis

  • Status changed from reviewing to closed
  • Resolution set to moved
Note: See TracTickets for help on using tickets.