[ome-users] Bits per pixel

Mark Woodbridge m.woodbridge at imperial.ac.uk
Thu Jul 7 17:43:14 BST 2011


Thanks Chris. It would be great if you could cc me if/when you create a 
ticket for this.

On 07/07/11 17:07, Chris Allan wrote:
> Hi Mark,
>
> We likely should but we currently don't have a place to and the stack is unable to action the information in any way. Andrew is going to put this on the roadmap for potential inclusion in 4.3.2 as we need model, database, server and clients to take advantage of this metadata.
>
> -Chris
>
> On 30 Jun 2011, at 17:31, Mark Woodbridge wrote:
>
>> 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>
>>>
>>>
>> _______________________________________________
>> ome-users mailing list
>> ome-users at lists.openmicroscopy.org.uk
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
>



More information about the ome-users mailing list