multi/single channel images

[Hauke Heibel]

On Thu, May 6, 2010 at 6:45 PM, Adam Goode <agoode at andrew.cmu.edu> wrote:
> So you using single-channel fluorescence? What happens if you have more
> than 3 in the Aperio file? These types of images can have varying
> numbers of channels, yes?

The Aperio files come with an XML file with the extension .afi. That
XML file lists the actual Aperio files, one for each fluorescence. Her
is an example:

--- fila.afi ---
 <ImageList>
   <Image>
     <Path>0_DAPI.svs</Path>
     <ID>@0</ID>
   </Image>
   <Image>
     <Path>1_Cy5.svs</Path>
     <ID>@1</ID>
   </Image>
 </ImageList>
--- end file ---

> Yes, we've never done anything but brightfield so far. I would suggest
> that in the case of numcomps=1, you treat it as grayscale data and
> replicate into RGB. For numcomps=2 and others, it is not clear.

As mentioned above, it is one file per fluorescence. At least for
Aperio though I would almost bet that it is the same for other
providers. I assume so since the images are acquired one after the
other. First, you emit wave length a, then capture the image, next you
emit wave length b and capture the next image... well, and I guess the
images are not saved interleaved. That would be a whole lot of effort.

Regarding replicating the data, it is as you say below for the 12bit
images - it means we'ld truncate to 8bit. I actually did that in the
beginning and the results are rather bad. In a worst case scenario 75%
of the intensities are mapped to 255. At best rescaling though that's
really costly and not feasible if you don't know the maximum intensity
a-priori.

> This would be great. For the Hamamatsu VMU format, we have
> 12-bit-per-channel RGB. Development is ongoing in reading this format,
> but for now we are truncating to 8 bits and using the existing API.
> Moving forward, it would be nice to support an extended interface as
> well that allows for greater bit depths per channel. I could imagine
> that this could work with varying numbers of channels as well.
>
> If you open an image with 1 or 3 channels, I think the existing
> mechanism should work. If you open an image with 2 or >3 channels, maybe
> openslide_open should fail and you have to try with some new API like
> openslide_open_extended yet to be invented. I'm not familiar enough with
> fluorescence imagery to know the details.

Yeah, we probably need a new interface... I might ponder about it over
the weekend.

Cheers,
Hauke