[ome-devel] ScanR importer bit representation

[Melissa Linkert]

Hi Ruben,

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

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.

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