Hi Vincent,
Vincent Povirk vincent@codeweavers.com wrote:
I'm not sure about this. According to MSDN, decoders are supposed to do the decoding incrementally in CopyPixels, assuming the user reads rows from the top. In theory, the other decoders that do all the work in Initialize should be changed to do it this way.
Can you explain why this change fixes the problem you observed? Is libjpeg broken? Are we using the API incorrectly? Could there be a memory bug somewhere else causing strange behavior?
It was quite a bit of time ago when I was looking into this, so I may not recall all the details. This patch fixed several problems: first one is with decoding the JPEG data, and that was a real bug causing corrupted images being produced, and I haven't digged into the source of it inside of libjpeg; another one is that Initialize() doesn't really try to decode the image data, and that leads to CopyPixels() failures later on when it's not really expected (e.g. for broken images), and that also makes QueryCapability() report success while subsequent CopyPixels() fails. I have a test program that converts any WIC image to other WIC formats to test converting images from many different sources (mainly from libtiff/libjpeg samples) and that was one of the problems found during my testing.