running the same command here, I get an image that contains ~16 bits
worth of data and it looks 'correct' in Nuke. It also matches a PNG
made with ffmpeg
Kevin
On Mon, May 11, 2015 at 2:50 PM, tim nicholson
nichot20-at-yahoo@ffmpeg.org wrote:
On 11/05/15 12:59, tim nicholson wrote:
Thanks
In case nobody realises, the colour differences you are showing, look
like a miss match between the encoding matrix and the decoding matrix
used to perform the RGB-YCbCr conversion, like it is encoded with BT
709 and decoded with 601.
Kevin
___
I should have paid more attention to your command line, in that case
you are going between the same pixel format and I'm not sure that the
use of the scalar for converting between different colour difference
encodings will actually do anything as I believe it only considers
using the matrices if
On Tue, Jun 9, 2015 at 1:08 PM, Hardik Kanakia hardik.kana...@gmail.com wrote:
Hello All,
Tried using the below command, still the issue of color jump persists from
dpx (RGB) to prores422 (YUV)
/usr/local/sbin/ffmpeg263/ffmpeg -r 24.00 -i hahk_c300_400.%06d.dpx
-s 1920x1080 -r
On Wed, Dec 16, 2015 at 11:27 PM, Rens Dijkshoorn wrote:
> Currently there is no agreed standard how this
> curve should be defined. The NHK/BBC proposal
> seems to be the most promising
>
> If the input file already has an OETF applied encoding
> with ffmpeg should be
The ITU has the following freely available
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1366-0-199802-S!!PDF-E.pdf
so at best tens of hours has 2 bits of BCD
Kevin
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
For note DCP's are typically 2.6 gamma encoded X'Y'Z'.
Conversion to Rec 709 RGB might be as simple as linearise to XYZ and
then convert to 709 using the primaries matrix and apply an
appropriate transfer function for your new display environment,
however for perceptual matching you may need to
On Fri, Jan 20, 2017 at 10:54 AM, Carl Eugen Hoyos wrote:
> 2017-01-19 3:20 GMT+01:00 Daniel Kim :
>
>> I'm trying to use ffmpeg in our pipeline and integrate it with
>> OCIO for the color space transformations.
>
> Why?
>
> What is wrong with the color
On Fri, Jan 20, 2017 at 5:53 PM, Carl Eugen Hoyos wrote:
> 2017-01-20 16:26 GMT+01:00 DEV - VFXBOAT :
>
>> But, the exr rendered by maya are in linear
>
> What is wrong if they transformed to png by FFmpeg?
>
> Please do not top-post here, Carl Eugen
Andreas,
instead of using the -colormatrix option try instead using
-vf
scale=in_range=full:in_color_matrix=bt709:out_range=tv:out_color_matrix=bt709
assuming your DPX files are utilising full range encoding
Kevin
___
ffmpeg-user mailing list
Answering my own question... I have not tested this but having
manually read the code in the git history I'll try code up a fix for
my theory:
looks like there is a bug in the commit
1a08758e7c4e14a9ea8d2fef6c33ad411b2d3c40 relating to the handling of
ptr in decode_frame after decode_block is
As a partial fix I've submitted a patch here:
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/205267.html
That fixes the simple cases.
Kevin
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To
Sent on the go...
> On 30 Apr 2018, at 18:58, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
>
> 2018-04-30 16:33 GMT+02:00, Kevin Wheatley <kevin.j.wheat...@gmail.com>:
>
>> I note that a similar report was made
>> https://trac.ffmpeg.org/ticket/6865 but tha
Hi,
I've just built a version of ffmpeg n4.0
from ace829cb45cff530b8a0aed6adf18f329d7a98f6 linked against libvmaf
ba5356cb41cf3b19ca0bb108bd8e86e9da402f94.
I notice when running commands similar to the examples in the FFmpeg
documentation:
ffmpeg -i test2.mov -i test3.mov -lavfi libvmaf -f null
from memory only ISO movies have the option of adding the range bit to
the ATOM, QuickTime (.mov) does not.
Kevin
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or
15 matches
Mail list logo