trac tickets and alternative build system

[Adam Goode]

On 05/06/2010 10:43 AM, Hauke Heibel wrote:
> Well, I think the CMake conversion/integration is done. Everything
> seems to work now and (after some hacking) I managed to load my first
> slides.
> 

Nice!

> The issue is that I am working with fluorescence slides. I mentioned
> earlier that I received the "image->numcomps != 3" error and that is
> exactly the reason. Aperio stores fluorescence slides with a single
> 10bit component and compression mode APERIO_COMPRESSION_JP2K_RGB. What
> is possible to do in this case is to read the data in
> 'aperio_tiff_tilereader(...)' via:
> 

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?

> dest[i] = comps[0].data[(y / c0_sub_y) * comps[0].w + (x / c0_sub_x)];
> 
> and the 'dest' output of openslide_read_region could then be e.g. read
> out like this:
> 
> float value = 0x0000ffff & dest[idx];
> 
> I know, this is pretty hackish and also not the most efficient since
> internally OpenSlide seems to do some RGBA related stuff.
> 

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.

> Long-term I will need this functionality and instead of reimplementing
> everything from scratch I will try to modify OpenSlide. In case you
> have ideas and some proposals, I would be glad to discuss about them.
> Hopefully, I will be able to implement the required changes such that
> eventually they will find their way into OpenSlide.

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.

I made a ticket for this:
http://openslide.cs.cmu.edu/ticket/48


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/0b9e5fb6/attachment.bin