[FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection

Michael Niedermayer michaelni at gmx.at
Wed Mar 4 15:48:24 CET 2015

On Wed, Mar 04, 2015 at 04:10:39PM +0200, Vilius Grigaliūnas wrote:
> 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.

i did not mean to suggest to leave libopenjpeg broken.
Just that in every case our native decoders replaced external wrapers.
If this happens with libopenjpeg too, all work on the wraper will be
in vain as it will not be used anymore after some point.
so i was imlpicitly thinking a bit ahead like " waht will be there
in the long term, lets concentrate work on that rather than the
short term"
but by all means if you like improvig the libopenjpeg wraper, do so

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150304/ab1a07a5/attachment.asc>

More information about the ffmpeg-devel mailing list