[ome-devel] ScanR Reader

[Melissa Linkert]

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.

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
>