Lossless Workflows using Premiere Pro, VirtualDub, ffmpeg and others

[jagabo]

ffVideoSource() gets YV24 with ~rec.601 colors.

[SameSelf]

Sadly, while the above method in post #139 appears to produce lossless ProRes444 SMPTE color bars. The workflow appears to break down for the HD SMPTE bars. In the vectorscope below, the Red and Cyan castellations' saturation appears to have been reduced. With that said, when I import the ProRes444 into AE and inspect the Red and Cyan RGB values, they appear to be correct. So maybe it is an interpret footage problem in PP. I am attaching them because others may still find them useful.

RGB Bars


ProRes444 Bars

[SameSelf]

ffVideoSource() gets YV24 with ~rec.601 colors.

Thanks. Add ffVideoSource to the list. ffmpeg/ffmbc/ffVideoSource.

[chris319]

What color space do you want to be working in? BT.709?

Some of these give me pause.

R: [191,0,1]
B: [0,1,192]

These are no longer pure primaries as a small amount of blue has been added to the red and green to the blue.

SMPTE bars were originally designed and spec'd for analog NTSC and the specs are in HSL, so for 75% saturation you have to calculate saturation using whatever color space you're working with.

Does SMPTE give digital values in any of its color bar specs? It would cost over $100 to buy the spec and find out. My lingering question is whether the so-called SMPTE bars are true to any spec.

True-spec color bars might give your vectorscope program fits.

[poisondeathray]

This is what AE says the dynamically linked PP generated SMPTE tone and bars RGB values are:

Grey: [191,191,191]
Yl: [191,190,0]
Cy: [0,191,190]
G: [0,191,0]
Mg: [191,0,192]
R: [191,0,1]
B: [0,1,192]
-I: [0,63,105]
+Q: [65,0,119]
W: [255,255,255]
Bl: [0,0,0]
Left pluge: [0,0,0]
Center pluge: [0,0,0]
Right pluge: [10,10,10]

Technically, the pluge is supposed to be -4,0,4 IRE, but -4 gets clipped in RGB space. Also, don't worry that the colors don't appear exactly right, for example, that R is not [191,0,0], because both collapse to the same 8-bit YUV value as do the others.

So, yes, they are 75% saturation (191/255 = 75%); otherwise the vectorscope will look wrong.

Studio swing applies to YUV, not RGB. 8-bit RGB is always [0...255].

Huh?

How are you getting those values with a dynamically linked PP bars? They look like rounding errors. They look ok in CC, and the negative pluge is there (you just need to work in 32bpc float to be able to detect it in the info palette, and it's visible in the waveform) . In float, the negative pluge will be -0.04, just like "Red" would be R 0.7500, G 0.0000 , B 0.0000 etc...

But even in 8bit, "Red" should be 191,0,0 etc.., from dynamic link so something is up

Or what video were you specifically talking about ? maybe I'm misunderstanding

[chris319]

Eureka! I found the spec for SMPTE rp219:

http://car.france3.mars.free.fr/HD/INA-%2026%20jan%2006/SMPTE%20normes%20et%20confs/rp...9%20mirehd.pdf

For the purposes of these bars only, 240 is considered peak white. Thus, 75% white = 180 = 240 * 0.75.

Here are the 8-bit RGB values I got. Saturation = 75%. Percent luminance = 8-bit value given in spec / 240. Thus, yellow = 168 / 240 = 70%

rgb(104,104,104));gray 43%
rgb(180,180,180));75% white
rgb(178,178,45));yellow 70%
rgb(42,171,171));cyan 60%
rgb(41,167,41));green 55%
rgb(137,34,137));magenta 26%
rgb(126,31,31));red 21%
rgb(24,24,97));blue 12%
rgb(104,104,104));gray 43%

[chris319]

Pop quiz:

What are the saturation values of the following colors?

#1. RGB 255,0,0

#2. RGB 0,127,0

#3. RGB 64,64,64

#4. RGB 118,0,118

[jagabo]

Eureka! I found the spec for SMPTE rp219:

http://car.france3.mars.free.fr/HD/INA-%2026%20jan%2006/SMPTE%20normes%20et%20confs/rp...9%20mirehd.pdf

Annex B, Pattern 1 corresponds to ColorBarsHD() in AviSynth:

ColorBarsHD(pixel_type="YV24")
Crop(0,0,-0,128) # just the top section
Stackvertical(last.ConvertToRGB(matrix="rec709"),\
	      ColorYUV(cont_u=-256, cont_v=-256).ConvertToRGB(matrix="pc.709").Subtitle("Y"),\
              UtoY().ConvertToRGB(matrix="pc.709").Subtitle("U"),\
              VtoY().ConvertToRGB(matrix="pc.709").Subtitle("V"))

Alternatively, you can generate SD colorbars and convert them to HD colorbars. Replace the ColorBarsHD() line above with:

ColorBars(pixel_type="YUY2").ColorMatrix(mode="rec.601->rec.709").ConvertToYV24()

For the purposes of these bars only, 240 is considered peak white. Thus, 75% white = 180 = 240 * 0.75.

No. Peak white is Y=235. And black is at 16. Therefore, 75 percent brightness is (235-16) * .75 + 16 = 180.25.

Here are the 8-bit RGB values I got. Saturation = 75%. Percent luminance = 8-bit value given in spec / 240. Thus, yellow = 168 / 240 = 70%

rgb(104,104,104));gray 43%
rgb(180,180,180));75% white
rgb(178,178,45));yellow 70%
rgb(42,171,171));cyan 60%
rgb(41,167,41));green 55%
rgb(137,34,137));magenta 26%
rgb(126,31,31));red 21%
rgb(24,24,97));blue 12%
rgb(104,104,104));gray 43%

No. On proper conversion to full range RGB all the RGB values of the colored bars are either 0 or 191 (with rounding errors giving 190 or 192 instead of 191, or 1 instead of 0, on some values. You can use an RGB reader on the above image to see this.

[SameSelf]

Haha! Yes! Rounding errors!!!!

When round tripping in 8-bit YUV space, six RGB colors on average collapse to the same YUV value. So let's try another way to think about this. What are the YUV values that PP is generating? Let's look at Red:

75% YUV BT.709 Red: [51,109,212] (this is the same value in this link: http://avisynth.nl/index.php/ColorBars_theory)

What does that transform to in 8-bit RGB space?

RGB R:[191,0,1]

So, there is no way one can generate pure RGB Red [191,0,0] from 8-bit YUV space. This is the consequence of what we have hashed out in earlier posts in this thread. Just do the math, and you will see for yourself what I am talking about. Maybe CC operates in 10-bit YUV space? That is the only way one can generate pure RGB Red from YUV.

I read ITU-R BT.1729 last night before posting because I suspected something was up. Unfortunately, it is mute on 100/0/75/0 bars. But I did check my transforms against the 100/0/100/0 bars in the publication. My calcs mapped perfectly for 8-bit systems.

As far as the -4 pluge getting clipped. Yes, I can see the negative pluge on the scope in PP. But when it is rendered out to RGB or UYVY, it gets clipped. And if these issues don't exist in CC, well, that stinks for me. Can you provide the colorbars that PP CC generates?


EDIT: One final note. I uploaded my RGB bars to this thread. If you have any problems with the RGB values I posted. I encourage you to download my RGB bars and investigate the RGB values yourself.

[chris319]

No. Peak white is Y=235. And black is at 16. Therefore, 75 percent brightness is (235-16) * .75 + 16 = 180.25.

See Fig. 3-2 on page 6 of the spec. The second bar from the left is labelled "75%W". It is achromatic so Pb and Pr are both 0. The Y value given for this bar is 180 which is 75% of 240. 75% of 235 is 176.25.

So 75% of what?

[poisondeathray]

So, there is no way one can generate pure RGB Red [191,0,0] from 8-bit YUV space. This is the consequence of what we have hashed out in earlier posts in this thread. Just do the math, and you will see for yourself what I am talking about. Maybe CC operates in 10-bit YUV space? That is the only way one can generate pure RGB Red from YUV.

Yes, I'm talking about internally in AE, not the exported file. Your post made it seem you were reading the values in AE. You have "perfect" bars in AE ie. float value of 0.75 for 75%, no rounding errors, and negative RGB values such as in the negative pluge area are "kept" internally when you use 32bpc

32bit mode in AE that allows you to access data that would normally be clipped by a standard sRGB conversion. For example if you have a full range YUV source, it gets treated as RGB in AE, but you still have access to YUV data before your manipulations (such as full range, superbrights/darks) . Thus you can work with negative RGB values that normally would be clipped in most other programs working in RGB. (You also have the option to work in other color models like Adobe RGB, or Rec1361 Wide Gamut RGB, etc...)

As far as the -4 pluge getting clipped. Yes, I can see the negative pluge on the scope in PP. But when it is rendered out to RGB or UYVY, it gets clipped. And if these issues don't exist in CC, well, that stinks for me. Can you provide the colorbars that PP CC generates?

Recall that PP is working in YUV, and the values are subsampled. If you recall, the point of dynamic linking to AE was to keep perfect bars, not subsampled chroma. Internally in AE they still are perfect (in 32bpc) , including the negative values. The potential problem arises when you export something out that isn't "perfect", because it's no longer float, and you have all the RGB<=>YUV issues and rounding issues discussed earlier. You can export something close to perfect, and that is 32bit EXR (image sequence). It's a 32bit linearized workflow - very common in high end FX work.

EDIT: One final note. I uploaded my RGB bars to this thread. If you have any problems with the RGB values I posted. I encourage you to download my RGB bars and investigate the RGB values yourself.

RGB values should be "perfect" for each bit depth. I'm not talking about a converted from YUV to RGB bars. I'm talking about original RGB bars. So if you didn't get 191,0,0, something is "wrong" with the export.

And looking at post 121, "HDColorBarsRGB.avi", the Red is off , It reads 191,0,1. So something is indeed wrong. I posted "perfect" 8bit RGB bars earlier (minus the negative pluge)

[chris319]

I uploaded my RGB bars to this thread. If you have any problems with the RGB values I posted. I encourage you to download my RGB bars and investigate the RGB values yourself.

It would be helpful if you could post a link or give the post date to your color-bar values. If this was a video file, it was suggested that some of the color errors might be due to VLC.

[poisondeathray]

Did you start with avisynth HD bars for that video? That could be the cause of the problem, because they are YUV444 (YV24) to begin with. When you convert to 8bit RGB, your RGB bars will get rounding errors. The post listing the "off" values sounded like you were reading them off in AE from PP dynamic linked internal bars & tone.

If you take the HD bars from wikipedia as an image for your source (either use ImageSource(), or just drop them on a timeline), those will give you perfect 8bit RGB bars. The internally generated bars from PP to AE are also "perfect", but at a higher bitdepth in float values as described earlier - so that give you more options to test true higher bitdepths. Unfortunately you don't have as many optoins for controlling the intermediate steps as something like vapoursynth

[SameSelf]

Well, I am not sure what the problem is. Here is my workflow. Maybe you can tell me where the problem is?

1. Generate 1920x1080 Bars and Tone in PP (similarly for HD Bars and Tone)
2. Drop into a timeline in PP
3. Dynamically link the timeline in AE
4. AE Project Settings are 32 bpc (float). Working space is None. Mousing over the Red bar shows RGB [0.7495,-0.0010,0.0022].
5. Drop the dynamically linked Bars into a comp. No effects or layers.
6. Send comp to render queue
7. Render settings are Format: AVI; Channels: RGB; Depth: Millions of colors

If I import this rendered AVI back into AE, Red is not pure red.

[poisondeathray]

It's off somewhere, at the dynamic link stage, because it should read 0.7500,0,0 before exporting (ie. 75% pure red) .

Save your PP project and open the .prproj project file in AE directly

[SameSelf]

Oddly enough, AE doesn't see the Bars and Tone solid if I import the .prproj file. AE puts it in a solids folder, and it is just solid black including the timeline. Very strange. Only seems to work when I dynamically link.

[chris319]

on proper conversion to full range rgb all the rgb values of the colored bars are either 0 or 191 (with rounding errors giving 190 or 192 instead of 191, or 1 instead of 0, on some values.

Answering my own question, I think I see where they get "75%":

191 / 254 = 75.2%

191 / 255 = 74.9%

What do you say, jagabo?

[jagabo]

on proper conversion to full range rgb all the rgb values of the colored bars are either 0 or 191 (with rounding errors giving 190 or 192 instead of 191, or 1 instead of 0, on some values.

Answering my own question, I think I see where they get "75%":

191 / 254 = 75.2%

191 / 255 = 74.9%

What do you say, jagabo?

Yes, of course. The range for 8 bit full range RGB is 0 to 255.

(255-0) * 0.75 + 0 = 191.25

And that rounds to 191 as an integer.

And I told you earlier where 180 comes from for the 75 percent greyscale Y value. Valid values of Y are 16 (full black) to 235 (full white). So 75 percent grey is 3/4 of the way between those two values.

(235-16) * 0.75 + 16 = 180.25

which rounds to 180 an an integer. It's only coincidental that 180 is 3/4 of 240. 240 has nothing to do with the calculation.

[poisondeathray]

Oddly enough, AE doesn't see the Bars and Tone solid if I import the .prproj file. AE puts it in a solids folder, and it is just solid black including the timeline. Very strange. Only seems to work when I dynamically link.

Sorry , that's what I meant: file=> import file, and select the project (ie. open it up directly as if it were a "video", not a project file). Most people just double click the project area and the open file dialog box will pop up. This is essentially the same as dynamic link. Also make sure your sequence settings in PP were correct in the first place.

If you still get "off" values, then it must be a CS6 bug with dynamic link or the PP bars. At that stage in AE, the numbers should be perfect. I would drop known 8bit RGB bars (e.g. one of the ones I uploaded) into a correct PP sequence and dynamic link that. Because those are known correct RGB values, if the numbers are off in AE, then you know it's a problem with CS6's dynamic link, not PP's internal bars & tone.

[SameSelf]

I dropped the PNG you uploaded into a PP timeline and dynamically linked that to AE, and the RGB values were fine, i.e. Red was [191,0,0]. However, when I dynamically link the Bars and Tone using the exact same process, Red is [191,0,1]. I checked that all the sequence settings were the same (e.g. max bit depth was checked). So I am not sure what the problem is. Also, when I render out your PNG colorbars from AE and load the RGB AVI back into AE, Red is still pure [191,0,0]. Transcoding to UYVY produces essentially the same image on a vectorscope as my original UYVY bars. The only difference was -I, and it was very minor. So at the end of the day, it's not that big of deal that the Bars and Tone don't dynamically link as expected into AE.

[SameSelf]

Responding to post #152 above. I thought the process for transcoding to ProRes 444 was breaking down for the HD bars. It appears that the HD bars generator in PP is the problem. So here is my new workflow:

HD Bars Workflow
1. Download the 1920x1080 HD bars PNG from wikipedia
2. Check the RGB values of each bar in AE. No problems. Each bar was a pure color.
3. Encode the PNG to UYVY
4. Import the UYVY bars into PP to overlay over the internally generated HD bars:

a. chroma value are fine
b. the castellations have a luma shift

5. Import the UYVY bars into AE and check out the RGB values:

a. Interesting, Red has a value of RGB[191,0,1]!
b. It appears that this is the source of the discrepancy in the dynamic links discussed above.
c. It would seem that AE converts the Y'CbCr 4:2:2 signal generated by PP to RGB24 in AE. This conversion is why Red is not pure Red in AE.
d. Lastly, the ProRes444 transcode looks fine when overlain over the UYVY transcode.

Anyway, I don't understand why there is a luma difference in the internally generated HD bars and the UYVY transcode. This problem doesn't show up in the SD bars (with the exception of the -4 pluge).

pdr, maybe you might have some insight into what is going on here exactly?

Here are my new HD UYVY bars:

[poisondeathray]

Responding to post #152 above. I thought the process for transcoding to ProRes 444 was breaking down for the HD bars. It appears that the HD bars generator in PP is the problem. So here is my new workflow:

HD Bars Workflow
1. Download the 1920x1080 HD bars PNG from wikipedia
2. Check the RGB values of each bar in AE. No problems. Each bar was a pure color.
3. Encode the PNG to UYVY
4. Import the UYVY bars into PP to overlay over the internally generated HD bars:

a. chroma value are fine
b. the castellations have a luma shift

5. Import the UYVY bars into AE and check out the RGB values:

a. Interesting, Red has a value of RGB[191,0,1]!
b. It appears that this is the source of the discrepancy in the dynamic links discussed above.
c. It would seem that AE converts the Y'CbCr 4:2:2 signal generated by PP to RGB24 in AE. This conversion is why Red is not pure Red in AE.
d. Lastly, the ProRes444 transcode looks fine when overlain over the UYVY transcode.

Anyway, I don't understand why there is a luma difference in the internally generated HD bars and the UYVY transcode. This problem doesn't show up in the SD bars (with the exception of the -4 pluge).

pdr, maybe you might have some insight into what is going on here exactly?

Here are my new HD UYVY bars:

I can't follow along exactly because some things are different in CC and I disassembled my CS6 rig

What "luma shift" are you seeing exactly ?

5a) is expected because AE is converting 8bit RGB to 8bit UYVY , so you 're going to get rounding errors.

For the dynamic link topic - There shouldn't be any discrepancy in dynamic link stage before exporting - because it's supposed to bypass all the conversions and thus errors. It's like a pure signal generator at any bitdepth. The fact that you see 191,0,1 directly in AE suggests some YUV<=>RGB conversion is going on

5c) It shouldn't be YCbCr 422 as an intermediate step, because that would entail subsampling. If you're seeing blurred chroma then maybe that's what you're getting. Earlier you reported it was razor sharp. That was the whole point of dynamic link to AE as you recall ,otherwise you could use PP alone

Prores4444 is a different story - it's supposed to be more reliable / fewer inconsistencies (at least that's what Apple is going to say), but the truth is you can get gamma shifts and mistreatment even with the certified version because there are YUV and RGB variants. Also, It's supposed to be governed by metadata and various tags telling the program exactly what it is and exactly how to treat it, but not all programs write or read that metadata. But DNxHD (any flavour, any encoder, AVid or otherwise, whether MOV or MXF) is even worse in terms of levels - it is horribly mistreated and very inconsistent between programs

Have a look at some of these older tests, look at the pdf. Not much has changed since then. It's a sorry state of affairs
http://www.stopp.se/lab-testing-the-pro-in-apple-prores/?cpage=1#comment-1982

I think the bottom line is test your workflow end to end with your specific encoder implementation, application (and version, because there can be major difference even between point releases) . For example, certified prores4444 (with all tags), works perfectly in AE, but not in PP CC

[SameSelf]

Thanks as always, pdr. I know you are running CC. I was hoping you could download the HD UYVY bars I uploaded above, overlay them on the HD Bars and Tone that CC generates, and see if you see the same luma shift that I see. Or, alternatively, download your own PNG and transcode to UYVY for comparison. The shift is in the 100% saturation castellations only (Red, Blue, Yellow, and Cyan). The 75% bars are fine. For some reason, PP's internally generated HD Bars and Tone has lower luma values for the 100% saturation castellations. And these lower luma values were the reason I thought the ProRes4444 workflow I outlined in post #152 was breaking down. But now, on closer inspection I suspect something is up in PP. It is really weird, and I was hoping to get your expert opinion.

"it's supposed to bypass all the conversions". That leads me to believe that there is a setting somewhere that I don't have properly enabled whether in PP or AE.

As for 5c, I was just interested in looking at the RGB values (easier to do in AE than PP) of the UYVY transcode because I couldn't understand why there was a luma difference in PP. It was while doing this that I noticed the Red RGB value was the same as the dynamically linked color bars as discussed above. It caused me to put two and two together that the internal PP YUV 422 bars must go through a YUV to RGB conversion in dynamic link, mirroring an import of the UYVY bars.

Thank you for the ProRes4444 discussion and link. Truly this is a sad state of affairs. I guess this is why the pros (Hollywood studios) use DPX.

[poisondeathray]

Ok sorry now I get what you're saying . It's PP "HD Bars and Tone" that is the problem. I can confirm the PP generator is "off" to begin with - it is in CC too. If you make a PP sequence from the wikipedia "SMPTE_Color_Bars_16x9.svg.png" for example, and frameserve that into AE , it's 100% identical in AE (no differences using the amplifed differences) , when compared to the original. The frameserver is working as expected

Since your HDColorBars.avi in the most recent post was generated from the wikipedia "SMPTE_Color_Bars_16x9.svg.png" . If you check those against each other in PP, they are the same except for the expected rounding and chroma subsampling differences

DPX has many issues as well (you would think not, but it does) . The reason is there are different configurations for log vs. linear, different black and white points, YCbCr and RGB.

[SameSelf]

Ok sorry now I get what you're saying . It's PP "HD Bars and Tone" that is the problem. I can confirm the PP generator is "off" to begin with - it is in CC too. If you make a PP sequence from the wikipedia "SMPTE_Color_Bars_16x9.svg.png" for example, and frameserve that into AE , it's 100% identical in AE (no differences using the amplifed differences) , when compared to the original. The frameserver is working as expected

Since your HDColorBars.avi in the most recent post was generated from the wikipedia "SMPTE_Color_Bars_16x9.svg.png" . If you check those against each other in PP, they are the same except for the expected rounding and chroma subsampling differences

DPX has many issues as well (you would think not, but it does) . The reason is there are different configurations for log vs. linear, different black and white points, YCbCr and RGB.

Thanks so much for checking. Yes, the SMPTE_Color_Bars_16x9.svg.png is exactly the file I am working with. I was starting to think I was going crazy! Can you believe that the PP HD Tone and Bars generator is off? How much time have I wasted naively trusting Adobe!

OK, great. I now have a 1920x1080 PNG for SMPTE color bars (SD and HD) that will be my gold standards going forward for testing all my workflows. It is a good thing too because Resolve doesn't read RGB based AVI's (AVI support in Resolve is very limited).

I have resisted the DPX route, for sure, and have only become aware of it recently because of Resolve. The good news is the ffmbc ProRes 444 encode I posted above works (I used the PNG as the input not the UYVY avi), even though it screws up some of the meta tags! I was worried that the HD Bars revealed a flaw that the SD bars did not. But that is not the case. There is no color/luma shift. Is it too soon to let out a hurray? I need to test it thoroughly with frameserving, x264 encodes, and so on, similar to that pdf matrix you posted. It is why I have worked so hard in this thread to define a known starting point which I discovered is extremely hard in and of itself. But now I know what people are talking about when they complain about color shifts. It was always mysterious to me before, and I am sure I mangled some video in the past because I was none the wiser. Not anymore thanks to you, jagabo, and everyone else who has helped.

I will likely be posting back with a more thorough description of my workflows detailing what works and maybe what doesn't.

[poisondeathray]

Sameself - Can you test these pr4444 bars in PP and AE CS6 against the "SMPTE_Color_Bars_16x9.svg.png"

[SameSelf]

pdr, they look good. No chroma or luma shifts from what I could see versus the PNG. Testing in AE is a little harder because there is no vectorscope outside of the Synthetic Aperture plug-in and clicking a layer on and off is not possible inside it. However, the RGB values looked good.

How did you generate these? Is it possible for you to generate a ProRes 422 version as well? All my Atomos footage is ProRes HQ 422 10-bit and ideally I would like a set of color bars to attach to my footage to test pipelines.

[poisondeathray]

pdr, they look good. No chroma or luma shifts from what I could see versus the PNG. Testing in AE is a little harder because there is no vectorscope outside of the Synthetic Aperture plug-in and clicking a layer on and off is not possible inside it. However, the RGB values looked good.

How did you generate these? Is it possible for you to generate a ProRes 422 version as well? All my Atomos footage is ProRes HQ 422 10-bit and ideally I would like a set of color bars to attach to my footage to test pipelines.

There is a plugin called "test gear" from the same company that you have to buy separately to get the vectorscope in the main application

The video was done in Nuke. This was a conversion to 10bit YUV Prores4444 (there are 12 bit variants as well as YUV , RGB) from the 8bit wikipedia bars as source. In AE and PP CC, they match up as well - the converted RGB value readouts in 8bit are same as the original. It's not quite lossless but close. I think from compression artifacts, there are a few pixels off at the junctions. (prores4444 still is a lossy codec. Even prores4444 XQ is lossy). You can see them with amplifed differences . Keep in mind those aren't totally correct bars, because they don't have the "negative" values (they are based on the zeroed 8bit RGB wiki source)

10bit444 YUV should be enough to return the original 8bit RGB values, correct ? You guys tested it with all that code, others tested it before with matlab etc... (So instead of 191,0,1, you should get back the 191,0,0, etc...), but it's difficult to test in a real workflow because v410 isn't very common right now (10bit444 uncompressed YUV).

In programs that handle prores correctly, you should get back the original values on this sample (at least on a limted simple color bars test). At first I thought it was metadata tags "guiding" the conversion, but I stripped some of the tags, and it still works in AE and PP CC. So this is some real world evidence that it can be done (mind you a limited test), but it would still be "nicer" to have a v410 test which would be truely lossless

The tags I was referring to are separate from the color primaries, transfer, and matrix ones you sometimes see in mediainfo. For example, there is an Apple colr atom, a colorspace tag, probably some other hidden flags. It's not well documented and I think Apple keeps some of the specs closely guarded because they can charge for prores certification. But if you change some of the tags you can get different results in the receiving application, at least for some software that pay attention to those flags and atoms

The "writing library" field that you see in mediainfo can be "spoofed" by ffmpeg using the prores-ks encoder using the -vendor flag. If you use "-vendor apl0", it will say "Apple" as if was authentic from a mac. It actually does solve some compatibility problems in some software that look for that

The conversion should be possible with vapoursynth, but I'm running a few versions behind and it's a big hassle to swap everything, plugins, python version, as mentioned before, etc.... But I tested it quickly with this old version and it's "off" with ffmbc or prores-ks. I can't access the pixels values easily before encoding in vapoursynth editor , so I don' t know if it's fmtc, vapoursynth itself, vspipe, or ffmbc/ffmpeg prores encoder that is the issue (vapoursynth editor is like avspmod, but doesn't have the color picker to read off pixel values yet in this older version, it might in the newer one)

For people using avisynth, you can open it properly in the 8bit environment by processing it in 16bit stacked using l-smash, dither tools, and disabling dithering. Dithering with certain algorithms will make a solid bar "flip" values as you move along a bar using a color picker to read values (ie. it's no longer a solid uniform color). It's a common reason why bit depth conversions might contain different pixel values than expected. Dithering might be useful on "normal" footage , not so much for solid test bars

e.g this should convert the prores4444 sample to 8bit RGB properly in avisynth, and the RGB values match up

LSmashVideoSource("INPUT.mov", format="yuv444p16", stacked=true)
Dither_convert_yuv_to_rgb (matrix="709", output="rgb24", lsb_in=true, mode=-1)

If you do an amplifed differences test, you can see some loss. (I think due to compression)
In avisynth it could be done like this. Areas in grey are lossless

a=Imagesource("SMPTE_Color_Bars_16x9.svg.png")

LSmashVideoSource("INPUT.mov", format="yuv444p16", stacked=true)
Dither_convert_yuv_to_rgb (matrix="709", output="rgb24", lsb_in=true, mode=-1)
b=last

Overlay(a,b, mode="Difference", pc_range=true)
Levels(127, 1, 129, 0, 255, false)

The observation that avisynth returns the correct RGB values means it can't be hidden flags guiding the conversion (LSmash won't read them)

[SameSelf]

Great write up, thanks. Lots and lots of info to wade through. Some quick thoughts.

Yes, if one starts from 8-bit RGB test bars and converts them to 10-bit YUV, that conversion is "lossless". Anyone who tries to convince you or me otherwise simply doesn't understand the math involved and should stay away from this discussion. I have verified this personally with more than one technique, so I speak with near 100% certainty. It would take a very informed, extraordinary example at this point to convince me otherwise.

However, I use "lossless" in quotes because I am just talking about the matrix conversion. Dithering, chroma subsampling, and compression artifacts are separate issues in my mind that can obviously trip up the inexperienced. If one stays in 4:4:4 space and uses a lossless codec like v410, then theoretically that would be perfectly lossless. I have not tested it though. With that said, the ProRes444 bars scope up very nice despite whatever compression artifacts are present. The only way to know for sure is to round trip like 50 times and see how the bars degrade. Otherwise, ProRes444 is near lossless which is fairly remarkable.

Finally, I didn't realize Nuke had a ProRes export option. I need to look at that more closely again.

And, thanks for uploading the ProRes422 bars. What algorithm did you use for the chroma subsampling?

[poisondeathray]

What algorithm did you use for the chroma subsampling?

The default cubic


Here is a way to do it with ffmpeg prores-ks . It's pretty clean too, if you look at amplified differences, similar pattern so I'm thinking lossy compression artifacts. At least the solid colors return RGB values correctly (when prores is decoded correctly as described above)

You need a ffmpeg build with prores-ks (zeranoe's doesn't have it by default) . I use the autobuild script

ffmpeg -r 24 -i "SMPTE_Color_Bars_16x9.svg.png" -vf scale=w=-1:h=-1:out_color_matrix=bt709 -profile:v 4444 -pix_fmt yuva444p10le -vcodec prores_ks -an -f mov -vendor apl0 ffmpeg_prores_ks_4444_q1.mov

Notice the vendor writing library in mediainfo hahaha

Writing library : Apple