[ome-devel] ScanR importer bit representation

[Melissa Linkert]

Hi Ruben,

Thank you for sending additional information.

My suspicion is that the ScanR software has the pixel signedness
reversed, i.e. if the pixels are signed the pixel type is set to
unsigned and vice versa.  If you have ImageMagick installed and run
this command:

$ tiffinfo 280809_8wellLT_008/data/A1--W00001--P00001--Z00000--T00001--dapi.tif
TIFF Directory at offset 0x2a0008 (2752520)
  Image Width: 1344 Image Length: 1024
  Resolution: 1, 1 (unitless)
  Bits/Sample: 16
  Sample Format: unsigned integer
  Compression Scheme: None
  Photometric Interpretation: min-is-black
  FillOrder: msb-to-lsb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 1024
  Planar Configuration: single image plane
  Software: National Instruments IMAQ

...you can see that the pixel type stored in the TIFFs is definitely
uint16.  I couldn't find anything in the experiment_descriptor.xml
file that indicated whether or not the pixels are signed.

For now, all of the datasets that you have sent so far will be
detected as int16 if you use the latest trunk build.  To verify that
the new pixel type detection logic is correct, it would help to have a
few datasets of different pixel types - e.g. int8, uint8, and uint16.
Does the ScanR software allow you to choose the bit depth/sign of the
pixel data?

Regards,
-Melissa

On Tue, Dec 1, 2009 at 2:44 AM, Rubén Muñoz <ruben.munoz at embl.de> wrote:
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>
>