Input files in XYZ color space are incorrecly detected as RGB which results
in incorrect output colors.
This fixes pixel format detection order (in increasing bit depth to
match libopenjpeg_matches_pix_fmt) when color space provided by
libopenjepg is unknown.
---
libavcodec/libopenjpegdec.c |
This fixes pixel values not being properly shifted in
libopenjpeg_copyto16 and libopenjpeg_copy_to_packed16 methods.
Pixel formats like xyz12le need to be shifted by AVComponentDescriptor::shift
to get the correct values.
---
libavcodec/libopenjpegdec.c |6 [32m[m[31m--[m
1 file
Input files in XYZ color space are incorrecly detected as RGB which results
in incorrect output colors.
This fixes pixel format detection order (in increasing bit depth to
match libopenjpeg_matches_pix_fmt) when color space provided by
libopenjepg is unknown.
---
libavcodec/libopenjpegdec.c |
Input files in XYZ color space are incorrecly detected as RGB which results
in incorrect output colors.
This changes pixel format detection to try XYZ before RGB when
color space provided by libopenjepg is unknown.
---
libavcodec/libopenjpegdec.c | 12 +++-
1 file changed, 7
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
On Tue, Mar 3, 2015 at 4:35 AM, Michael Bradshaw mjbs...@gmail.com wrote:
You can use the -pix_fmt option to specify the pixel format of the source.
The openjpeg decoder will try that pixel format first before iterating
through its (prioritized) list of pixel formats. That should provide a way
Overall, looks good to me. Maybe the + desc-comp[x].shift; part should be
moved inside the FFMIN macro? Seems okay as is, though.
I looked how it is implemented in jpeg200dec.c and there is no FFMIN there.
___
ffmpeg-devel mailing list
While the native jpeg2000 decoder can determine pixel format correctly
from the codestream, libopenjpeg wrapper cannot. To make sure that
the output is correct when using libopenjpeg to decode digital
cinema files, we do detection from the metadata included in the MXF
wrapper.
If the container
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
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
On Wed, Mar 4, 2015 at 4:48 PM, Michael Niedermayer michae...@gmx.at wrote:
i did not mean to suggest to leave libopenjpeg broken.
It is not technically broken, it just relies on guessing in some cases
which might not always be correct. It think there should be a warning
that this is happening
On Tue, Mar 3, 2015 at 11:40 AM, Carl Eugen Hoyos ceho...@ag.or.at wrote:
Doesn't this break rgb48 images?
No, it does not break rgb48. They are not affected by this change. Due
to the way libopenjpeg_matches_pix_fmt is implemented, rgb48 can match
xyz12, but xyz12 can not match rgb48. So the
On Tue, Mar 3, 2015 at 2:05 PM, Carl Eugen Hoyos ceho...@ag.or.at wrote:
Why don't you just move XYZ_PIXEL_FORMATS in front
of the list?
Then the rgb24/rgba would not be detected correctly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Tue, Mar 3, 2015 at 10:19 AM, Vilius Grigaliūnas
vilius.grigaliu...@gmail.com wrote:
This fixes pixel values not being properly shifted in
libopenjpeg_copyto16 and libopenjpeg_copy_to_packed16 methods.
Pixel formats like xyz12le need to be shifted by AVComponentDescriptor::shift
to get
14 matches
Mail list logo
