The reason for this change is that the native jpeg2000 decoder does not yet support 4K digital cinema files (#2586). The workaround for that is to use libopenjpeg decoder, which sort of works but incorrectly detects pixel format as rgb48le instead of xyz12le. This produces wrong colors in the output. This patch basically fixes the issue so that the correct output is produced when using libopenjpeg decoder. I should have included this in commit message.
On Tue, Mar 3, 2015 at 12:49 AM, Michael Bradshaw <mjbs...@gmail.com> wrote: > Is this really desirable, though? The most common case should be the > default. If XYZ is the most common use case for ffmpeg/avcodec users, then > sure, this is good. But I'm not convinced XYZ is more common than RGB. I > believe RGB is more common than XYZ, and as such should remain the default. This only affects cases where openjpeg did not detect color space (CLRSPC_UNKNOWN) as it is most likely to be in XYZ. As far as I have figured out, openjpeg does not have proper detection for XYZ images, it decodes them all right, but the information coming from their API is just not there. When the image is in RGB, openjpeg should detect it as CLRSPC_SRGB and the behavior has not changed here. I have tested this with several files and the results were correct in all cases. > This small cleanup/micro optimization is better in a different patch. It > seems unrelated to testing XYZ before RGB. Same for the similar change to > libopenjpeg_copyto16(). This is not an optimization, but a fix for a bug. It fixes the pixel value shift for xyz12le pixel format so that the values are properly aligned. It is not as much a detection issue, but the correct detection exposed it. I think there was no way to hit it before due to incorrect pixel format detection as rgb48le does not need bit shifts but xyz12le does. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel