[ome-devel] ScanR importer bit representation

[Melissa Linkert]

Hi Ruben,

> I have one more concern about bioformats, which is again ScanR specific.
> It is great that the importer currently supports different not labelled
> layouts:
*snip*
> There's in fact a third layout (LabTek) which is 12 rows and 32 columns.
> At the moment this layout is importing because the wells are labeled: A1 to L32

I'm not opposed to adding support for 32 x 12 plates; the only issue
is how to detect that the plate is 32 x 12 if the wells are not
labeled.  I haven't been able to find anything in the
experiment_descriptor.xml files (aside from the optional well labels)
that indicates the layout of the plate - are you aware of any other
way to determine the plate dimensions?

If not, then there is no way to differentiate between unlabeled 32 x
12 plates and unlabeled 16 x 24 plates, since the only information we
have is that there are 384 wells.

>  - Would it possible to detect the LabTek layout and apply a different
> naming convention?

The latest trunk build has the naming convention swapped for plates
with more than 26 rows.

>  - In addition would it be possible to give the Spot number (1 - 384) to the
> well name for that particular layout? (something like store.setImageName(new
> String(i), i);)

The latest trunk build includes the spot number in the Image name, so
now you should have names like "Well A1, Field 1 (Spot 1)".  I'd
really prefer not to use the spot number on it's own, but can make
minor adjustments to the name formatting if you would like.

> I think that these are minor changes but I could upload corresponding
> datasets (from LabTeks) under request.

It would really help to have at least two datasets that were acquired
with a LabTek plate - one with labeled wells, and one with unlabeled
wells.

Regards,
-Melissa

On Wed, Dec 16, 2009 at 3:53 AM, Rubén Muñoz <ruben.munoz at embl.de> wrote:
> Hi Ruben,
>
>
> Hi Melissa
>
> This is expected; your original ScanR data has 16 bits per pixel, but
> Bio-Formats can only write JPEGs with 8 bits per pixel.
>
> That's very fine because we do not want to loose quality during the
> conversion.
>
> Exporting signed data to PNG should work if you update to the latest
> trunk build.  The pixel data is converted from signed to unsigned
> (since PNG does not support signed pixel types), so the pixel type of
> the converted PNG will be 'uint16'.
>
> Tried this, the results was very satisfactory. :)
> I have one more concern about bioformats, which is again ScanR specific.
> It is great that the importer currently supports different not labelled
> layouts:
> if (wellRows * wellColumns == 0) {
>       if (wellLabels.size() <= 96) {
>         wellColumns = 12;
>       }
>       else if (wellLabels.size() <= 384) {
>         wellColumns = 24;
>       }
>       wellRows = wellLabels.size() / wellColumns;
>       if (wellRows * wellColumns < wellLabels.size()) wellRows++;
> }
> There's in fact a third layout (LabTek) which is 12 rows and 32 columns. At
> the moment this layout is importing because the wells are labeled: A1 to L32
> You may notice that the naming convention is the opposite for this layout.
> Below is the current ScanR naming convention:
> store.setPlateRowNamingConvention("A", 0);
> store.setPlateColumnNamingConvention("1", 0);
>  - Would it possible to detect the LabTek layout and apply a different
> naming convention? A I said, it has different number of columns and rows
> than the normal 384 Plates.
>  - In addition would it be possible to give the Spot number (1 - 384) to the
> well name for that particular layout? (something like store.setImageName(new
> String(i), i);)
> I think that these are minor changes but I could upload corresponding
> datasets (from LabTeks) under request. By now I attach an
> experiment_descriptor.xml for one of this 384 LabTeks.
>
>
>
> Sincerely grateful.
> Merry christmas!
> Rubén
>
> Regards,
> -Melissa
>
>
>