uint16 values restricted to uint8
Posted: Wed Jan 15, 2014 10:41 am
Hi Everyone,
I am referring to the previous topic
http://www.openmicroscopy.org/community/viewtopic.php?f=13&t=7368
for a which a ticket has already been opened.
https://trac.openmicroscopy.org.uk/ome/ticket/11847
I checked the explanation given in the ticket, but I discovered that this is not the problem in our case:
The camera is a Canon EOS Rebel XSi (also EOS 450D in europe). In the specs of the camera there's an indicated datatype (bit depth) of 14 for the color of the raw files (not for jpeg, these are saved with 8), plus other 2 probably for the white balancing as it was said in the ticket. While opening the raw pics with other viewers we also get values much higher than 255 for the color, as we expect. We think that the values are just scaled to 255 somewhere in bfopen, also because this is the only software with which we got smaller values. The strange thing is that bfopen also returns uint16 as a variable type, the only thing is that they are all perfectly scaled to 255.
Has anyone an idea of what might be happening here, or did someone have this problem before?
greetings,
nico
I am referring to the previous topic
http://www.openmicroscopy.org/community/viewtopic.php?f=13&t=7368
for a which a ticket has already been opened.
https://trac.openmicroscopy.org.uk/ome/ticket/11847
I checked the explanation given in the ticket, but I discovered that this is not the problem in our case:
The camera is a Canon EOS Rebel XSi (also EOS 450D in europe). In the specs of the camera there's an indicated datatype (bit depth) of 14 for the color of the raw files (not for jpeg, these are saved with 8), plus other 2 probably for the white balancing as it was said in the ticket. While opening the raw pics with other viewers we also get values much higher than 255 for the color, as we expect. We think that the values are just scaled to 255 somewhere in bfopen, also because this is the only software with which we got smaller values. The strange thing is that bfopen also returns uint16 as a variable type, the only thing is that they are all perfectly scaled to 255.
Has anyone an idea of what might be happening here, or did someone have this problem before?
greetings,
nico