SDR to HDR on Resolve by Eclair Cinéma France

We observed many differences between Resolve 12.5 and 14. The version 12.5 is not used anymore, but we use it as comparison to test version 14. We would like to share with you some observations we think useful to improve workflows in Resolve. These observations concern mainly workflows for SDR - HDR remastering.

Prores HDR Rec.2020 St2084 : Resolve 12 vs Resolve 14
On Resolve 12 the renders in Prores 4444 XQ, with colorspace HDR Rec2020 St2084 checked, presented a color shift in comparison with renders in TIFF. Colors are slightly different, mainly in Red, TIFF is conform with our grading, Prores is not.

- We compared renders (grading, TIFF and Prores) in a timeline in Resolve without color management to be sure renders are not modified. Grading vs TIFF : no difference on vectorscope neither on screen. Grading vs Prores : difference on vectorscope and perceptible on screen.

- Analyze renders in Transkoder (Colorfront) : color volume rotates slightly between two renders. It seems to us that it shifts like if render of prores was encoded in wrong primaries. The shift looks like a shift between R2020 and P3 primaries.

On Resolve 14 the problem does not occur when we select "colorspace". Our observation on this topic is that different colorspaces like Rec2020 and Rec2100 are not well described for the encoding in Davinci and does not make coherence with recommendations.

Tests and results described on this document : 20171101 - COMP_PXQ_R12_vs_R14

20171101 - COMP_PXQ_R12_vs_R14.jpg (151.2 KiB) Viewed 2950 times

Soon the test suite : DNxHR 444 Rec.2020 St2084 : Resolve 12 vs Resolve 14

How do you import ProRes to transkoder?
Do you manually overwrite its interpretation (set that it's HDR/2020)?

Don't rely on reading color tags- this is far form being robust and properly supported by any app.

We only imported it in Transkoder.
These tests were made with the version 2016.
We couldn't set any hdr color parameters at the input.

Now with the v2017 we must set the HDR Colorspace.
We have the choice between Rec2020, DCIP3-D65 and Rec709.

To set this parameter you must know the Colorspace of the file. You can't guess it.

Resolve puts medatata in the file via the color managment, that you can recover/see in mediainfo.
But don't rely on it 100%

And with Transkoder 2017 do you still have those problems?

DNxHR 444 Rec.2020 St2084 : Resolve 12 vs Resolve 14

Because Prores was not satisfying in colors, we were wondering if we could find a format equivalent. So we try DNxHR 444 which allows similar quality and weight.

Ø We didn't have the same problem of color shift with this format (neither version 12 or 14). We have the same color between grading and DNxHR.

20171030 - COMP_DNxHR444_R12_vs_R14.jpg (503.37 KiB) Viewed 2604 times

HDR metadatas vs Prores4444XQ compression :

HDR norms require to have metadata embedded with our image HDR master. It's metadata like Max CLL and Max FALL. We grade with a clipping at 1000nits, so we would have Max CLL metadata at "1000nits". This master will be used for other deliveries like H265 Blu ray.

When we export Prores 4444XQ (on version 14) we get compression, that's normal, but this compression creates pixel higher than 1000nits. We know that H265 will lead to more compression and potentially more of these high pixels, but on Prores4444XQ master we should reduce this effect in one way or another cause each HDR master is not acceptable. This problem was not occuring in SDR cause the format will clip values in full or legal range, but with HDR we have to think differently because code values are not use the same way.

Clipping signal at 1000nits while grading was not enough so we try using OFX with lower clipping (ex 800nits).

Ø To render in TIFF with a clipping at 1000nits provide us a good master with no pixel higher than 1000nits cause there is no compression. It's our reference. Output ColorSpace > Gamma = ST2084 1000 à no color shift, TIFF analyze on Transkoder "pass", this means no value higher 1000nits

Ø Render in Prores4444XQ. Output ColorSpace > Gamma = ST2084 1000 à even though we clipped the signal we find higher values.

Ø After few tests with lower clipping, we found that we should use Output ColorSpace > Gamma = ST2084 800 to get a master in Prores4444XQ that would "pass" Transkoder analyze. With Color Space Transform OFX we can adjust more precisely the clipping and a clipping at 850 seems to be sufficient on all the images we tested. We had the same observations on DNxHR.

We propose : ? research on how clip compression while encoding?

Test document :

20171025 - R14_TIFF_PXQ_DNxHR_Luminance_Mapping-page-001.gif (821.76 KiB) Viewed 2603 times

Very interesting
thanks

Salut,

Absolutely no idea if it has any influence and if the cache has been used:
Is the cache format good for HDR or> = 16 bit?

HDR metadatas vs Prores4444XQ compression :

HDR norms require to have metadata embedded with our image HDR master. It's metadata like Max CLL and Max FALL. We grade with a clipping at 1000nits, so we would have Max CLL metadata at "1000nits". This master will be used for other deliveries like H265 Blu ray.

When we export Prores 4444XQ (on version 14) we get compression, that's normal, but this compression creates pixel higher than 1000nits. We know that H265 will lead to more compression and potentially more of these high pixels, but on Prores4444XQ master we should reduce this effect in one way or another cause each HDR master is not acceptable. This problem was not occuring in SDR cause the format will clip values in full or legal range, but with HDR we have to think differently because code values are not use the same way.

Clipping signal at 1000nits while grading was not enough so we try using OFX with lower clipping (ex 800nits).

Ø To render in TIFF with a clipping at 1000nits provide us a good master with no pixel higher than 1000nits cause there is no compression. It's our reference. Output ColorSpace > Gamma = ST2084 1000 à no color shift, TIFF analyze on Transkoder "pass", this means no value higher 1000nits

Ø Render in Prores4444XQ. Output ColorSpace > Gamma = ST2084 1000 à even though we clipped the signal we find higher values.

Ø After few tests with lower clipping, we found that we should use Output ColorSpace > Gamma = ST2084 800 to get a master in Prores4444XQ that would "pass" Transkoder analyze. With Color Space Transform OFX we can adjust more precisely the clipping and a clipping at 850 seems to be sufficient on all the images we tested. We had the same observations on DNxHR.

We propose : ? research on how clip compression while encoding?

Test document :

20171025 - R14_TIFF_PXQ_DNxHR_Luminance_Mapping-page-001.gif

It's normal to see single pixels going out of 1000nits and as you said- after h265 encoding you may have plenty more of them.

This is why standards like EBU-R103 for HD delivery allows not only for signal to have thresholds e.g. go to 103%, but also to have 1% of the of the frame to be outside of those thresholds. For HDR there are no proper guidelines yet as far as I understand.
Is it end of the world to have few pixels above 1000 nits? TVs will do tone mapping on this signal anyway, so I don't think it will ever cause any problem (really be visible).

You should stay with RGB based format in this case to avoid any intermediate YUV<->RGB conversions.
Try Cineform instead of ProRes/DNxHR as it operates in RGB in its 12bit RGB mode. It may work way better as there won't be any YUV->RGB conversion on the way.

You can also test this. Render TIFF and then use latest ffmpeg with -vf zscale. You need to specify range, primaries, matrix, transfer for in and out as per: https://ffmpeg.org/ffmpeg-filters.html#zscale-1. You can use this as reference: viewtopic.php?f=21&t=60707&p=347213&hilit=zscale#p347213 (adjusting it correctly to your case) to convert to YUV based format: ProRes or DNxHR or even v210 (to see if compression adds additional issues). Analyse this in Transcoder. Zscale is very high quality conversion engine.
You can also export v210 out of Resolve to see if this has problems with going outside 1000nits.
I still think there may be some additional issues with Resolve.