ACES Gamut Mapping VWG Meeting #14
Thursday, May 28, 2020
9:30am - 10:30am PT (Los Angeles time / UTC-4:30pm)
Please join us for the next meeting of this virtual working group (VWG). Future meeting dates for this month include:
Dropbox Paper link for this group:
We will be using the same GoToMeeting url and phone numbers as in previous groups.
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.
First GoToMeeting? Let’s do a quick system check: [https://link.gotomeeting.com/system-check]
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
Thanks for the recap!
Not all the imagery that enters into the system does it via a vendor blessed IDT, e.g. RAW to ACES, etc…
The IDTs will hopefully get better but we reasonably cannot build a solid system while thinking it will be the case or we need to impose absolute requirements on IDTs themselves, but as of now, AFAIK, there are not.
Mapping from infinity is certainly not practical and we are bound to the reality of floating-point number representation (and storage) with maximum representable values being:
- Half16: 65504
- Float32: 3.40282E+38
With that in mind and given that (to my dismay) inter-exchange must be done with Half16 as per the ACES container specification, it puts 65504 as a reasonable absolute limit: Under the current specification, nobody will ever receive or send files with ACES relative exposure values over 65504.
From Spectral Locus to the intersection of AP1 with the Spectral Locus. We need to consider the non-physically-realisable values beyond the Spectral Locus that AP1 can represent.
Intersection or union? Isn’t it the union of the horseshoe of the spectral locus and the triangle of AP1?
In Set Theory, the union of AP1 and Spectral Locus would be the set of elements belong to either AP1 and Spectral Locus or both of them. We want the set of elements that belong only to both of them, i.e. the intersection, i.e. AP1 ∩ Spectral Locus.
Exactly. The above read to me like “in AP1, but outside the spectral locus” which is not in the intersection. But maybe I’m misunderstanding what you’re getting at.
We need to consider the non-physically-realisable values beyond the Spectral Locus that AP1 can represent are undesirable in some processes.
Yes that makes sense. Sorry for my misunderstanding.
No worries, I should have been explicit!