| Message ID | CAB0OVGrU5qF+V3TfjuB-2XSAXRKNjWU3bRi+3zsGq=ZDVjKcRA@mail.gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>> Fixes #4409. >>>>>> >>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>> --- >>>>>> libavcodec/dpx.c | 3 ++- >>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c >>>>>> index 538a1b9943..04b55ffadf 100644 >>>>>> --- a/libavcodec/dpx.c >>>>>> +++ b/libavcodec/dpx.c >>>>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx, >>>>>> read10in32(&buf, &rgbBuffer, >>>>>> &n_datum, endian, shift); >>>>>> } >>>>>> - n_datum = 0; >>>>>> + if (packing != 2) >>>>>> + n_datum = 0; >>>>>> for (i = 0; i < elements; i++) >>>>>> ptr[i] += p->linesize[i]; >>>>>> } >>>>> >>>>> This breaks decoding the output of the following command: >>>>> $ gm convert converted_image_gets_skewed.dpx -define >>>>> dpx:packing-method=b out.dpx >>>> >>>> I do not trust that app, its full of bugs. >>> >>> What is the reference for dpx in your opinion? >> >> ImageTragick certainly not. > > That's not ImageMagick above. Then what is it? > > The sample in question looks better with attached poc, breaks > four component sample, also attaching other samples that > show the difference. Attacking crappy patches and non-compliant files that conflict and do not follow specification is not productive.
2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>: > On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>> Fixes #4409. >>>>>>> >>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>> --- >>>>>>> libavcodec/dpx.c | 3 ++- >>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c >>>>>>> index 538a1b9943..04b55ffadf 100644 >>>>>>> --- a/libavcodec/dpx.c >>>>>>> +++ b/libavcodec/dpx.c >>>>>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx, >>>>>>> read10in32(&buf, &rgbBuffer, >>>>>>> &n_datum, endian, shift); >>>>>>> } >>>>>>> - n_datum = 0; >>>>>>> + if (packing != 2) >>>>>>> + n_datum = 0; >>>>>>> for (i = 0; i < elements; i++) >>>>>>> ptr[i] += p->linesize[i]; >>>>>>> } >>>>>> >>>>>> This breaks decoding the output of the following command: >>>>>> $ gm convert converted_image_gets_skewed.dpx -define >>>>>> dpx:packing-method=b out.dpx >>>>> >>>>> I do not trust that app, its full of bugs. >>>> >>>> What is the reference for dpx in your opinion? >>> >>> ImageTragick certainly not. >> >> That's not ImageMagick above. > > Then what is it? GraphicsMagick which claims to be the dpx reference (afaiu). >> The sample in question looks better with attached poc, breaks >> four component sample, also attaching other samples that >> show the difference. > > Attacking crappy patches and non-compliant files that Do you know of a 10bit gray dpx sample that does not look better with my "crappy" patch? > conflict and do not follow specification is not productive. GraphicsMagick claims differently. Carl Eugen
On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>> Fixes #4409. >>>>>>>> >>>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>>> --- >>>>>>>> libavcodec/dpx.c | 3 ++- >>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>>>> >>>>>>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c >>>>>>>> index 538a1b9943..04b55ffadf 100644 >>>>>>>> --- a/libavcodec/dpx.c >>>>>>>> +++ b/libavcodec/dpx.c >>>>>>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx, >>>>>>>> read10in32(&buf, &rgbBuffer, >>>>>>>> &n_datum, endian, shift); >>>>>>>> } >>>>>>>> - n_datum = 0; >>>>>>>> + if (packing != 2) >>>>>>>> + n_datum = 0; >>>>>>>> for (i = 0; i < elements; i++) >>>>>>>> ptr[i] += p->linesize[i]; >>>>>>>> } >>>>>>> >>>>>>> This breaks decoding the output of the following command: >>>>>>> $ gm convert converted_image_gets_skewed.dpx -define >>>>>>> dpx:packing-method=b out.dpx >>>>>> >>>>>> I do not trust that app, its full of bugs. >>>>> >>>>> What is the reference for dpx in your opinion? >>>> >>>> ImageTragick certainly not. >>> >>> That's not ImageMagick above. >> >> Then what is it? > > GraphicsMagick which claims to be the dpx reference (afaiu). > >>> The sample in question looks better with attached poc, breaks >>> four component sample, also attaching other samples that >>> show the difference. >> >> Attacking crappy patches and non-compliant files that > > Do you know of a 10bit gray dpx sample that does not look > better with my "crappy" patch? > >> conflict and do not follow specification is not productive. > > GraphicsMagick claims differently. How sample from ticket #4409 looks with that tool?
2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda@gmail.com>: > On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>>> Fixes #4409. >>>>>>>>> >>>>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>>>> --- >>>>>>>>> libavcodec/dpx.c | 3 ++- >>>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>>>>> >>>>>>>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c >>>>>>>>> index 538a1b9943..04b55ffadf 100644 >>>>>>>>> --- a/libavcodec/dpx.c >>>>>>>>> +++ b/libavcodec/dpx.c >>>>>>>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx, >>>>>>>>> read10in32(&buf, &rgbBuffer, >>>>>>>>> &n_datum, endian, shift); >>>>>>>>> } >>>>>>>>> - n_datum = 0; >>>>>>>>> + if (packing != 2) >>>>>>>>> + n_datum = 0; >>>>>>>>> for (i = 0; i < elements; i++) >>>>>>>>> ptr[i] += p->linesize[i]; >>>>>>>>> } >>>>>>>> >>>>>>>> This breaks decoding the output of the following command: >>>>>>>> $ gm convert converted_image_gets_skewed.dpx -define >>>>>>>> dpx:packing-method=b out.dpx >>>>>>> >>>>>>> I do not trust that app, its full of bugs. >>>>>> >>>>>> What is the reference for dpx in your opinion? >>>>> >>>>> ImageTragick certainly not. >>>> >>>> That's not ImageMagick above. >>> >>> Then what is it? >> >> GraphicsMagick which claims to be the dpx reference (afaiu). >> >>>> The sample in question looks better with attached poc, breaks >>>> four component sample, also attaching other samples that >>>> show the difference. >>> >>> Attacking crappy patches and non-compliant files that >> >> Do you know of a 10bit gray dpx sample that does not look >> better with my "crappy" patch? >> >>> conflict and do not follow specification is not productive. >> >> GraphicsMagick claims differently. > > How sample from ticket #4409 looks with that tool? It fails differently than with your patch. Carl Eugen
On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>>>> Fixes #4409. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>>>>> --- >>>>>>>>>> libavcodec/dpx.c | 3 ++- >>>>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>>>>>> >>>>>>>>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c >>>>>>>>>> index 538a1b9943..04b55ffadf 100644 >>>>>>>>>> --- a/libavcodec/dpx.c >>>>>>>>>> +++ b/libavcodec/dpx.c >>>>>>>>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx, >>>>>>>>>> read10in32(&buf, &rgbBuffer, >>>>>>>>>> &n_datum, endian, shift); >>>>>>>>>> } >>>>>>>>>> - n_datum = 0; >>>>>>>>>> + if (packing != 2) >>>>>>>>>> + n_datum = 0; >>>>>>>>>> for (i = 0; i < elements; i++) >>>>>>>>>> ptr[i] += p->linesize[i]; >>>>>>>>>> } >>>>>>>>> >>>>>>>>> This breaks decoding the output of the following command: >>>>>>>>> $ gm convert converted_image_gets_skewed.dpx -define >>>>>>>>> dpx:packing-method=b out.dpx >>>>>>>> >>>>>>>> I do not trust that app, its full of bugs. >>>>>>> >>>>>>> What is the reference for dpx in your opinion? >>>>>> >>>>>> ImageTragick certainly not. >>>>> >>>>> That's not ImageMagick above. >>>> >>>> Then what is it? >>> >>> GraphicsMagick which claims to be the dpx reference (afaiu). >>> >>>>> The sample in question looks better with attached poc, breaks >>>>> four component sample, also attaching other samples that >>>>> show the difference. >>>> >>>> Attacking crappy patches and non-compliant files that >>> >>> Do you know of a 10bit gray dpx sample that does not look >>> better with my "crappy" patch? >>> >>>> conflict and do not follow specification is not productive. >>> >>> GraphicsMagick claims differently. >> >> How sample from ticket #4409 looks with that tool? > > It fails differently than with your patch. > I have dpx specification, and my patch above show correct output for that file. So I do not know what we are discussing about. Find actual program that correctly displays sample from above ticket and that we can talk again.
2018-12-05 22:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>: > On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> 2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>>>>> Fixes #4409. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>>>>>> --- >>>>>>>>>>> libavcodec/dpx.c | 3 ++- >>>>>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>>>>>>> >>>>>>>>>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c >>>>>>>>>>> index 538a1b9943..04b55ffadf 100644 >>>>>>>>>>> --- a/libavcodec/dpx.c >>>>>>>>>>> +++ b/libavcodec/dpx.c >>>>>>>>>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext >>>>>>>>>>> *avctx, >>>>>>>>>>> read10in32(&buf, &rgbBuffer, >>>>>>>>>>> &n_datum, endian, shift); >>>>>>>>>>> } >>>>>>>>>>> - n_datum = 0; >>>>>>>>>>> + if (packing != 2) >>>>>>>>>>> + n_datum = 0; >>>>>>>>>>> for (i = 0; i < elements; i++) >>>>>>>>>>> ptr[i] += p->linesize[i]; >>>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> This breaks decoding the output of the following command: >>>>>>>>>> $ gm convert converted_image_gets_skewed.dpx -define >>>>>>>>>> dpx:packing-method=b out.dpx >>>>>>>>> >>>>>>>>> I do not trust that app, its full of bugs. >>>>>>>> >>>>>>>> What is the reference for dpx in your opinion? >>>>>>> >>>>>>> ImageTragick certainly not. >>>>>> >>>>>> That's not ImageMagick above. >>>>> >>>>> Then what is it? >>>> >>>> GraphicsMagick which claims to be the dpx reference (afaiu). >>>> >>>>>> The sample in question looks better with attached poc, breaks >>>>>> four component sample, also attaching other samples that >>>>>> show the difference. >>>>> >>>>> Attacking crappy patches and non-compliant files that >>>> >>>> Do you know of a 10bit gray dpx sample that does not look >>>> better with my "crappy" patch? >>>> >>>>> conflict and do not follow specification is not productive. >>>> >>>> GraphicsMagick claims differently. >>> >>> How sample from ticket #4409 looks with that tool? >> >> It fails differently than with your patch. >> > > I have dpx specification, > and my patch above show correct output for that file. I am not so sure: Look at the right border with and without my change. > So I do not know what we are discussing about. > > Find actual program that correctly displays sample from above > ticket and that we can talk again. It displays correctly with my change, I am not sure if the file conforms to the dpx specification. Carl Eugen
On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2018-12-05 22:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>> 2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>>>>>> Fixes #4409. >>>>>>>>>>>> >>>>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>>>>>>> --- >>>>>>>>>>>> libavcodec/dpx.c | 3 ++- >>>>>>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c >>>>>>>>>>>> index 538a1b9943..04b55ffadf 100644 >>>>>>>>>>>> --- a/libavcodec/dpx.c >>>>>>>>>>>> +++ b/libavcodec/dpx.c >>>>>>>>>>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext >>>>>>>>>>>> *avctx, >>>>>>>>>>>> read10in32(&buf, &rgbBuffer, >>>>>>>>>>>> &n_datum, endian, shift); >>>>>>>>>>>> } >>>>>>>>>>>> - n_datum = 0; >>>>>>>>>>>> + if (packing != 2) >>>>>>>>>>>> + n_datum = 0; >>>>>>>>>>>> for (i = 0; i < elements; i++) >>>>>>>>>>>> ptr[i] += p->linesize[i]; >>>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> This breaks decoding the output of the following command: >>>>>>>>>>> $ gm convert converted_image_gets_skewed.dpx -define >>>>>>>>>>> dpx:packing-method=b out.dpx >>>>>>>>>> >>>>>>>>>> I do not trust that app, its full of bugs. >>>>>>>>> >>>>>>>>> What is the reference for dpx in your opinion? >>>>>>>> >>>>>>>> ImageTragick certainly not. >>>>>>> >>>>>>> That's not ImageMagick above. >>>>>> >>>>>> Then what is it? >>>>> >>>>> GraphicsMagick which claims to be the dpx reference (afaiu). >>>>> >>>>>>> The sample in question looks better with attached poc, breaks >>>>>>> four component sample, also attaching other samples that >>>>>>> show the difference. >>>>>> >>>>>> Attacking crappy patches and non-compliant files that >>>>> >>>>> Do you know of a 10bit gray dpx sample that does not look >>>>> better with my "crappy" patch? >>>>> >>>>>> conflict and do not follow specification is not productive. >>>>> >>>>> GraphicsMagick claims differently. >>>> >>>> How sample from ticket #4409 looks with that tool? >>> >>> It fails differently than with your patch. >>> >> >> I have dpx specification, > >> and my patch above show correct output for that file. > > I am not so sure: Look at the right border with and without my change. > >> So I do not know what we are discussing about. >> >> Find actual program that correctly displays sample from above >> ticket and that we can talk again. > > It displays correctly with my change, I am not sure if the file > conforms to the dpx specification. The files you posted does not conform, B files looks like using no-packing mode.
2018-12-06 10:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>: > On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> 2018-12-05 22:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>> 2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>>>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>: >>>>>>>>>>>>> Fixes #4409. >>>>>>>>>>>>> >>>>>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>>>>>>>> --- >>>>>>>>>>>>> libavcodec/dpx.c | 3 ++- >>>>>>>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>>>>>>>>> >>>>>>>>>>>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c >>>>>>>>>>>>> index 538a1b9943..04b55ffadf 100644 >>>>>>>>>>>>> --- a/libavcodec/dpx.c >>>>>>>>>>>>> +++ b/libavcodec/dpx.c >>>>>>>>>>>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext >>>>>>>>>>>>> *avctx, >>>>>>>>>>>>> read10in32(&buf, &rgbBuffer, >>>>>>>>>>>>> &n_datum, endian, shift); >>>>>>>>>>>>> } >>>>>>>>>>>>> - n_datum = 0; >>>>>>>>>>>>> + if (packing != 2) >>>>>>>>>>>>> + n_datum = 0; >>>>>>>>>>>>> for (i = 0; i < elements; i++) >>>>>>>>>>>>> ptr[i] += p->linesize[i]; >>>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> This breaks decoding the output of the following command: >>>>>>>>>>>> $ gm convert converted_image_gets_skewed.dpx -define >>>>>>>>>>>> dpx:packing-method=b out.dpx >>>>>>>>>>> >>>>>>>>>>> I do not trust that app, its full of bugs. >>>>>>>>>> >>>>>>>>>> What is the reference for dpx in your opinion? >>>>>>>>> >>>>>>>>> ImageTragick certainly not. >>>>>>>> >>>>>>>> That's not ImageMagick above. >>>>>>> >>>>>>> Then what is it? >>>>>> >>>>>> GraphicsMagick which claims to be the dpx reference (afaiu). >>>>>> >>>>>>>> The sample in question looks better with attached poc, breaks >>>>>>>> four component sample, also attaching other samples that >>>>>>>> show the difference. >>>>>>> >>>>>>> Attacking crappy patches and non-compliant files that >>>>>> >>>>>> Do you know of a 10bit gray dpx sample that does not look >>>>>> better with my "crappy" patch? >>>>>> >>>>>>> conflict and do not follow specification is not productive. >>>>>> >>>>>> GraphicsMagick claims differently. >>>>> >>>>> How sample from ticket #4409 looks with that tool? >>>> >>>> It fails differently than with your patch. >>>> >>> >>> I have dpx specification, >> >>> and my patch above show correct output for that file. >> >> I am not so sure: Look at the right border with and without my change. >> >>> So I do not know what we are discussing about. >>> >>> Find actual program that correctly displays sample from above >>> ticket and that we can talk again. >> >> It displays correctly with my change, I am not sure if the file >> conforms to the dpx specification. > > The files you posted does not conform What is wrong about them? > B files looks like using no-packing mode. The only difference between "B" and "L" files is the endianness. Two files are lsb-padded, two are msb-padded ("a" and "b"). Carl Eugen
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c index 538a1b9..b9e02e5 100644 --- a/libavcodec/dpx.c +++ b/libavcodec/dpx.c @@ -50,6 +50,8 @@ static unsigned int read32(const uint8_t **ptr, int is_big) return temp; } +static int counter = 0; + static uint16_t read10in32(const uint8_t **ptr, uint32_t * lbuf, int * n_datum, int is_big, int shift) { @@ -60,9 +62,11 @@ static uint16_t read10in32(const uint8_t **ptr, uint32_t * lbuf, *n_datum = 2; } - *lbuf = *lbuf << 10 | *lbuf >> shift & 0x3FFFFF; - - return *lbuf & 0x3FF; + if (*n_datum < 2) + *lbuf = *lbuf >> 10; +if (counter++<30) +printf("%x \n", *lbuf >> shift & 0x3FF); + return *lbuf >> shift & 0x3FF; } static uint16_t read12in32(const uint8_t **ptr, uint32_t * lbuf, @@ -168,6 +172,7 @@ static int decode_frame(AVCodecContext *avctx, bits_per_color = buf[0]; buf++; packing = read16(&buf, endian); +printf("packing: %d, endian: %d, descriptor: %d, bpc: %d \n", packing, endian, descriptor, bits_per_color); encoding = read16(&buf, endian); if (encoding) { @@ -310,6 +315,7 @@ static int decode_frame(AVCodecContext *avctx, case 51121: avctx->pix_fmt = AV_PIX_FMT_GBRAP12; break; + case 6100: case 6101: avctx->pix_fmt = AV_PIX_FMT_GRAY10; break; @@ -363,20 +369,20 @@ static int decode_frame(AVCodecContext *avctx, (uint16_t*)ptr[1], (uint16_t*)ptr[2], (uint16_t*)ptr[3]}; - int shift = packing == 1 ? 22 : 20; + int shift = packing == 1 ? 2 : 0; for (y = 0; y < avctx->width; y++) { - if (elements >= 3) - *dst[2]++ = read10in32(&buf, &rgbBuffer, - &n_datum, endian, shift); - *dst[0]++ = read10in32(&buf, &rgbBuffer, - &n_datum, endian, shift); - if (elements >= 2) - *dst[1]++ = read10in32(&buf, &rgbBuffer, - &n_datum, endian, shift); if (elements == 4) *dst[3]++ = read10in32(&buf, &rgbBuffer, &n_datum, endian, shift); + if (elements >= 2) + *dst[1]++ = read10in32(&buf, &rgbBuffer, + &n_datum, endian, shift); + *dst[/*elements == 4 ? 2 :*/ 0]++ = read10in32(&buf, &rgbBuffer, + &n_datum, endian, shift); + if (elements >= 3) + *dst[/*elements == 4 ? 0 :*/ 2]++ = read10in32(&buf, &rgbBuffer, + &n_datum, endian, shift); } n_datum = 0; for (i = 0; i < elements; i++)