[ome-devel] ScanR importer bit representation

[Rubén Muñoz]

> Hi Ruben,

Hi Melissa,

>
>> With images from this microscope Pixel type = uint16 is auto  
>> detected, but
>> they are all signed 16 bit, we know this with precision.
>
> Do either of the datasets that you have uploaded have this problem?
> If not, would you be willing to upload a small dataset that does have
> the problem?

The datasets that I have uploaded so far were signed 16bits, right out  
of the microscope.  I uploaded one more for you to have something  
smaller  "280809_8wellLT_008.zip". The import always works, but  
reports uint16.

>
> Also, just to be clear - have the TIFF files been modified at all
> since they were acquired?  You mentioned that images are converted
> from int16 to uint16 before processing; if this conversion has already
> happened, then seems correct for 'showinf' to report the pixel type as
> uint16.

We only convert the images punctually for analysis, then delete them.  
When I run 'showinf' with original TIFF files from ScanR, I get uint16  
and within the same execution the signed image gets displayed. Signed  
16 bit images are displayed not nice, nearly completely in grey.

If I can be of more help, please let me know.

Regards,
Ruben


>
> Regards,
> -Melissa
>
> On Mon, Nov 30, 2009 at 10:07 AM, Rubén Muñoz <ruben.munoz at embl.de>  
> wrote:
>>
>> Hi Ruben,
>>
>> Hi Melissa, I understand that mine was not an ScanR specific  
>> question, but I
>> have to detail a bit more what I believe an issue.
>>
>> The pixel type recorded by the ScanR software is stored in each of  
>> the
>> TIFF files.  The above code retrieves the pixel type stored in the
>> first TIFF file; later on, that pixel type is assigned to each well
>> and field.  So for the purposes of importing into OMERO, you should
>> not need to convert int16 images to uint16 - Bio-Formats will detect
>> whether or not the images are signed.
>>
>> With images from this microscope Pixel type = uint16 is auto  
>> detected, but
>> they are all signed 16 bit, we know this with precision.
>> Then the files are not properly auto-detected, or the files are not
>> consistent themselves, next is the output of ./showinf
>> Checking file format [Olympus ScanR]
>> ...
>> Series count = 54
>> Series #0:
>> Image count = 25
>> RGB = false (1)
>> Interleaved = false
>> Indexed = false (true color)
>> Width = 1344
>> Height = 1024
>> SizeZ = 1
>> SizeT = 25
>> SizeC = 1
>> Thumbnail size = 128 x 97
>> Endianness = intel (little)
>> Dimension order = XYCTZ (uncertain)
>> Pixel type = uint16
>> Metadata complete = false
>> Thumbnail series = false
>>
>> 16 signed bit images display completely out of range, far too  
>> bright only in
>> light grey (also with ./showinf).
>> Can we do something about it, to have "int16" stored would be  
>> correct.
>>
>> The only assumption is that every well and field has the same pixel
>> type - if you know of a case where that assumption is incorrect,
>> please let me know
>>
>> All them are signed so far.
>>
>> Thanks for your understanding,
>> Ruben
>>
>> Regards,
>> -Melissa
>>
>>
>> On Thu, Nov 26, 2009 at 11:27 AM, Rubén Muñoz <ruben.munoz at embl.de>  
>> wrote:
>>
>> Hello Melissa,
>>
>> Your ScanR importer has loaded tons of datasets in our premises. We  
>> are
>>
>> concerned that ScanR software is storing signed bit images, but  
>> part of the
>>
>> code reads:
>>
>>    reader = new MinimalTiffReader();
>>
>>    reader.setId(tiffs[0]);
>>
>>    int sizeX = reader.getSizeX();
>>
>>    int sizeY = reader.getSizeY();
>>
>>    int pixelType = reader.getPixelType();
>>
>> I cannot say how ScanR tells the sample bit representation, in this  
>> lab we
>>
>> are used to convert the images from int16 to uint16 before  
>> processing them,
>>
>> actually thats the way we keep on doing this.
>>
>> Will be more convenient if the importer would store the proper  
>> value, but I
>>
>> also would like to ask your opinion, since you are the expert.
>>
>> A different question would be if the 'real' number of bits used  
>> have a place
>>
>> in OMERO metada, for example for many microscopes this is 12 bits.
>>
>> Regards,
>>
>> --
>>
>> Rubén Muñoz
>>
>> European Molecular Biology Laboratory
>>
>>
>>
>>
>>
>>