ACES 2.0 CAM DRT Development

Discussions - ACESNext VWG – Output Transforms
492

Yes, the mistake @priikone picked up only affected hellwig_lib_v057.h. The other v57 DCTL files are unchanged.

Thanks for that. I don’t have an OpenCL system here to test. When I had one before I always found it was far more picky about DCTL syntax than the others.

I’ve pushed an update with your suggested fix.

1 Like
493

I pushed CAM DRT v058 with some new parameter values to my repo. I’ll create a pull request for Alex later after we’ve discussed some things in the meeting.

One thing we’ve talked privately was P3D65 inverse. Previous versions haven’t inverted P3 as well as Rec.709 and to get it inverse better we’d have to increase cusp smoothing, rather than what I’ve been doing lately, which is to reduce it to reduce clipping. This version should bring P3 inverse to same level as Rec.709, but it does come with a bit more clipping in the forward direction in Rec.709.

Param changes (no code changes):

  • Change power of powerP compression from 1.2 to 1.0
  • Change Lower hull gamma constant from 1.14 to 1.145
  • Change Smooth cusps value from 0.18 to 0.12
  • Change Smooth J value from 0.02 to 0.0 (becomes possible to eliminate)
  • Change Smooth M value from 0.18 to 0.25
1 Like
494

Just pushed a v58 update to my DCTLs, including versions tagged to be used in the custom ACES Transforms directory.

3 Likes
495

During last night’s meeting, @jpzambrano9 pointed out that the reach cusp (AP1) table in my DCTL did not quite match the table in the Blink. I realised that my Python which generates the tables was still incorrectly using D65 white for the AP1 reach, despite that being fixed in the Blink a few versions ago.

I have just pushed a commit to fix that in the v58 DCTL.

3 Likes
496

Hello guys,

I have a quick question.

It is super nice to see this group wrapping up and I was wondering if now would be a good time to discuss the “flare/glare compensation” ?

Are we compensating for the “low contrast” look of the curve by boosting this parameter ?
DRT_CAM_Kernel_daniele_t_1 0.04

Is this intended ? I think it was mentioned also in this thread.

Regards,
Chris