multi/single channel images

[Adam Goode]

On 05/06/2010 01:29 PM, Hauke Heibel wrote:
> 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 ---
> 

Ah, that makes some sense. I guess we would have another mechanism for
opening .afi files which internally opens multiple svs files. I think we
would want to have a mechanism for getting the names of channels from
the XML. It might be worth examining the API documentation for Aperio's
system, to see what interfaces they provide for this.

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

For the VMU format, we have 16-bit values but from a header we know the
data is 12-bit. Is scaling expensive? Wouldn't we just right shift by 4
for each pixel? You're right that you cannot do this if you don't know
the max intensity.

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

Ok, sounds good. Keeping with the string-based "properties" and
"associated images" mechanisms currently in OpenSlide, I think having
named "channels" might also be good.

By the way, I sense the number of dimensions growing here, we already
have layers, associated images, now channels and possibly focal planes
(from a different Hamamatsu format)! Have to be careful to manage the
complexity.



Adam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20100506/25542b8c/attachment.bin