[FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection
Vilius Grigaliūnas
vilius.grigaliunas at gmail.com
Wed Mar 4 15:10:39 CET 2015
On Wed, Mar 4, 2015 at 10:08 AM, Vilius Grigaliūnas
<vilius.grigaliunas at gmail.com> wrote:
> On Wed, Mar 4, 2015 at 1:03 AM, Michael Niedermayer <michaelni at 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 <michaelni at 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.
More information about the ffmpeg-devel
mailing list