On Wed, Mar 04, 2015 at 05:07:17PM +0200, Vilius Grigaliūnas wrote:
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
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 04, 2015 at 10:08:56AM +0200, Vilius Grigaliūnas 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
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.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
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
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 3:04 AM, Vilius Grigaliūnas
vilius.grigaliu...@gmail.com wrote:
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
On Tue, Mar 3, 2015 at 1:19 AM, Vilius Grigaliūnas
vilius.grigaliu...@gmail.com wrote:
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
On Tue, Mar 03, 2015 at 10:19:48AM +0200, Vilius Grigaliūnas wrote:
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
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
Vilius Grigaliūnas vilius.grigaliunas at gmail.com writes:
static const enum AVPixelFormat libopenjpeg_all_pix_fmts[] = {
-RGB_PIXEL_FORMATS, GRAY_PIXEL_FORMATS,
YUV_PIXEL_FORMATS, XYZ_PIXEL_FORMATS
+AV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA, XYZ_PIXEL_FORMATS,
AV_PIX_FMT_RGB48,
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
Vilius Grigaliūnas vilius.grigaliunas at gmail.com writes:
Input files in XYZ color space are incorrecly detected
as RGB which results in incorrect output colors.
Doesn't this break rgb48 images?
Could you explain how I can reproduce your issue?
Carl Eugen
13 matches
Mail list logo
