Color-/Lineshifts under Windows?

[Adam Goode]

On 08/07/2010 04:23 PM, Hauke Heibel wrote:
> Hi,
> 
> I tried to debug this but did not succeed but want to let you know
> about my findings. I thought the error might be coming from
> openslide-ops-jpeg.h so I reverted to file to the oldest version being
> windows compatible and nothing changed. I double checked, that the
> jpeg is correctly read by the function read_from_one_jpeg(...) and
> that seems to be the case. It is though funny, that three different
> programs (xnview, photoshop, openslide resp. jpeglib) give me three
> different results when it comes to the color of pixel (48,204) of the
> file Data0014.dat - no clue why this should and could happen.
> 

How different are the values? You may be seeing the result of color
correction. Also, Photoshop almost certainly uses a different JPEG
library, and will result in slight variations in individual pixels.

> The file test7-09.ppm is generated from Data0014.dat. I saved the
> Data0014.dat as a proper jpeg and loaded Data0014.jpeg and
> test07-09.ppm into Gimp and tried to overlay the two files - it is
> impossible. The problem is that even the shape of the cells changed in
> test7-09.ppm and not only the colors.
> 

Can you try with the MIRAX viewer? I think it will output similar
dimensions to OpenSlide. MIRAX on-disk storage is unusual in this way.
(I will try to explain later.)

> I am not yet sure how to properly debug in OpenSlide since I am always
> a bit confused about where the actual data is written to the
> destination buffer? Is it in read_tile? Do I understand correctly,
> that read_tile is writing one tile to the destination buffer?
> 

Things start with paint_region. This calls the helper
_openslide_read_tiles which strides across the buffers and does the
painting. It does this by calling the callback read_tile.

In the JPEG backend, read_tile is in charge of calling into
read_from_one_jpeg if the tile is not already in the cache. Ultimately,
the tile is painted into the cairo_t that is passed in.

> A last thing I tried is that I changed the call to
> cairo_image_surface_create_for_data(...) in the function read_tile.
> The color format was set to CAIRO_FORMAT_RGB24 and I was thinking
> CAIRO_FORMAT_RGBA24 would be better, since actually, the data is RGBA,
> right?

Well, JPEG is only 3 channel, so there is a slight performance
improvement to store the JPEG tiles as RGB24 (but no storage
improvement). The destination surface is ARGB32 though.

> 
> That's all I could come up with so far.
> 
> Regards,
> Hauke
> 
> 2010/8/4 Marco Feuerstein <feuerste at cs.tum.edu>:
>> Adam,
>> thanks for looking into that problem.
>> I hope you can fix it easily. Please let me know if I can test anything here.
>> Marco
>>
>>> -----Original Message-----
>>> From: Adam Goode [mailto:agoode at andrew.cmu.edu]
>>> Sent: Mittwoch, 4. August 2010 03:06
>>> To: Marco Feuerstein
>>> Cc: openslide-users at lists.andrew.cmu.edu
>>> Subject: Re: Color-/Lineshifts under Windows?
>>>
>>> Marco,
>>>
>>> Glad it fixes the problem, at least partially. On Windows I never run
>>> test.c so I never see this.
>>>
>>> The black dots are more troubling, Mirax is a difficult format to
>>> render, and I have had many such bugs like this in the past. After
>>> trying it, I do see the dots on Linux.
>>>
>>> I think I know why the dots are visible now and not before, I will try
>>> to look into it. At the very least, I will record a bug. :)
>>>
>>>
>>> Thanks,
>>>
>>> Adam
>>
>> _______________________________________________
>> openslide-users mailing list
>> openslide-users at lists.andrew.cmu.edu
>> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
>>
> 


-------------- 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/20100809/d572541c/attachment.bin