[ome-devel] Problem with fetching image from image server

[Swaroop A. Jagadish]

Hello Ilya,
Thanks for your reply. I needed to fetch the image in order to compute
texture feature vectors and not for display purposes. Clearly, Composite 
mehtod is not the one to be used according to what you said. If the 
original image was a single TIFF image(which in our case is true for a 
majority of the time), I'm ok with using the ReadFile method. However, if the original file
is a Z-series image, how can I extract individual slices as TIFF images. 
My feature extractor can only understand TIFF images. Any help in this 
regard will be greatly helpful.

Thanks,
Swaroop

On Wed, 15 Mar 2006, Ilya Goldberg wrote:

> Hi Swaroop
> The Composite method always returns an 8-bit TIFF (or JPEG, or PNG)- 
> regardless of the bit-depth in the original TIFF.  If you specify RGB 
> channels, you get an RGB TIFF, if you specify GrayChannel, you get a 
> grayscale TIFF.  But its always 8 bit per channel, because the purpose of 
> this method is to produce an image for display rather than one preserving the 
> numerical content of the pixels.
> Is this what you want to do?
> Because if you want the numerical values of the pixels, you should use one of 
> the GetPixels methods.  Unfortunately, those don't produce TIFF files - they 
> only give you the raw pixel data.
> If you just want the original TIFF, then you can use the ReadFile method 
> (with no parameters other than the FileID), and it will give you back your 
> original TIFF just as it was.
>
> If the Composite method really is what you want, the specification of how to 
> map Pixels channels to display channels is done using RedChannel, 
> GreenChannel, BlueChannel or GrayChannel (for a grayscale tiff).
> Each *Channel parameter has 4 components:
> the channel index (Pixels coordinate in the C dimension), black level, white 
> level, and gamma
> e.g. GrayChannel=0,0,255,1.0
> The black level and white level refer to the input range - i.e. the numerical 
> range of your pixels.  The output range is always 0-255, because  the output 
> is always 8 bits per channel with this method, because its meant for display. 
> If your image was an 8-bit tiff to start out with, then the example above 
> will not do any scaling because the specified black level and white level 
> match the 0-255 output range.  If it was not an 8-bit tiff to start with, 
> some scaling needs to occur because only 8 bits per RGB channel (or 
> grayscale) can be displayed.  You can scale from min to max, or from 0 to 
> 4095 (for a 12-bit CCD) or 0 to 32767 for signed 16-bit, or 0 to 65535 for 
> unsigned 16-bit.  But remember that the pixel values in the resulting TIFF 
> will always be 0-255.  This is all because its not physically possible to 
> display an image with more bit depth "as is" without scaling.
> You can determine what input range to use by looking at pixel statistics 
> which are stored in the DB (look at the outputs of the Stack statistics 
> module for one of your images in the Web UI).  Some suggestions may be to use 
> StackMinimum and StackMaximum for your black level and white level.
>
> OME attempts to "guess" at an appropriate black-level and white-level setting 
> for your images when you import them (look at the DisplayChannel output of 
> the "Image import" module for one of your images in the Web UI). 
> DisplayOptions has a reference to DisplayChannel for each of the RGB channels 
> to indicate the mapping for an RGB display.
>
> Maybe a more detailed description of what you want to do would help us help 
> you better.
>
> -Ilya
>
>
>
>
> On Mar 14, 2006, at 6:45 PM, Swaroop A. Jagadish wrote:
>
>> Hi,
>> What are the right parameters to use for the white level and black level
>> for each channel if I'm using the Composite method to fetch the image. I
>> want the image  in its original form when I uploaded it (Its not a
>> Z-series image - its just a simple TIFF image). Are these values stored in
>> the database somewhere.
>> 
>> I tried using GetPlaneStats method to extract the min and max for each
>> channel. But that doesn't seem to be helping. Any help would be greatly
>> appreciated.
>> 
>> Thanks,
>> Swaroop
>> _______________________________________________
>> ome-devel mailing list
>> ome-devel at lists.openmicroscopy.org.uk
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>