On Wed, Mar 4, 2015 at 10:08 AM, Vilius Grigaliūnas <vilius.grigaliu...@gmail.com> wrote: > On Wed, Mar 4, 2015 at 1:03 AM, Michael Niedermayer <michae...@gmx.at> wrote: >> this detects codestreams_profile0/p0_08.j2k as xyz, is this intended? > > No, this seems to be a regression. At the moment there is not enough > information in openjpeg data structures (opj_image_t specifically) to > reliably determine whether given image is is 12-bit XYZ or 12-bit > RGB. I do not know how the best way to handle this case. Unless we can > find some additional way to determine this, one of these cases will be > broken.
AFAIK there is no way to reliably determine color space just from naked J2K codestream. It basically boils down to a guess. In my opinion assuming that the value is 12-bit XYZ is just as valid as 12-bit RBG. I think in cases like this there should be a way to a pass pixel format value as input option. The way I understand jpeg2000 standard, XYZ interpretation would be more correct unless JP2 header or other source indicates otherwise. But I see how this would lead to mostly unexpected behavior in a lot of real-world cases. On Wed, Mar 4, 2015 at 12:10 PM, Michael Niedermayer <michae...@gmx.at> wrote: > the best way would be to improve our jpeg2000 decoder so its at least > as good as libopenjpeg then it can be used and it would have access > to everything from the bitstream to determine the colorspace ... That would be great, but that does not mean that we should leave libopenjpeg decoder broken in specific cases (as in Digital Cinema which is one of the main use cases for JPEG200). I still see the utility in having it as it will have wider format support for the foreseeable future. Native jpeg2000 only uses xyz pixels if it detects that the file in Digital Cinema profile (RSiz = 3 or RSiz = 4). While libopenjpeg does not expose this, it is also stored in MXF container which is the standard wrapper for DC j2k streams. That means we can detect xyz pixels in avformat/mxfdec and pass it to decoder. Which might be an even better solution. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel