Ticket #1801 (closed defect: moved)

Opened 7 years ago

Last modified 6 years ago

Brightness/Contrast uses fractions

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

Description (last modified by bdezonia) (diff)

In the imagej devel maling list Gabriel Landini noted the following issues with the Brightness/Contrast plugin:

Minimum and maximum return fractional values for an 8 bit LUT. Is that right?

Are the Brightness and Contrast values (0-100?) the best scale resolution to use?. I think that having 100 units controlling LUTs with 256 values at least for 8 bit images will create unnecessary hassle (like the fractional values mentioned above). I can't see any advantage on 0-100 vs 0-255 (but maybe there is some reason?).

Also Michael Cammer mentioned elsewhere:

the values displayed in the min/max bars have decimal values but the images we have are 16 bit integer.

Change History

comment:1 Changed 7 years ago by bdezonia

  • Cc Michael.Cammer@…, curtis added
  • Description modified (diff)

After discussion between bdezonia and ctrueden we think the fractional display is okay. IJ1 is doing the same thing but does not have numeric fields that communicate this is the case. We could always display numbers without trailing fractions but that would be a problem for floating point datasets. If people object with leaving it as it is please chime in.

comment:2 Changed 7 years ago by bdezonia

  • Description modified (diff)

comment:3 Changed 7 years ago by bdezonia

Also note that 0-100 scale supports all data types. If we didn't have a displayable field for min/max this would be a nonissue (and scale could go to 1000 for finner granularity).

comment:4 Changed 7 years ago by landinig

Hm... I appreciate that this would make it the same for all image types and that it might not matter when you adjust a picture where intensity units are not particular important (a family photo or similar).
But I do not think that an arbitrary (0-100 or 0-1000) range for contrast and brightness would be useful or intuitive for images with "data".

Let's suppose I have an image coded with values between 306 and 799 and I want to make a false colour image within that range, or any other range where I want the LUT 0 and 255 values coincide to particular pixel values. Currently you cannot do that, but you can (within the resolution of the LUT values) in the IJ1 approach. It is important to know the values (not the %) of the LUT being mapped.

Can I humbly suggest to just replicate the B&C dialog as in IJ1?

It would be useful to have a "Reset" button to return to the original image state.

comment:5 Changed 7 years ago by bdezonia

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

comment:6 Changed 6 years ago by bdezonia

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

comment:7 Changed 6 years ago by curtis

I am reviewing IJ2's brightness/contrast logic, and I am afraid I do not understand what landinig is saying in comment 4 above. Currently, you can explictly assign the min/max display range to whatever values you want (not a percentage). The percentage only comes in to play with the Brightness and Contrast values -- not the Minimum or Maximum.

My question is: why does it matter what the granularity of the B&C parameters are? Having them range from 0-255 for 8-bit still seems completely arbitrary to me. All they do is adjust the slope and offset of a line function; to my knowledge, there is no useful 1-to-1 mapping between B&C values versus data range. Or do I misunderstand?

Thanks for any insight!

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

comment:8 Changed 6 years ago by landinig

Hi Curtis,
I can't remember exactly why I made that comment! I think it was that if the granularity of min and max was not integer on integer images, then the LUT might not be easily guaranteed to be in the right place? i.e. are the boundaries of the LUT falling where I think they are? With integer images in IJ1 I think we do (although not in 32 bit images).
I had a look at beta-7 and now I see that the min and max *could* be made integer if input by hand, but it is not handy to do all by typing and pressing the increment buttons AND without an histogram to return a visual cue. In IJ1 you could set the B/C and min/max with sliders interacting with the histogram. You can't in IJ2.

I suspect that other users will miss the sliders too. I do not feel the increment buttons are practical compared to sliders to make interactive adjustments with the mouse (you have to go through every number between 0 and 70 to set he min to 70!). Having a slider AND a editable box (and the increment buttons if needed) would be the best of both worlds.

For example since there is no histogram shown either, it makes it difficult to know how much data we leave out of the window defined by min and max so currently in IJ2 I can't tell what I am really adjusting. Having a "normal" histogram open does not help either because it does not show the LUT line/range like IJ1 does. That is why I suggested to replicate the behaviour of IJ1 (really I can't think of a reason to do it differently).

Hope my comments are useful and thanks for all the effort being put in IJ2.

comment:9 Changed 6 years ago by bdezonia

I'm not clear on what this ticket is really about anymore. Today I added a histogram to the dialog that displays the slope line and updates interactively. We have a ticket elsewhere for replacing the incrementers with sliders (#1803). There is some question as to whether the fractions are a problem or not. Anyone care to propose what to do with this ticket?

comment:10 Changed 6 years ago by curtis

It should be doable to make the B&C command round min and max values to integers *iff* the dataset is of integer type. Let's close this ticket once we have done that.

comment:10 Changed 5 years ago by curtis

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