[ome-devel] ScanR Reader

[Rubén Muñoz]

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