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

[Ilya Goldberg]

If the texture extraction is in software that you developed (or that  
you have access to), wouldn't it be just as easy for it to operate on  
a raw pixel dump as on a set of pixels from a TIFF file?  If you  
can't modify the texture extractor, and it really must use a tiff  
file for input, then maybe using OME-TIFF is what you want to do.   
There are tools available (including command-line) that let you  
produce these types of files.  More info here:
http://www.loci.wisc.edu/ome/ome-tiff.html

This type of problem is probably common enough that we may want to  
consider implementing TIFF conversion features in OMEIS.  Maybe by  
adding an optional Format parameter to GetPlane.  Probably TIFF is  
the only format that would make sense because its the only format  
capable of dealing with all the numerical types supported by OMEIS.   
This would be quite limited - there would be no way to put multiple  
planes (or RGB) into a single TIFF.  Another option is to give the  
Composite method a parameter to lift the 8-bit per channel limitation  
on the output tiff.

How much of the TIFF standard does your texture extraction software  
support?  Does it work with RGB tiffs?  16-bit?  floating-point?   
multi-plane?  As you can see this can potentially be a lot of  
features to support.  How much of the conversion should be supported  
by OMEIS vs. by the client requesting the pixel data?

-Ilya



On Mar 18, 2006, at 1:30 AM, Swaroop A. Jagadish wrote:

> 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
>>
>