[ome-users] Bits per pixel

Mark Woodbridge m.woodbridge at imperial.ac.uk
Thu Jun 30 17:31:40 BST 2011


Admittedly, I don't understand the intricacies of this (particularly 
"valid" bpp vs pixeltype) but it does seem that OMERO should somehow 
record the fact that I imported 12-bit data, especially as Bio-Formats 
is able to extract this information.

On 30/06/11 17:23, Curtis Rueden wrote:
> Hi everyone,
>
>     I might try to pull the original metadata from OMERO ("DataChannel #
>     Bits Per Sample") to get the real depth, or make a guess based on
>     the min/max values unless anyone has a more elegant solution.
>
>
> This idea of "valid bits per pixel" comes up a fair amount, and is
> distinct from the storage bit depth—particularly for 12-bit data.
> Bio-Formats already supports reporting this information:
>
> /**
> * Gets the number of valid bits per pixel. The number of valid bits per
> * pixel is always less than or equal to the number of bits per pixel
> * that correspond to {@link #getPixelType()}.
> */
> int getBitsPerPixel();
>
> Perhaps we should add a field to the OME-XML schema to record this value
> in a standard way?
>
> Regards,
> Curtis
>
> On Thu, Jun 23, 2011 at 10:54 AM, Mark Woodbridge
> <m.woodbridge at imperial.ac.uk <mailto:m.woodbridge at imperial.ac.uk>> wrote:
>
>     Ok. It's using uint16. I think all our Zeiss images are 12-bit.
>
>     I'm not sure whether it's safe to use min/max because if the
>     exported images are used in batch processing then each image will
>     have a different range.
>
>     I might try to pull the original metadata from OMERO ("DataChannel #
>     Bits Per Sample") to get the real depth, or make a guess based on
>     the min/max values unless anyone has a more elegant solution.
>
>     Similarly (but less important), is there a way to specify the bit
>     depth when using renderingEngine.__renderProjectedAsPackedInt so
>     that I can produce a 12 bit (rather than 8 bit) tiff?
>
>     Mark.
>
>
>     On 23/06/11 16:40, Will Moore wrote:
>
>         Hi Mark,
>
>         I have an idea what the problem is:
>         OMERO doesn't support 12 bits:
>
>         omero=# select * from pixelstype;
>         id | permissions | value | external_id | bitsize
>         ----+-------------+-----------__-----+-------------+---------
>         1 | -35 | bit | | 1
>         2 | -35 | int8 | | 8
>         5 | -35 | uint8 | | 8
>         3 | -35 | int16 | | 16
>         4 | -35 | int32 | | 32
>         6 | -35 | uint16 | | 32
>         7 | -35 | uint32 | | 32
>         8 | -35 | float | | 32
>         9 | -35 | double | | 64
>         10 | -35 | complex | | 64
>         11 | -35 | double-complex | | 128
>         (11 rows)
>
>
>         Can you see what's the pixels type in the database for those images
>         E.g. psql using imageId...
>         # select * from pixelstype where id = (select pixelstype from pixels
>         where image=9986);
>         (or maybe it's displayed in Insight too)?
>
>         Probably 16 bits??
>
>         Not sure what your best solution is here.
>         I guess you've not seen this before since you haven't processed
>         any 12
>         bit images before?
>
>         Not sure the best strategy here.
>         Would it work for you to simply use the min and max pixel values of
>         the source image, same as Insight is doing with Min/Max?
>
>
>         Will.
>
>
>
>         On 23 Jun 2011, at 16:08, Mark Woodbridge wrote:
>
>             Hi,
>
>             I have a set of lsm files. Bio-Formats showinf says that
>             they have
>             'Valid bits per pixel = 12'. But when I go to Preview> Full
>             Range
>             in Insight it sets the maximum to 65535, even though Min/Max
>             gives
>             0-4095 (as I would expect).
>
>             Is this correct? I have an export script that uses
>             renderingEngine.__getPixelsTypeUpperBound to set the channel
>             window
>             for projection and it similarly returns 65535, meaning that the
>             resultant projection is very dark.
>
>             Mark.
>
>             _________________________________________________
>             ome-users mailing list
>             ome-users at lists.__openmicroscopy.org.uk
>             <mailto:ome-users at lists.openmicroscopy.org.uk>
>             http://lists.openmicroscopy.__org.uk/mailman/listinfo/ome-__users
>             <http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users>
>
>
>         William Moore
>         Wellcome Trust Centre for Gene Regulation& Expression
>         College of Life Sciences
>         MSI/WTB/JBC Complex
>         University of Dundee
>         Dow Street
>         Dundee DD1 5EH
>         United Kingdom
>
>         Phone 01382 386364
>         http://openmicroscopy.org
>
>
>
>
>
>     _________________________________________________
>     ome-users mailing list
>     ome-users at lists.__openmicroscopy.org.uk
>     <mailto:ome-users at lists.openmicroscopy.org.uk>
>     http://lists.openmicroscopy.__org.uk/mailman/listinfo/ome-__users
>     <http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users>
>
>



More information about the ome-users mailing list