Graphic text elements issue - ACES in DaVinci Resolve

Tags: #<Tag:0x00007f6dbff5dd98> #<Tag:0x00007f6dbff5d9d8>
(Ihe) #1


When using ACES(ACEScct) in DaVinci Resolve, I am having trouble getting graphic text elements (like maintitles and end credits) looking as intended - often they look rather bad, with very bad staircase(jagged) edges and color shifts.
This applies both to text displayed over image and on black. The problem seem to persist no matter the bit depth or if the source file format is TIFF, PSD or PNG.
Assigning the correct IDT (usually sRGB) does nothing to remedy said issues.

Have anyone experienced similar issues, and perhaps even worked towards possible solutions?

Perhaps I am missing a vital link on how to propper work with and interpret graphical text elements within ACES and DaVinci Resolve.

While I have never found Resolve to especially proficient at displaying graphical text elements (even in DaVinci YRGB), in ACES the problem seem to be in a different order of magnitude.

Kind regards,

1 Like
(Charles Boileau) #2

@ihe. I was just re-testing this about 15 mins ago. It’s still a problem and BMD is aware of it.

The problem is that we cannot color manage the titles and it’s hard to tell where they fall into the ACES workflow.

It would be great to get some insight from the ACES people.


(Willian Aleman) #3

Hi Ihe,

This is probably because in DR, Color Management Preferences you are using the old 3D Lookup Table Interpolation >Trilinear<. Please, try to change it to >Tetrahedral< to see if this can smooth the interpolation caused by the Trilinear setting.

(Charles Boileau) #4

This has an impact when using ACES? I thought it was only when using LUTs.


(Willian Aleman) #5

I believe it’s global. I saw a demonstration of it in a recent workshop, (Color Management for Film and TV) I attended with Dado Valentic in NYC, where his was using ACES workflow.
I’ll confirm this once I get back to the studio on Monday.

(Charles Boileau) #6

Thanks! I’ll also try!! This might mean that certain OFXs might work better also!

(Nick Shaw) #7

Tetrahedral is a method of LUT interpolation. It should have no effect on the built in ACES transforms in Resolve, as I believe those are implemented with shaders, not LUTs. If you include your own LUTs in an ACES workflow, the use of tetrahedral interpolation is recommended for those.

(Willian Aleman) #8

Nick, thanks for the clarifying this.

(Thomas Mansencal) #9

@nick: This is actually very interesting because it might be tricky to say without seeing the code / disassembly.

Even though the ACES transforms are built as fragment shaders, it doesn’t mean they are not applied as a 3D LUT, actually for performance reason they could / should: Essentially you apply your whole colour correction stack onto a RGB / IPT / YCbCr / Pick_Your_Favorite_Colourspace cube that you finally apply on the image as a 3D LUT, this is much much faster than processing millions of pixels. It could in turn introduce interpolation artefacts.

(Nick Shaw) #10

Interesting indeed. A quick test indicates that switching between tetrahedral and trilinear in ACES mode has no effect on the code values in rendered images.

(Jimmy Zhu) #11

The best format for text with alpha channel that I found out is 16 bit DPX. I always transcode Tiff or PNG into 16 bit DPX in AE and reimport them into Resolve. The edge becomes way smoother than what we get from the original Tiff or PNG.

1 Like
(Peter) #12

I noticed that in Aftereffects when discussing the use of sRGB elements in an ACES environment.

When I want a sRGB full white I need a codevalue of about 16. If you then write black text onto that (with a value of 0) the antialiasing around the edges of the text seems to be “eaten up” by the high power of the white. So far I have not found a solution other than adding titles after the RRT/ODT.

I was also wondering if maybe the inverted RRT/ODT for sRGB elements may also corrupt the alphachannel. But I don’t know.

Here is my other thread about using sRGB in ACES.

(Margus Voll) #13

I have seen similar issued and have assumed it is Resolve bug. To a degree it helps to use input transform as rec . What BM has said about it?

(Boris Tivchev) #14


I am faced with the same issue using png files in an ACES workflow in DR.

Has anyone found a fix for that?


(Yerlan Tanayev) #15

I have same issue, but when I see playback all titles are smooth and clean without antialising problems

(Yerlan Tanayev) #16

30 Try this settings they should work

(Adam Fiori) #17

I’m experiencing the same issue here, in Resolve Studio (16 Beta,) working under ACES, imported PNGs used on a timeline — at the moment — are pixelated and unusable. Tatrahedral had no effect; I’ve also tried the above settings, Resize Filter: Smoother and Anti-alias edges: ‘On,’ however, the result is the same, unusable.

Has anyone else found a resolution to this issue?

1 Like
(Christiaan Daniel Wouda) #19

Hi Adam,

If your image contains an alpha channel, make sure its alpha mode (Straight vs Premultiplied) is interpreted correct in Clip Attributes. Also make sure that down the line people have been consistent with this alpha mode. If the image is not the same size as your timeline set the resize filter to 'bilinear or ‘bicubic’ not to Resolve’s own algorithms ‘sharper’ or ‘smoother’ and use ACES 1.1.

In the future, if possible, process this asset, image / logo through a color managed workflow and set a proper IDT when you import it and don’t use PNG.

Hope it helps, Chris

(Krystian Naja) #20


How about built-in titles, I have noticed problems with them too?
Do you have any ideas or workarounds?

1 Like
(Karsten Missot) #21


I did have the same problem, ‘fuzzy’ titles (weird edges, pixelated etc), i found a solution, hope this will help you too:

Apply an OpenFX effect: Color space transform, on your title clip. On input gamme (second option), select the same input color space as your project.
If you’re not sure, ‘linear’ should be doing the trick also.

Maybe this solution also helps with .png’s, not sure. Also not sure if this is a good or bad solution, but it did saved me from a workaround -> after effects.

Kind regards.