From: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/tiff: add support for decoding compressed rgb floating point formats
Date: Sun, 2 Oct 2022 00:28:18 +0200
Message-ID: <GV1P250MB073730497A9C2EF7E0A44E088F599@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CA+anCR=_FoL9TcaodCqB_NnODHZaXYXxBnD04JPPkP5CroeHjA@mail.gmail.com>
Mark Reid:
> On Sat, Oct 1, 2022 at 7:22 AM Andreas Rheinhardt <
> andreas.rheinhardt@outlook.com> wrote:
>
>> mindmark@gmail.com:
>>> From: Mark Reid <mindmark@gmail.com>
>>>
>>> floating point uses a slightly different predictor technique describe
>> here
>>> http://chriscox.org/TIFFTN3d1.pdf
>>>
>>> Here is a link the test files, if someone could add them to fate me
>>> https://www.dropbox.com/s/fg59h2os4gb4wug/tiff_fate_samples.zip
>>>
>>>
>>> ---
>>> libavcodec/tiff.c | 66 +++++++++++++++++++++-
>>> tests/fate/image.mak | 18 ++++++
>>> tests/ref/fate/tiff-lzw-rgbaf32le | 6 ++
>>> tests/ref/fate/tiff-lzw-rgbf32le | 6 ++
>>> tests/ref/fate/tiff-uncompressed-rgbaf32le | 6 ++
>>> tests/ref/fate/tiff-uncompressed-rgbf32le | 6 ++
>>> tests/ref/fate/tiff-zip-rgbaf32le | 6 ++
>>> tests/ref/fate/tiff-zip-rgbf32le | 6 ++
>>> 8 files changed, 119 insertions(+), 1 deletion(-)
>>> create mode 100644 tests/ref/fate/tiff-lzw-rgbaf32le
>>> create mode 100644 tests/ref/fate/tiff-lzw-rgbf32le
>>> create mode 100644 tests/ref/fate/tiff-uncompressed-rgbaf32le
>>> create mode 100644 tests/ref/fate/tiff-uncompressed-rgbf32le
>>> create mode 100644 tests/ref/fate/tiff-zip-rgbaf32le
>>> create mode 100644 tests/ref/fate/tiff-zip-rgbf32le
>>>
>>> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
>>> index 3a610ada85..c1d07f8c3e 100644
>>> --- a/libavcodec/tiff.c
>>> +++ b/libavcodec/tiff.c
>>> @@ -1913,7 +1913,7 @@ static int decode_frame(AVCodecContext *avctx,
>> AVFrame *p,
>>> TiffContext *const s = avctx->priv_data;
>>> unsigned off, last_off = 0;
>>> int le, ret, plane, planes;
>>> - int i, j, entries, stride;
>>> + int i, j, k, entries, stride;
>>
>> Don't add another loop variable. We support "for (int k = 0;" nowadays.
>>
>>> unsigned soff, ssize;
>>> uint8_t *dst;
>>> GetByteContext stripsizes;
>>> @@ -2249,6 +2249,70 @@ again:
>>> }
>>> }
>>>
>>> + /* Floating point predictor
>>> + TIFF Technical Note 3 http://chriscox.org/TIFFTN3d1.pdf */
>>> + if (s->predictor == 3) {
>>> + int channels = s->bppcount;
>>> + int lane_offset;
>>> + uint8_t *tmpbuf;
>>> + int bpc;
>>> +
>>> + dst = five_planes ? five_planes : p->data[plane];
>>> + soff = s->bpp >> 3;
>>> + if (s->planar) {
>>> + soff = FFMAX(soff / s->bppcount, 1);
>>> + channels = 1;
>>> + }
>>> + ssize = s->width * soff;
>>> + bpc = FFMAX(soff / s->bppcount, 1); /* bytes per component
>> */
>>> + lane_offset = s->width * channels;
>>> +
>>> + tmpbuf = (uint8_t*)av_malloc(ssize);
>>
>> unnecessary cast.
>>
>>> + if (!tmpbuf)
>>> + return AVERROR(ENOMEM);
>>> +
>>> + if (s->avctx->pix_fmt == AV_PIX_FMT_RGBF32LE ||
>>> + s->avctx->pix_fmt == AV_PIX_FMT_RGBAF32LE) {
>>> + for (i = 0; i < decoded_height; i++) {
>>> + /* copy first sample byte for each channel */
>>> + for (j = 0; j < channels; j++)
>>> + tmpbuf[j] = dst[j];
>>> +
>>> + /* decode horizontal differences */
>>> + for (j = channels; j < ssize; j++)
>>> + tmpbuf[j] = dst[j] + tmpbuf[j-channels];
>>> +
>>> + /* combine shuffled bytes from their sepearate
>> lanes */
>>
>> ^
>>
>> Did you not like this comment? I can remove it, I felt the code needed
> some explanation and I don't think the comment is the best.
There is a typo: sepearate should be separate.
> The docs example code refers to these lanes as rowIncrements, which I
> thought was a confusing name too.
>
> Each byte of every floating point value in a row of pixels is split and
> combined into separate groups.
> A group of all the sign/exponents bytes in the row and groups for each of
> the upper, mid, and lower mantissa bytes in the row.
>
> Maybe group_size is a better name than lane_offset now that I typed that
> out.
>
>
>>> + for (j = 0; j < lane_offset; j++) {
>>> + for (k = 0; k < bpc; k++) {
>>> + dst[bpc * j + k] = tmpbuf[(bpc - k - 1) *
>> lane_offset + j];
>>> + }
>>> + }
>>> + dst += stride;
>>> + }
>>> + } else if (s->avctx->pix_fmt == AV_PIX_FMT_RGBF32BE ||
>>> + s->avctx->pix_fmt == AV_PIX_FMT_RGBAF32BE) {
>>> + /* same as LE only the shuffle at the end is reversed */
>>> + for (i = 0; i < decoded_height; i++) {
>>> + for (j = 0; j < channels; j++)
>>> + tmpbuf[j] = dst[j];
>>> +
>>> + for (j = channels; j < ssize; j++)
>>> + tmpbuf[j] = dst[j] + tmpbuf[j-channels];
>>> +
>>> + for (j = 0; j < lane_offset; j++) {
>>> + for (k = 0; k < bpc; k++) {
>>> + dst[bpc * j + k] = tmpbuf[k * lane_offset +
>> j];
>>> + }
>>> + }
>>> + dst += stride;
>>> + }
>>> + } else {
>>> + av_log(s->avctx, AV_LOG_ERROR, "unsupported floating
>> point pixel format\n");
>>> + }
>>> + av_free(tmpbuf);
>>> + }
>>> +
>>> if (s->photometric == TIFF_PHOTOMETRIC_WHITE_IS_ZERO) {
>>> int c = (s->avctx->pix_fmt == AV_PIX_FMT_PAL8 ? (1<<s->bpp)
>> - 1 : 255);
>>> dst = p->data[plane];
>>> diff --git a/tests/fate/image.mak b/tests/fate/image.mak
>>> index 03e794dc48..971531520d 100644
>>> --- a/tests/fate/image.mak
>>> +++ b/tests/fate/image.mak
>>> @@ -501,6 +501,24 @@ fate-tiff-fax-g3: CMD = framecrc -i
>> $(TARGET_SAMPLES)/CCITT_fax/G31D.TIF
>>> FATE_TIFF += fate-tiff-fax-g3s
>>> fate-tiff-fax-g3s: CMD = framecrc -i
>> $(TARGET_SAMPLES)/CCITT_fax/G31DS.TIF
>>>
>>> +FATE_TIFF += fate-tiff-uncompressed-rgbf32le
>>> +fate-tiff-uncompressed-rgbf32le: CMD = framecrc -i
>> $(TARGET_SAMPLES)/tiff/uncompressed_rgbf32le.tif
>>> +
>>> +FATE_TIFF += fate-tiff-uncompressed-rgbaf32le
>>> +fate-tiff-uncompressed-rgbaf32le: CMD = framecrc -i
>> $(TARGET_SAMPLES)/tiff/uncompressed_rgbaf32le.tif
>>> +
>>> +FATE_TIFF += fate-tiff-lzw-rgbf32le
>>> +fate-tiff-lzw-rgbf32le: CMD = framecrc -i
>> $(TARGET_SAMPLES)/tiff/lzw_rgbf32le.tif
>>> +
>>> +FATE_TIFF += fate-tiff-lzw-rgbaf32le
>>> +fate-tiff-lzw-rgbaf32le: CMD = framecrc -i
>> $(TARGET_SAMPLES)/tiff/lzw_rgbaf32le.tif
>>> +
>>> +FATE_TIFF += fate-tiff-zip-rgbf32le
>>> +fate-tiff-zip-rgbf32le: CMD = framecrc -i
>> $(TARGET_SAMPLES)/tiff/zip_rgbf32le.tif
>>> +
>>> +FATE_TIFF += fate-tiff-zip-rgbaf32le
>>> +fate-tiff-zip-rgbaf32le: CMD = framecrc -i
>> $(TARGET_SAMPLES)/tiff/zip_rgbaf32le.tif
>>> +
>>> FATE_TIFF-$(call DEMDEC, IMAGE2, TIFF) += $(FATE_TIFF)
>>
>> I already wanted to write that framecrc tests don't really work with
>> floating point formats, but then I saw that there is no real floating
>> point code in this patch. Very weird for a floating point format.
>> (Apart from that: You want to use FRAMECRC instead of DEMDEC.)
>>
>>
> yes there is no floating point calculations involved, the process should
> always be bitexact.
>
> you mean like this right?
> FATE_TIFF-$(call FRAMECRC, IMAGE2, TIFF) += $(FATE_TIFF)
Yes.
>
> Thanks for the quick review!
>
>>
>>> FATE_IMAGE_FRAMECRC += $(FATE_TIFF-yes)
>>> diff --git a/tests/ref/fate/tiff-lzw-rgbaf32le
>> b/tests/ref/fate/tiff-lzw-rgbaf32le
>>> new file mode 100644
>>> index 0000000000..c99aa02ef0
>>> --- /dev/null
>>> +++ b/tests/ref/fate/tiff-lzw-rgbaf32le
>>> @@ -0,0 +1,6 @@
>>> +#tb 0: 1/25
>>> +#media_type 0: video
>>> +#codec_id 0: rawvideo
>>> +#dimensions 0: 8x8
>>> +#sar 0: 0/1
>>> +0, 0, 0, 1, 1024, 0x877e1d5f
>>> diff --git a/tests/ref/fate/tiff-lzw-rgbf32le
>> b/tests/ref/fate/tiff-lzw-rgbf32le
>>> new file mode 100644
>>> index 0000000000..a6d3fabfda
>>> --- /dev/null
>>> +++ b/tests/ref/fate/tiff-lzw-rgbf32le
>>> @@ -0,0 +1,6 @@
>>> +#tb 0: 1/25
>>> +#media_type 0: video
>>> +#codec_id 0: rawvideo
>>> +#dimensions 0: 8x8
>>> +#sar 0: 0/1
>>> +0, 0, 0, 1, 768, 0xad26ed90
>>> diff --git a/tests/ref/fate/tiff-uncompressed-rgbaf32le
>> b/tests/ref/fate/tiff-uncompressed-rgbaf32le
>>> new file mode 100644
>>> index 0000000000..c99aa02ef0
>>> --- /dev/null
>>> +++ b/tests/ref/fate/tiff-uncompressed-rgbaf32le
>>> @@ -0,0 +1,6 @@
>>> +#tb 0: 1/25
>>> +#media_type 0: video
>>> +#codec_id 0: rawvideo
>>> +#dimensions 0: 8x8
>>> +#sar 0: 0/1
>>> +0, 0, 0, 1, 1024, 0x877e1d5f
>>> diff --git a/tests/ref/fate/tiff-uncompressed-rgbf32le
>> b/tests/ref/fate/tiff-uncompressed-rgbf32le
>>> new file mode 100644
>>> index 0000000000..a6d3fabfda
>>> --- /dev/null
>>> +++ b/tests/ref/fate/tiff-uncompressed-rgbf32le
>>> @@ -0,0 +1,6 @@
>>> +#tb 0: 1/25
>>> +#media_type 0: video
>>> +#codec_id 0: rawvideo
>>> +#dimensions 0: 8x8
>>> +#sar 0: 0/1
>>> +0, 0, 0, 1, 768, 0xad26ed90
>>> diff --git a/tests/ref/fate/tiff-zip-rgbaf32le
>> b/tests/ref/fate/tiff-zip-rgbaf32le
>>> new file mode 100644
>>> index 0000000000..c99aa02ef0
>>> --- /dev/null
>>> +++ b/tests/ref/fate/tiff-zip-rgbaf32le
>>> @@ -0,0 +1,6 @@
>>> +#tb 0: 1/25
>>> +#media_type 0: video
>>> +#codec_id 0: rawvideo
>>> +#dimensions 0: 8x8
>>> +#sar 0: 0/1
>>> +0, 0, 0, 1, 1024, 0x877e1d5f
>>> diff --git a/tests/ref/fate/tiff-zip-rgbf32le
>> b/tests/ref/fate/tiff-zip-rgbf32le
>>> new file mode 100644
>>> index 0000000000..a6d3fabfda
>>> --- /dev/null
>>> +++ b/tests/ref/fate/tiff-zip-rgbf32le
>>> @@ -0,0 +1,6 @@
>>> +#tb 0: 1/25
>>> +#media_type 0: video
>>> +#codec_id 0: rawvideo
>>> +#dimensions 0: 8x8
>>> +#sar 0: 0/1
>>> +0, 0, 0, 1, 768, 0xad26ed90
>>> --
>>> 2.31.1.windows.1
>>>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
prev parent reply other threads:[~2022-10-01 22:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-01 14:06 mindmark
2022-10-01 14:21 ` Andreas Rheinhardt
2022-10-01 22:23 ` Mark Reid
2022-10-01 22:28 ` Andreas Rheinhardt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=GV1P250MB073730497A9C2EF7E0A44E088F599@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM \
--to=andreas.rheinhardt@outlook.com \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git