[ome-devel] ScanR Reader
Rubén Muñoz
ruben.munoz at embl.de
Wed Aug 25 10:01:14 BST 2010
Hi Melissa,
I have subtracted the values of all the pixels for one example in the original and the OME.TIF format.
The difference is a constant which means that there was no information loss.
The constant is a power of 2, which means that only one bit was changed.
Therefore, the implemented algorithm does exactly what we wanted.
Thanks for your time in solving this issue.
While testing this, we had to comment a couple of lines out from ImageConverter.java. To enable the multiple OME.TIF export.
Are they still necessary?
//if (format.equals("OME-TIFF") &&
// (out.indexOf(FormatTools.SERIES_NUM) > 0 ||
// out.indexOf(FormatTools.SERIES_NAME) > 0 ||
// out.indexOf(FormatTools.CHANNEL_NUM) > 0 ||
// out.indexOf(FormatTools.CHANNEL_NAME) > 0 ||
// out.indexOf(FormatTools.Z_NUM) > 0 ||
// out.indexOf(FormatTools.T_NUM) > 0))
// {
// // FIXME
// LOGGER.info(
// "Sorry, conversion to multiple OME-TIFF files is not yet supported.");
// return false;
// }
Best regards,
Rubén
On Aug 23, 2010, at 11:57 PM, Melissa Linkert wrote:
> Hi Rubén,
>
>> My colleague found out that ScanR's sign is at the 12th bit. So he applied the mask to the x0F to the 4th bit of the second byte. That's the 12th bit (little endian).
>
> That would explain it - the sign bit is generally assumed to be the 16th
> bit.
>
> r6838 should mask out the 12th bit (and takes endianness into account); can you
> please give that a try and see if it works for you? On one of the ScanR
> datasets that you sent previously, r6837 gave pixel values between 33362 and
> 32930 while r6838 gives pixel values between 594 and 495. This seems correct to
> me, but please let me know if I am mistaken.
>
> Regards,
> -Melissa
>
> On Thu, Aug 19, 2010 at 10:02:24AM +0200, Rubén Muñoz wrote:
>> Hi Melissa,
>>
>> Thanks for your e-mail. Sorry, but the signed images are not being transformed to unsigned yet. I updated and tested but still get pixels over 32768.
>> I agree that the changes should apply to the ScanR reader, but the software didn't replace the sign, so we changed it directly when writing the image.
>>
>> My colleague found out that ScanR's sign is at the 12th bit. So he applied the mask to the x0F to the 4th bit of the second byte. That's the 12th bit (little endian).
>>
>> Kota: please correct me if I am wrong.
>>
>> Could it be that the writter didn't detect the sign because of not being at the 16th position? Is there a way to mask the data at the ScanR reader?
>>
>> Thanks for your patience with this topic. It has a long history.
>>
>> Best regards,
>>
>> Ruben
>>
>> On Aug 18, 2010, at 9:14 PM, Melissa Linkert wrote:
>>
>>> Hi Rubén,
>>>
>>>> The answer is 3) The pixel type is always unsigned. The sign is set by National Instruments NI-IMAQ, which is the driver used by ScanR to store the images.
>>>> There's a document explaining this at http://digital.ni.com/public.nsf/allkb/3C727E03F004EA528625714900706CA0
>>>
>>> Fair enough. The latest trunk build (r6810) should fix this.
>>>
>>>> A colleague of mine introduced some code in ImageConverter fixing this issue.
>>> *snipped code*
>>>
>>> I really wouldn't recommend fixing the problem in this way for a few
>>> reasons:
>>
>>>
>>> 1) It assumes that the data being converted is 16-bit. That's fine if
>>> you are only working with ScanR data, but it will cause problems if you
>>> are working with other formats.
>>
>> Yes, the fix should affects to the ScanR, and the problem resides in the signness of the bytes but my colleague found the following problem.
>>
>>>
>>> 2) It assumes that the data is little-endian; again, this is probably
>>> fine for ScanR, but will cause a problem for other formats.
>>>
>>> 3) Some formats do legitimately have signed pixel values, in which case you
>>> shouldn't convert the values to unsigned.
>>>
>>> In general, it's best to resolve format-specific problems in the reader
>>> for that format.
>>>
>>> Regards,
>>> -Melissa
>>>
>>> On Wed, Aug 18, 2010 at 04:50:04PM +0200, Rubén Muñoz wrote:
>>>> Hi Melissa
>>>>
>>>> Sorry for the late reply.
>>>> The answer is 3) The pixel type is always unsigned. The sign is set by National Instruments NI-IMAQ, which is the driver used by ScanR to store the images.
>>>> There's a document explaining this at http://digital.ni.com/public.nsf/allkb/3C727E03F004EA528625714900706CA0
>>>>
>>>> I have tried to change your code myself:
>>>>
>>>> case FormatTools.INT16:
>>>> pixelType = FormatTools.UINT16;
>>>> break;
>>>> case FormatTools.UINT16:
>>>> pixelType = FormatTools.INT16;
>>>> break;
>>>>
>>>> To:
>>>>
>>>> case FormatTools.INT16:
>>>> pixelType = FormatTools.INT16;
>>>> break;
>>>> case FormatTools.UINT16:
>>>> pixelType = FormatTools.UINT16;
>>>> break;
>>>>
>>>> But, none of them is producing unsigned OME.TIF images with bfconvert. I do not know if the TIFF writer can transform the data in such a way.
>>>>
>>>> A colleague of mine introduced some code in ImageConverter fixing this issue.
>>>>
>>>> long s = System.currentTimeMillis();
>>>> byte[] buf = reader.openBytes(i);
>>>>
>>>> ...
>>>>
>>>> convert12bitTo16bit(buf);
>>>> writer.saveBytes(i, buf);
>>>>
>>>> Where:
>>>>
>>>> public static void convert12bitTo16bit(byte[] buf){
>>>> for (int i = 0; i < buf.length; i += 2)
>>>> buf[i+1] = (byte)(buf[i+1] & 0x0F);
>>>> }
>>>>
>>>> He stands that the images take values in 12 bit little endian range, so removes the sign with the mask.
>>>>
>>>> I hope the following information helps, at least it clarifies the problem.
>>>>
>>>> Best regards,
>>>>
>>>> Rubén
>>>>
>>>> On Aug 13, 2010, at 4:54 PM, Melissa Linkert wrote:
>>>>
>>>>> Hi Rubén,
>>>>>
>>>>>> However bfconvert seems to keep the signedness upon conversion. This is, the resulting OME.TIFFs are signed 16 bit like the raw data.
>>>>>
>>>>> That's right. Reading through this thread from last year:
>>>>>
>>>>> http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2009-November/001517.html
>>>>>
>>>>> it looks like you had originally asked to have the the pixel type
>>>>> recorded as signed 16-bit, even if the raw files contain unsigned 16-bit
>>>>> data. Changing that is relatively easy, but I want to make certain that
>>>>> we are both clear on how the pixel type needs to be recorded.
>>>>> Basically, we need to make a final decision between these options:
>>>>>
>>>>> 1) The pixel type of the ScanR dataset always matches the pixel type in
>>>>> each of the TIFF files.
>>>>>
>>>>> 2) The pixel type of the ScanR dataset always has the opposite sign of
>>>>> the pixel type in each of the TIFF files.
>>>>>
>>>>> 3) The pixel type is always unsigned.
>>>>>
>>>>> 4) The pixel type is always signed.
>>>>>
>>>>> (1) is my personal preference, and (2) is what we are using now. If you
>>>>> could clarify which option is preferable to you, that would be very helpful.
>>>>>
>>>>> Regards,
>>>>> -Melissa
>>>>>
>>>>> On Thu, Aug 12, 2010 at 11:00:46AM +0200, Rubén Muñoz wrote:
>>>>>> Hi Melissa,
>>>>>> I have one more question regarding the ScanR format. Hope that you can dedicate a bit more time to this.
>>>>>> As you know, Bioformats Exporter plugin its creating unsigned 16 bits images out of ScanR slices. That's appreciated.
>>>>>>
>>>>>> However bfconvert seems to keep the signedness upon conversion. This is, the resulting OME.TIFFs are signed 16 bit like the raw data.
>>>>>> Is this configurable. Could one have unsigned bytes by default in OME.TIF. Signed pixels have no advantage I guess.
>>>>>>
>>>>>> Thanks a lot.
>>>>>>
>>>>>> Rubén
>>>>
>>
More information about the ome-devel
mailing list