Notice of Meeting - Output Transforms Architecture VWG - January 19, 2022

Output Transforms Architecture VWG Meeting

Wednesday, January 19, 2022
1pm Pacific time
Add to calendar (.ics)


Dropbox Paper homepage for this group:

We use the same GoToMeeting URL and phone numbers for all VWG meetings.

You may join via computer/smartphone (preferred) which will allow you to see any presentations or documents that are shared, or you can join using a telephone which will be an audio only experience.

Please note that meetings are recorded and transcribed and open to the public. By participating you are agreeing to the ACESCentral Virtual Working Group Participation Guidelines.

Audio + Video

Please join my meeting from your computer, tablet or smartphone.

Audio Only

You can also dial in using your phone.

Dial the closest number to your location and then follow the prompts to enter the access code.

** United States: +1 (669) 224-3319 **
** Access Code: 241-798-885 **

More phone numbers:

Australia: +61 2 8355 1038
Austria: +43 7 2081 5337
Belgium: +32 28 93 7002
Canada: +1 (647) 497-9379
Denmark: +45 32 72 03 69
Finland: +358 923 17 0556
France: +33 170 950 590
Germany: +49 692 5736 7300
Ireland: +353 15 360 756
Italy: +39 0 230 57 81 80
Netherlands: +31 207 941 375
New Zealand: +64 9 913 2226
Norway: +47 21 93 37 37
Spain: +34 932 75 1230
Sweden: +46 853 527 818
Switzerland: +41 225 4599 60
United Kingdom: +44 330 221 0097

The recording and notes from meeting #38 are now available.

5 Likes

A little post about the flare compensation model used in OpenDRT:

The tonescale function has the following parameters

  • s0 - input domain scale
  • s1 - output domain scale
  • p - power function controlling contrast
  • t0 - toe compression for flare/glare compensation

Here is a graph with just the function. Play with the parameters to get a feel for what they do.

Here is a graph with the model I’ve built to describe a mapping between scene-referred images to display-referred output images. This model is based on my own testing and preferences and can absolutely be modified as deemed necessary.

The flare compensation is defined in the model as t_{0}=\frac{1}{L}, where L = display peak luminance. This simple relationship seemed to describe well the amount of flare compensation required as display peak luminance increased (at least on my single hdr display device). This puts flare compensation for SDR at 0.01, which is pretty strong. Feel free to modify as deemed necessary.

1 Like

Thanks for the details, thinking through the flare compensation in real display environments; we should consider the impact of the surround as well as what the effect of power budget in HDR devices resulting in limited capabilities for full screen brightness.

Perhaps we need to also figure out the displays’ own flare and how this interacts (very much a refinement in my book)

Kevin

The power budget in current HDR devices in an annoying thing and it applies mostly to LCD screens as OLED screens are already rated to a lower peak brightness. You can either grade to 60% of the rated peak brightness or grade to the peak brightness and trust them to do the right thing. I prefer the later option considering that LCD devices rated for peak 1500 nits and sustained 1000 nits are already starting to appear :slight_smile: . Btw, LG OLEDs rated for 600 peak nits do a great job at downmapping content graded for 1200 nits.