PAL and NTSC have different color primaries, so
NTSC = SMPTE 170M = BT 601 525
PAL = BT 470 BG = BT 601 625
See the rows for value 5 & 6 on the table on page 387 of the active H.264 standard.
So the right args for ffmpeg are:
ffmpeg -i input \
-colorspace smpte170m -color_primaries smpte170m -color_trc smpte170m
You may want to use FFMPEG's lut3d filter. It requires you to provide a look-up table (a *.cube file). For example, if you have an ARRI camera you can generate these files using ARRI Color Tool or simply download a package with them from the linked page.
Once you have the files, use FFMPEG like this:
ffmpeg -i "Input.mov" -vf lut3d="ARRIP3D65PQ108-33....
If your question was
Where are these pixel formats defined?
Go to http://ffmpeg.org/download.html and download the source of ffmpeg. Then unpack it
tar -xavf FILENAME.tar.*
and descend to the folder in the source code that is called libavutil
and open the file pixfmt.h where you will find a description of all pixel formats. A ...
There are a number of reasons why there are so many color spaces:
Color resolution - sRGB and similar color spaces only cover a portion of the visible spectrum. This means that they can be represented with fewer bits per color channel. (8 in the case of sRGB.) For something like Rec. 2020 or ACEScg, you need 16 or more bits per channel. If you don't have ...
Most videos are limited range i.e. luma goes from 16 to 235, and chroma from 16 to 240.
Unless expressly set, FFmpeg does not scale the range from one to another. Whatever the source is, that's the output.*
However, many inputs don't tag this property in their metadata. So, the output doesn't get tagged either. In that scenario, players tend to assume ...
The short answer is: You don't pick a color space for your RAW material based on what kind of monitor you're using.
A color pipeline is a very complicated series of mathematical conversions, which is heavily dependent upon:
The operating system's color management settings, such as .icc device profiles from manufacturers, and/or calibration software.
It's a bit of a semantics game. The YUY2 video mode is not "compressed," but it won't result in a bit-exact copy of RGB input. The luminance is full resolution in that mode, but the chrominance is sampled at a lower resolution. This is technically decimation rather than compression, but some information is indeed lost.
That said, if you are ...
This announcement article dated January 11, 2017 indicates that there will be an upgrade to the app FiLMiC Pro which may accommodate what you are looking for. Note that the FiLMic Pro App Store web page indicates the latest release is 12/23/2016 - I do not know when the update the article speaks of will be available:
The forthcoming update will introduce ...
"Is D-Cinelike just a flatter colour profile with less contrast (to capture more detail in shadows and highlights)?" Yes. It's closer to log color rather than linear. The big thing to be aware of in post production is to make sure you grade it to where you want it to be and possibly use their LUT to convert back towards Rec 709 depending on what you are ...
Apparently FFmpeg doesn't set input color attributes correctly for BMP input (probably because the file doesn't contain that metadata) and the BMP decoder doesn't check for manually flagged attributes. However, we can force it using the format filter.
ffmpeg -i 000.bmp -vf format=rgb24 -pix_fmt yuv420p -vcodec libx264 -profile:v main -crf 16 first.mp4
The order of the components in RGB32 seems to do with endianness:
PIX_FMT_RGB32 is handled in an endian-specific manner. An RGBA color
is put together as: (A << 24) | (R << 16) | (G << 8) | B This is
stored as BGRA on little-endian CPU architectures and ARGB on
The descriptions of the various related formats ...
While I always guessed that the big / little endian was more a matter of patents rather than performance,
Nope little endian was developed as a performance optimization whern moving to multi byte words. https://en.wikipedia.org/wiki/Endianness#Optimization
Nothing to to with patents. Different representation have different advantages and disadvantage. ...
In this case, the problem didn't come from ffmpeg/avconv.
The rawvideo source I use offers different color formats to be used:
When I extract a png file (which was fine), the bgr24 color format is used.
When I capture a video, avconv automatically chose one of the yuv formats.
I guess the clamping to (16..235) did ...
Without knowing the video properties, my generic answer is
ffmpeg -i in.mp4 -vf geq=lum='p(X,Y)':cb=128:cr=128 out.mp4
This will reset the color information, but pass the luma plane intact. Add -crf 0 for truly lossless re-encoding.
This is the faster way,
ffmpeg -i in.mp4 -vf extractplanes=y,format=yuv420p out.mp4
The luma plane is extracted, and then ...
YUV color encoding with 4:2:0 chroma subsampling is the only widely safe pixel format for web playback, although for certain codecs, other pixel formats may be supported.
FFmpeg auto-selects the pixel format for the output as not all encoders support all pixel formats. It will select the pixel format which best preserves the source bit depth, chroma ...
Yes, as it says a couple of lines above, colormatrix supports only 8bpc (8-bit per component) pixel formats. So, when a 16-bit input is filtered with colormatrix, it will be converted to 8-bits. And won't get converted back to 16-bit unless manually done or auto-converted due to output encoder limitations. But that's pointless anyway, as the precision has ...
Since I cannot use hyperlinks in comments, here is the gist of my research:
This answer on a reddit post suggests, that the reason for the color-shift is the way illegal and legal colors are handled. So maybe the "broadcast colors" effect can help limit the color-range to the legal range? I'd recommend giving that a quick shot.
If that doesn't work,...
Theoretically, instead of 3 × 8 = 24 bits per every pixel you need 3 × 10 = 30 bits for every pixel, which gives multiplier 2^30 / 2^24 = 2^6 = 64, i.e. 64 times greater file size than for 8-bit color info.
Practically, there is also alpha channel (10 bits instead of 8 bits), which means another multiplier is 2^2 = 4, so altogether the file size will be 256 ...
The question is impossible to answer in a general way.
If a camera offers to record in RGB, it is likely using a completely different codec that could be better or worse. Very few cameras will actually record video in RGB, so if you see the option in a menu, it may be referring to something very particular about the color handling of video on that specific ...
Are YUV and YCbCr the same thing? → strictly, no. The former is applied to analog signals, and the latter to digital. But media apps (like Mediainfo) use YUV as the designated term.
It doesn't make any sense to say RGB 4:2:0, right? → Not theoretically incoherent, but I haven't seen any codec that implements subsampling for RGB pixels except for Bayer RGB ...
You may need to perform a “trim pass” to export to Rec709 colour space.
Matching colors in Rec. 2020 and Rec. 709 masters
When some colors are translated to the narrower gamut of Rec. 709, they may look
different. To ensure that the Rec. 2020 master and Rec. 709 submaster look similar, ...
As I understand it, ffmpeg creates a raw image buffer with the input files it is given, then applies effects such as scaling and then encodes. So if you use ffmpeg to do the scaling and encoding to a 4:4:4 codec it should do what you want:
ffmpeg -i "my_gh4_422_4k.mov" -vf scale=1920:1080 -c:v prores -profile:v 4 -c:a copy "my_prores_444_1080.mov"
It would ...
I use the trapcode suite as well, the issue has more to do with the fact that even though you may be working in an sRGB workspace at 32 Bit; your monitor output is 8 bit. 10 Bit monitors are available but unless you forked up a lot of cash - you are viewing 8-bit.
The way to solve gradient problems like this - with this as well as any other gradient in AE/...