[ome-devel] ScanR importer bit representation

Melissa Linkert melissa at glencoesoftware.com
Fri Dec 11 19:03:06 GMT 2009 

Hi Ruben,

>  - The command tool bfconvert has trouble to generate a JPG:
> /Users/gonzales/Desktop/Exp1/plate_001/experiment_descriptor.xml [Olympus ScanR] -> test.jpg
> [JPEG] Exception in thread "main" loci.formats.FormatException: Floating point data not
> supported.

This is expected; your original ScanR data has 16 bits per pixel, but
Bio-Formats can only write JPEGs with 8 bits per pixel.

>  - It works to generate a PNG however, but the result is in the wrong grey range.

Exporting signed data to PNG should work if you update to the latest
trunk build.  The pixel data is converted from signed to unsigned
(since PNG does not support signed pixel types), so the pixel type of
the converted PNG will be 'uint16'.

Regards,
-Melissa

On Mon, Dec 7, 2009 at 3:19 AM, Rubén Muñoz <ruben.munoz at embl.de> wrote:
> Hi Melissa,
> Thanks you for correcting the importer.
> I have been testing the new version and its behaving as expected in the following cases:
>
>  - With the command tool showinf: displays the correct pixel signedness and the image w/ dark background (this was not happening before)
>  - OMERO importer: imports the images (was working before).
>  - OMERO web: shows the images w/ dark background (was working before).
>
> What didnt work is the format conversion (bfconvert). We do not use this functionality yet but it could represent a problem later on.
>
>  - The command tool bfconvert has trouble to generate a JPG: /Users/gonzales/Desktop/Exp1/plate_001/experiment_descriptor.xml [Olympus ScanR] -> test.jpg [JPEG] Exception in thread "main" loci.formats.FormatException: Floating point data not supported.
>
>  - It works to generate a PNG however, but the result is in the wrong grey range.
>
> ./bfconvert ~/Desktop/Exp1/plate_001/experiment_descriptor.xml test.png
> /Users/gonzales/Desktop/Exp1/plate_001/experiment_descriptor.xml [Olympus ScanR] -> test.png [Animated PNG] ................................................................................................................................................................................................................................................................................................................................................................................................ [done]
> 156.55s elapsed (98.78906+300.77603ms per plane, 2866ms overhead)
>
> Do you know if ss the format conversion something that is aware of the signedness? Is the data transformed first to unsigned when the input format is signed?
>
> What we do when we didn't have bioformats was to process the signed images to unsigned first.
>
> Regards,
>
> --
> Rubén Muñoz
> European Molecular Biology Laboratory
>
>
>
> On Dec 3, 2009, at 8:54 PM, Melissa Linkert wrote:
>
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

More information about the ome-devel mailing list