Notice of Meeting - Output Transforms Architecture VWG - October 18th, 2023

Output Transforms Architecture VWG Meeting

Wednesday, October 18th, 2023
1pm PDT Add to calendar (.ics)


Dropbox Paper homepage for this group:

NOTE: We will be using Zoom for this meeting.

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
Topic: ACES Virtual Working Group Meetings
Time: This is a recurring meeting Meet anytime

Join Zoom Meeting

Or follow this link: bit.ly/acesvwg

Meeting ID: 993 4048 4145
Passcode: 972426
One tap mobile
+16699006833,99340484145#,*972426# US (San Jose)
+16694449171,99340484145#,*972426# US

Meeting ID: 993 4048 4145
Passcode: 972426
Find your local number: Zoom International Dial-in Numbers - Zoom

The recording is now available.

1 Like

As discussed during the meeting, here is a modified Desmos plot for the cusp intersection, which has a ‘gamma bend’ in the top part as well as the bottom. (Note, in Desmos the expressions may be longer than what you can see in the default view. So you may need to widen the side panel to see everything)

The gamma curve at the top is flipped vertically compared to the bottom one, i.e. J=100 is equivalent to the origin, and the cusp to (1, 1). It could be flipped horizontally instead, so the cusp was equivalent to the origin, and J=100 to (1, 1) which would give a slightly different shaped bulge. I don’t know which is more like what we want. Here is a simple plot showing the two types of shape, using an exponent of 2 to make the difference obvious.

Further note: As a reminder, the curve intersection includes a ‘fudge factor’ (f) to get the approximation (there is no analytic solution to the intersection of a straight line and a power curve) closer to the gamma curve. But in fact the value needs to be 1.0, or there is a discontinuity at the cusp. Although, even with the fudge factor, the intersection does not track exactly with the curve, it should not matter as the gamma curve is not an exact match to the gamut shape anyway. The important thing is that the approximation will give the same result in the forward and inverse direction, so it will not cause an inversion mismatch.

1 Like

The notes from meeting #123 are now available.

Thanks for this Nick

I am curious if there is any problem with the upper (g2) parameter going below 1?

I am not sure if this is 100% necessary, but judging from the fit to display cube Alex was demonstrating, it appears that the upper hull may be both concave and convex in some of those less well approximated areas. (Rec. 709 in that case)

Apologies if this has been specifically discussed, I thought it almost was when discussing possible curve fitting options, but currently Desmos is limited to 1 and above.

It is easy enough to modify the slider/parameter in Desmos and visually it appears to work fine, so I am assuming it can dip a little bellow 1 if that is a better approximation, or is there any reason to avoid doing that?

No reason whatsoever. You make a valid point. I just set the lower bound in Desmos to 1.0 because the initial intent was to make it bulge out, to ensure the approximation enclosed the true gamut hull. But dipping it in where appropriate would be fine to create a better match.

The only concern is that whatever we do has to be generalisable. Since it will vary with target gamuts, we can’t ask people to manually fit the lumps and bumps of a custom gamut if they make a custom DRT.

@priikone has reminded me that the intersection finding method shown in that Desmos is not in fact used in the current DRT. It is something I showed in a meeting as a proposal to improve invertibility of the gamut compression, but it has never been incorporated into the Blink code.

The method currently used is based on the original straight line intersection code which used ‘from’ and ‘to’ points to define a line, and then found the intersection with a straight line from the origin to the cusp. To approximate the intersection with a gamma curve instead, the J values of from and to are modified by the exponent before finding the intersection with the straight line to the cusp.This effectively moves the point found further up the straight line, and then only the M component of that is used as an approximation of the M value at the intersection with the gamma curve.

While this method gives a reasonable approximation to the true intersection, when used in the reverse direction from and to will not be the same, as they are the compressed values. So the approximation will be different.

The intent of the method in the above Desmos is that it uses only the J intersection and compression slope to approximate the intersection, and these two values will by design be the same in both the forward and reverse directions. While it does not exactly match the intersection with the gamma curve either, since the gamma curve is not the true boundary, I believe the path described by the point found using this method is as valid an approximation of the boundary as the gamma curve is.