Problem with bit depth when importing Prores 4444 and HEVC 10bit files

[Railway FX]

Hello!

I noticed, that when i'm importing these types of files

mov ProRes 4444 10bit

mov ProRes 4444 XQ 10bit

mp4 HEVC 444 10bit/16bit

Adobe After Effects interprets them as 8bit and shows Millions of colors instead of Trillions and unwanted banding appears.

There is no way to change import settings, but i'm definitely sure, that these files have more bit depth (checked using Nuke, ffprobe, PotPlayer).

When i'm trying to use ProRes/HEVC with 422/420 chroma subsampling - AE imports them correctly.

I've attached project files and sample videos.

ProRes files rendered inside After Effects (Beta) 17.1.2

10/16bit mp4 h265 with 444 chroma transcoded using ffmpeg.

mp4 HEVC 422 10bit 

"ffmpeg.exe" -n -i "D:\Prores\Gradient_ProRes4444.mov" -c:v libx265 -preset slow -pix_fmt yuv422p10le -q 0.18 "D:\Prores\Gradient_h265_10bit_422.mp4"

mp4 HEVC 444 16bit

"ffmpeg.exe" -i "D:\Prores\Gradient_ProRes4444.mov" -c:v hevc_nvenc -preset slow -pix_fmt yuv444p16 -q 0.18 "D:\Prores\Gradient_h265_10bit_444.mp4"

[R Neil Haugen]

I think I've heard in other places some questions about both Premiere and Ae with 4444 10-bit plus files.

Neil

[JohnColombo]

Hi Railway_FX,

Thanks very much for reporting this issue. The team is now tracking this issue internally as DVAAE-4215476. If there are any updates to this bug, this thread will be updated.

Thanks again for reporting this issue and thank you for trying out After Effects (Beta).

- John, After Effects Engineering

[Felix Dames]

Hey John,

are there any news for this ProRes bug?

It's still in AE versions from 17.1.4 up to current Beta version 17.6.0.

This is a major issue for professional work and should be number one on your priority list.

Here is an AE User Voice link if you haven't noticed it yet:

https://adobe-video.uservoice.com/forums/911311-after-effects/suggestions/41633581-after-effects-17-...

Another ProRes bug exists when rendering ProRes with RGB+Alpha Premultiplied. With alpha channel premultiplied alpha channel is wrong compared to a correct rendering when Alpha Straight is selected. The Alpha premultiplied bug is best to see with a transparent gradient.

Would be great if we could get a fix soon, because lot's of our clients deliver files as ProRes 444 12bit. We need to work on these and loosing color bit depth is not acceptable...

Thanks and all the best,

Felix

[JohnColombo]

Hi Felix,

Thank you so much for reporting these issues. The first issue ( where ProRes4444 is misinterpreted as 8bit ) is currently being investigated but there are unfortunately no updates at this time.

The second issue you've raised is one I don't think we have had reported before. Would you be able to describe in greater detail what is going on when rendering ProRes with RGB+Alpha Premultiplied? With screenshots if possible.

Thanks again for reporting and for using the Beta. And thanks for any additional information you can provide,

- John, After Effects Engineering Team

[Felix Dames]

Hey John,

regarding the second issue I raised (Alpha Premuliplied bug), I did some more tests and have to admit that it's not a rendering bug how it looked at first. It's a ProRes4444 footage interpretation or an footage unpremultiplication bug of After Effects. I double checked the rendered alpha channels Straight and Premultiplied and compared them mathematically by difference and they null/zero out so that proofs they are identical and the rendered alpha channel is correct for both Straight and Premultiplied. They also import and look correct in Premiere Pro.

But if these correctly rendered files are imported back into AE for comparison, the alpha channel values for Straight and Premultiplied Alpha channels are still correct and identical but for the Premultiplied Alpha test file the unpremultiplied RGB values are wrong a bit off and darker compared to the original AE composition and the Alpha Straight test file!!! I strongly believe that's bug.

Doing exactly the same test but rendering with GoPro Cineform Codec instead of ProRes4444 does not have the described issue (wrong unpremultiplied RGB values) from above.

That proofs it's a ProRes4444 footage interpretation or a footage unpremultiplication bug!

I still need to do some more tests to find out what's really going on but I already found some more interesting things I want to share:

For one of my rendered ProRes4444 test files I recognized something strange:

This ProRes4444 test file was created with AE Project settings:

Color Depth = 16 bits per channel

Working Space = None,

Blend Colors Using 1.0 Gamma = OFF

Assume Working Gamma = 2.4 (Rec. 709).

The composition settings for background color was pure black RGB [0,0,0]. (as for all my test files)

I rendered the test file with RGB+Alpha Premultiplied and Color Depth = Millions of Colors (8bit)

It's important to notice that the AE Projekt Color Depth is 16 bits but rendering is done to only millions of colors (8 bit). Only with this combination the following issue happens.

When this ProRes4444 file is imported back into AE like all other ProRes4444 (alpha premultiplied) test files unpremultiplied RGB values are wrong. But additionally if I hit the "Guess" Alpha Channel button in AE's Interpret Footage dialog the black color RGB [0,0,0] (Premultiplied - Matted With Color) changes to RGB [2,0,2]! Where do these color values come from? BUG? Doing the exact same test but rendering it with GoPro Cineform Codec the "Premultiplied - Matted With Color" does not change from RGB [0,0,0] to RGB [2,0,2]! It stays where it should at RGB [0,0,0] like all my other test files do when pushing "Guess" Alpha channel. I have no idea why only this special test file behaves differently when pushing "Guess Alpha"?!?

Well, it's not so easy to explain, I hope it was understandable.

Would be good to hear if you are able to reproduce it.

Felix

[Felix Dames]

WOW it's absurd Adobe knows about this nasty and confirmed bug since June 2020 and is tracking it internally as DVAAE-4215476, there is a uservoice thread about it I already posted, this bug exists in all AE versions including all beta versions since AE 2019 v.16.1.3 and Adobe doesn't care!!! ProRes4444 is still broken although it's the most used codec in post production and this bug prevents entire post production facilities from upgrading to AE 2020. This again proofs that AE Uservoice is useless for bug reporting as well as this forum as it seems. Sorry to come along rude but if I see that Adobe is using it's development resources to update a homescreen nobody asked for, redesigning the UI Composition Panal nobody asked for, putting lipstic on a pick with an ugly 3D Gizmo instead of rebuilding 3D from scratch with real meshes and proper viewports (that's what the community asked for)... instead of fixing such a fundamental ProRes4444 bug then I need to ask myself how long I'm willing to rent broken software! [RANT OFF] Sorry but sometimes things have to be said LOUD: FIX IT ASAP!

And still I recorded a video for Adobe showcasing the bug:

AE_Footage_Interpretation_Bug.mp4

Cheers Felix

[R Neil Haugen]

Felix,

I understand your feelings of course. There's several major issues for a couple of my workflows also. And have been so for in one case about three years.

However, the total number of people with a similar problem from these is relatively a small segment of the total user base. And many things I find not particularly useful have been advanced.

But there are a ton of other users who are thrilled that those things have been advanced. A lot. No matter what I think about those issues.

I've had engineers at NAB point out some of the things that were way high on the list because of the total number of requests. Which had my jaw hanging. Yea, many of the things that are very highly requested seem to me and many of the engineers to be rather frivolous, absurd, or plain dumb.

But it's not the fault of the engineers that so many users want those things. Particularly as the engineers don't have that much of a say in the overall direction and development of the app. That's above even the program heads, and rests with the marketing & experience people ... M&E. The people that do everything by metrics.

The UserVoice is one of their main metric sources, and especially the one we users can have influence over. And given how many of the users ask for things you and I would find questionable, we do need to file posts over there for the truly more important things.

Neil

[Felix Dames]

Neil,

I appreciate your comment and I'm aware of these marketing practices or priorities in development...

But this is a bug report thread so please let's not turn it into a discussion about other things.

Thanks 😉

@JohnColombo 

Have you and or the developers watched the video showcasing the bug?

AE_Footage_Interpretation_Bug.mp4

Any answer or reaction would be very welcome.

Felix

[R Neil Haugen]

They are doing more engineer oversight here than on the normal user forums, but I think we users all wish it was more. Especially that they were able to get after things reported much faster.

Watched your video, and it's well done. The bigger surprise for me was the DNxHD/R was not "that" bad, as I know others that have shown the bit-depth of 444 DNx can be incorrect. I actually expected that to have a greater variance than your test showed.

Yes, it necessary to get this fixed as it's a bit of a mess as you're showing there.

Neil

[Felix Dames]

As it looks for today, it's finally fixed in AE Beta 18.1.0 (Build 30) although there is no word about it in the bug fixes release notes section!?!

- Footage Interpretation bug of ProRes444 as only 8bpc including incorrectly marked as "Millions of Colors" - FIXED!

- Footage Interpretation bug of ProRes4444 with Alpha Channel Premultiplied resulting in wrong unpremultiplied RGB values - FIXED!

Thank you Adobe 😉

Is this already fixed and rolled out in AE 18.0.1 official release canditade?

Felix