[ome-devel] ScanR Reader

[Rubén Muñoz]

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
>>