ffmpeg/x264 RGB to YUV

[poisondeathray]

Was that for half float ? I haven't gotten around to finishing up the other tests, but full float seemed fine on all tests so far

[SameSelf]

Yes, it was half float. I don't want to have to use full float

[SameSelf]

It wasn't a color shift but some really bizarre artifacts that looked like neon lights in the black areas.

Doh! I didn't keep close enough notes of my testing apparently. That's what happens when you are up against a deadline and can't remember the exact steps. The green neon artifacts I was seeing were the same as the green artifact in the blue ramp on the belle nuit test chart when linear light is left on during an AE export. If switched off, the green goes away. So to recap:

1. Export as half float PIZ openEXR but TURN OFF linear light
2. Encode with ffmpeg using the -apply_trc linear option since the sRGB LUT is now baked in

[poisondeathray]

It wasn't a color shift but some really bizarre artifacts that looked like neon lights in the black areas.

Doh! I didn't keep close enough notes of my testing apparently. That's what happens when you are up against a deadline and can't remember the exact steps. The green neon artifacts I was seeing were the same as the green artifact in the blue ramp on the belle nuit test chart when linear light is left on during an AE export. If switched off, the green goes away. So to recap:

1. Export as half float PIZ openEXR but TURN OFF linear light
2. Encode with ffmpeg using the -apply_trc linear option since the sRGB LUT is now baked in

Did you mean just uncheckmark non linear working space in the project settings ? 32bpc ? non color managed ?

BTW, there were other problems with dark reds turning blue with the 1st set of tests as well on other patterns (I haven't gotten around to do all the tests yet)

[SameSelf]

No, in the Color Management tab on Output Module Settings in the Render Queue. This at least solves the blue bar turning green and what I was seeing in my real world encodes where dark parts of the image (a night sky to be exact) had very strange neon green artifacts. So from what I can tell it was the exact same problem.

I am not aware of any dark reds turning blue. Which dark reds did you see do that? The only other problems that I see are:

1. Obvious chroma subsampling artifacts in the numbered 1, 2, 3, and 4 regions
2. Dithering noise that can't be turned off


[Attachment 39255 - Click to enlarge]

[poisondeathray]

No, in the Color Management tab on Output Module Settings in the Render Queue. This at least solves the blue bar turning green and what I was seeing in my real world encodes where dark parts of the image (a night sky to be exact) had very strange neon green artifacts. So from what I can tell it was the exact same problem.

Do you see how output profile is greyed out in your screenshot ? Working space "none" . That implies linear workspace is not active. So the problem (from my perspective) isn't the output module conversion to something; it's everything before that.

So that's not going to be a suitable workaround 99% of the cases where EXR is used. The most common reason to use EXR is linear workflow - linear compositing , linear math operations (1+1=2) - so you will get color and levels shift if you delinearize the working space on high bit depth HDR sources, such as camera raw, or multipass compositing workflows (e.g. CG, 3D compositing) . Most operations, effects and compositing operations used in those scenarios will be inaccurate because the gamma isn't compensated for. Each non linear operation amplifies the errors. Actually that's a big reason why programs like nuke are so popular for high end compositing workflows - it linearizes everything in the workspace before any operations are applied.

Basically, if you can find a combination that allows for linear workflow (so all work in AE is done with linear light calculations) all the way until export from AE that works in ffmpeg at half float, then I'd call it a suitable workaround for that AE-ffmpeg half float "bug" .

I am not aware of any dark reds turning blue. Which dark reds did you see do that

The dark reds turning blue were from higher bit depth source tests. The Belle Nuit test chart is 8bit, sRGB, and only has a blue gradient. There is no green or red gradient. It's useful to as a quick test a quite a few things , but there are still others that need to be tested

[SameSelf]

Do you see how output profile is greyed out in your screenshot ? Working space "none" . That implies linear workspace is not active. So the problem (from my perspective) isn't the output module conversion to something; it's everything before that.

That is because my input files were linear, and there is no need to specify a working space because AE defaults to sRGB when none is chosen. So it doesn't make any difference unfortunately as the green artifact still shows up even when sRGB is explicitly specified and linear is left on. From my testing, the problem is specifically related to how ffmpeg handles linear images from AE. Linear images from Resolve do not have a problem.

[poisondeathray]

linearize working space in the project settings, working space sRGB. I think that fixes it for all combinations and inputs. I'll double check tomorrow but that looks like it's working for half float exr

[SameSelf]

I see. Only problem is when I check the linearize working space in the project settings, while my GUI display is not affected, my external display goes linear. So while I hear you regarding linear workspaces, unless I get an external LUT box, I guess my hands are tied. But then again, it wouldn't surprise me if I am doing something wrong! Nevertheless, I did a quick test with linearize working space checked and working space set to sRGB, and after exporting as linear half float, the green still showed up. If you get different results, I'm all ears.

[poisondeathray]

Yes it's working for me now, at least in CC. Maybe they fixed something

Let me double check some things later today, but all tests are working now, even the high bit depth corrupted dark reds

But you were able to get AE's EXR full float linear to work with ffmpeg, right ? In my earlier tests it was only half float that was affected

I'll also take a look on the ffmpeg end to see if there are other switches to control the dither (you should be able to , because it works for other formats) . The thing is I tried many switches, as the filter setting, as input option, as output option, etc... Most of the time on "typical" footage, the dithering is ok, but sometimes you might want to disable, or use something else like sierra, or floyd-steinberg - the point is it would be nice to be able to control it




EDIT: yes I'm certain now it works. I ran a bunch of other tests as well and everything is ok . One the belle nuit test did you interpret or override the interpretation of the chart ? Make sure preserve RGB is uncheckmarked . It should already be interpreted as sRGB profile, if not , set it. Also make sure you clean the cache before you test it again. Maybe even consider rebooting first. If your grading/preview setup doesn't have those controls, you can use view=>simulate output in AE to emulate the output

[SameSelf]

OK, I seem to have got it working. If I go into the Project Settings and check linearize working space then export as openEXR half float linear, there is no green bar. I was resistant to doing this at first because checking linearize working space causes my external display to go linear. My gui monitor is not affected just the Output Device selected in the Video Preview preferences. But I can live this I suppose. I just have to remember to check the linearize working space option prior to render.