[ome-users] Bits per pixel
Jason Swedlow
jason at lifesci.dundee.ac.uk
Wed Jul 13 13:33:44 BST 2011
Hi Mark-
We discussed this at our Tuesday mtg yesterday. There's alot here, but to summarise:
1. It's very easy for us to update Detector with the dynamic range used in the A/D conversion. We can express this value in bits, so the full dynamic range of the ADU would be 12 bits, or 2**12, or 4096.
2. Putting this value on the Pixels invokes lots (and lots and lots) of issues. Rarely is the dynamic range (DR) of the **signal** (and thus the Pixels) the full dynamic range of the ADU. This value, properly stated, includes consideration of the saturation value (full well depth on CCDs), read noise, any other systematic noise, and even, if we're being rigorous, the Poisson variation on the signal (so-called "counted events"). Formally, this amounts to calculating the real number of detected photoelectrons and dividing by the square root of the sum of the squares of the individual noise sources. We're assuming this is not the value you want, and instead, simply what we've stated in (1) above.
If (1) is acceptable, let us know, and we'll let you know whether we can jam this is 4.3.2. Note this would entail a database upgrade, which violates a rule on point releases. But if you need this badly, say so.
Cheers,
Jason
On 7 Jul 2011, at 17:43, Mark Woodbridge wrote:
> 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
>>
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
**************************
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) 385819
Intl phone: 44 1382 385819
FAX (01382) 388072
email: jason at lifesci.dundee.ac.uk
Lab Page: http://gre.lifesci.dundee.ac.uk/staff/jason_swedlow.html
Open Microscopy Environment: http://openmicroscopy.org
**************************
The University of Dundee is a Scottish Registered Charity, No. SC015096.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-users/attachments/20110713/73fe516d/attachment.html>
More information about the ome-users
mailing list