This ensures the default ycbcr_subsampling is 2 while also
ensuring the subsampling values are correct for all pixel formats.
This solution while it takes a few lines more code should be more
robust
In TIFF specification only CbCr subsampling is allowed. The field is explicitly named
TIFF decoder uses wrong default YCbCrSubsampling value so it breaks
on files that rely on standard default and omit the value.
This patch broke fate-exif-image-tiff and fate-lavf-tiff.
Patch updated, fixed one more error in code: rps check used subsampling even
for non-subsampled formats.
TIFF decoder uses wrong default YCbCrSubsampling value so it breaks on files
that rely on standard default and omit the value.
From 1b638417034ec212de4675db8e1695d1e5469d1d Mon Sep 17 00:00:00 2001
From: Pavel Skakov
Date: Tue, 24 Sep 2019 20:30:59 +0300
Subject: [PATCH] avcodec/tiff: correct
Corrected handling of border pixels when unpacking YUV.
This should be a separate patch and please mention ticket #1178 if it is
related.
It's probably unrelated: the ticket is about TIFF writer while I'm working on
TIFF reader for now.
___
Corrected handling of border pixels when unpacking YUV. Example (bottom line):
https://github.com/BitMiracle/libtiff.net/blob/master/TestCase/ycbcr-cat.tif
From 09f9822d8d38f26ff386df3d01794fcafe3f3869 Mon Sep 17 00:00:00 2001
From: Pavel Skakov
Date: Thu, 10 Oct 2019 02:21:06 +0300
Subject:
Correct name is [PATCH v2 3/4].
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Added support for 16-bit per sample YUV formats. This would allow ffmpeg to
losslessly save (later) and load subsampled 10/16-bit YUV frames in simple and
somewhat standard format.
Formats that don't currently have ffmpeg support but would work if such support
appears are left commented out
Made it easier for compiler to optimize array indexes when unpacking YUV.
From 29b2437e04d6af1c5093efcaac6f8bc852525d78 Mon Sep 17 00:00:00 2001
From: Pavel Skakov
Date: Thu, 10 Oct 2019 02:43:34 +0300
Subject: [PATCH 4/4] avcodec/tiff: small compiling optimization
Signed-off-by: Pavel Skakov
Re-indentation after previous patches.
From 1d3fbed08cf7c89cb81a3b98403605b7a7e20235 Mon Sep 17 00:00:00 2001
From: Pavel Skakov
Date: Thu, 10 Oct 2019 02:37:50 +0300
Subject: [PATCH 3/4] avcodec/tiff: indentation
Signed-off-by: Pavel Skakov
---
libavcodec/tiff.c | 39
Added support for 16-bit per sample YUV formats. This would allow ffmpeg to
losslessly save (later) and load subsampled 10/16-bit YUV frames in simple and
somewhat standard format.
Corrected handling of border pixels when unpacking YUV. Example for 8-bit
(bottom line):
Add support for properly handling PC/TV ranges and Rec601/Rec709 color spaces.
Example for PC range YUV, compare to ImageMagick decoding:
https://samples.ffmpeg.org/image-samples/dscf0013.tif
From 5e24edbf73f3a897fd203e36963e9cf5db5e688d Mon Sep 17 00:00:00 2001
From: Pavel Skakov
Date: Thu, 3
You should use AVRationals instead. It's ideal seeing the way these
values are coded in the bitstream.
See libavutil/rational.h
Can AVRational be used even through the values are essentially unsigned?
LibTIFF really likes to encode 0..1 values with denominator 0x.
Add support for properly handling PC/TV ranges and Rec601/Rec709 color spaces.
Can't this be implemented without using floats?
AVRationals are not a good idea as those values are unsigned and often use full
unsigned range.
Here is slightly different approach: range check for fractional
Can AVRational be used even through the values are essentially unsigned?
LibTIFF really likes to encode 0..1 values with denominator 0x.
floats do not have enough precission to store unsigned 32/32bit fractions
just consider a float has 32bit (and a good part is really small and large
Can AVRational be used even through the values are essentially unsigned?
LibTIFF really likes to encode 0..1 values with denominator 0x.
Is it feasible for this to use av_reduce() with INT_MAX as max argument?
It takes int64_t as input values, so UINT_MAX should be fine.
It seems to
15 matches
Mail list logo
