converting to ShortProcessor. By setting your FloatProcessor's
DisplayRange to max and min you are effectively disabling this feature.
When starting to process DICOM data this gave me a big headache. I
ShortProcessor using this short[][].
FloatProcessor before the conversion to an integer format. Also iff there
the first step that is taken before converting to a color format.
constructor; So... each type of processor does it differently. As you
hard to comment further.
> Context: Java plugins
> I want to take a completely arbitrary ImageProcessor and produce a
> ColorProcessor, with the twist that I want to enhance images for display.
> For my images, most color images (including 8-bit images with color LUTs)
> are already sufficiently enhanced (or - the colors actually mean something
> and I donât want to interfere with that). But, the grayscale images
> include everything from 8-bit images with and without LUTs to 32-bit Float
> images with very strange ranges of values.
>
> The intent is to produce an image to LOOK AT. Measurements are done using
> parallel copies of the images, which are not modified (and not displayed).
>
> I started with a very verbose set of cases, for testing and debugging. I
> had some difficulty with the 32-bit images and found it necessary to
> convert (with scaling) to 16-bit before enhancing. I donât remember
> what the issue was. Today, I decided to collapse the cases at the cost of
> possibly doing some extra work. Speed and other efficiency is NOT an
> issue.
>
> I would appreciate it if someone more expert than myself would take a
> look at the following piece of code and comment. It appears to work
> properly, but I have really only tested it in 32-bit Float and 8-bit
> images with color LUTs. Iâm especially interested in comments on why
> the computation of min/max and the conversion to 16-bit is required for
> 32-bit images (and also whether it is âwrongâ to do that for other
> image formats). It appears to work, but this is the result of trial and
> error (lots of errors!) and I may have lost perspective. Of course, this
> is a tiny part of (several) larger Java plugins. I *think* that the use
> of IJ.run(â¦) is required for the âEnhance Contrastâ step; some of
> the other steps might use more direct methods, but as long as I have the
> ImagePlus available, I thought I might as well use it.
>
> I am grateful for any comments.
>
> // enhance an ImageProcessor for display purposes
> // Input is an arbitrary ImageProcessor
> // Output is a ColorProcessor, possibly enhanced for display
> private ColorProcessor ip2cp(ImageProcessor ipIn)
> {
> if(ipIn.isGrayscale())
> {
> ImageProcessor ip = ipIn.duplicate();
> ImagePlus ipl = new ImagePlus("temp", ip);
> ImageStatistics imStat = ip.getStatistics();
> double min = imStat.min;
> double max = imStat.max;
> ipl.setDisplayRange(min,max);
> IJ.run(ipl,"16-bit","true");
> IJ.run(ipl,"Enhance Contrast","saturated=0.35");
> IJ.run(ipl,"Apply LUT","");
> return ipl.getProcessor().convertToColorProcessor();
> }
> return ipIn.convertToColorProcessor();
> }
>
> â
> Kenneth Sloan
>
[hidden email]
> Vision is the art of seeing what is invisible to others.
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>