Here's a question about ImageJ from my boss.
John
>With 16-bit grayscale images, ImageJ appears to allow the display of more
>than 256 shades of gray. How is this done?
>
>It appears this way because the "Brightness/Contrast" or "B&C" tool
>(Image->Adjust->Brightness/Contrast or Ctrl+Shift+C) updates the screen
>very rapidly; i.e., changes in screen colors keep up with any slight
>movement of the sliders. Even on a 1Kx1K image that uses the full gray
>range (0-65535), the update of the colors is almost instantaneous. Yet if
>you compress the display range to any 256-value window, you still see the
>full grayscale -- there appears to be no quantization of the color bins.
>
>My model of how images are displayed is that there is a 256x4-element
>color lookup table (LUT) for mapping a pixel value to (R-G-B-alpha) for
>display. Then, for 8-bit images, an image pixel intensity value between 0
>and 255 maps to the right RGB value in the LUT. (The LUT can be
>grayscale, where the RGB values are equivalent at each intensity, or false
>color where they are not.) The B&C tool, then would only have to change
>768 LUT values (256 each for R,G,B) for every mouse slider movement... easy.
>
>However, when the number of possible intensity values is 65536, as with
>16-bit images, and the number of display values is 256, it seems that the
>entire image would have to be remapped to a new 256 values in the frame
>buffer in order to avoid quantized gray levels. This would take
>considerable time for a 1Kx1K image, so it would not be intantaneous,
>right? Am I missing something? The documentation does not talk much
>about 16-bit grayscale displays.
>
>I am impressed by this property of ImageJ, as other programs do not handle
>display of >8-bit grayscale as seamlessly. Can someone shed light on this
>property? Thank you.
>
>(Note: I have a PC laptop with the standard Intel 82852/82855 GM/GME
>Graphics controller.)
>
Locked
