Re: Conversions for HDR Canvas Specification

Not helpful.
The worked examples are often useless, as we saw recently in ST 2128 IPT C2.
If provided, they should go into a separate engineering guideline document, not in the standard. Here is where an Excel spreadsheet (or Jeff's calculator) would be useful, as it would let users plug in their own numbers.

Give me the real math and I can verify that the  4/3*pi  or 18/19 formula is correct.
I don't want to verify that 4.188790205 is correct. You're wasting my time.

If you provide both real math and numbers, you're confusing the implementor: which one should I use?
We usually don't approve of programmers writing 4.188790205 instead of 4/3*pi or 18/19.
(It's probably against our company policy.)
Personal note: I've wasted lots of time debugging code where programmers entered long numbers incorrectly, and such bugs are very hard to spot.

Interop is not achieved with 4.188790205. That's too many decimals for float, too few for double, and still will not match 4/3*pi. And besides, the target implementations are probably half-float anyhow.

So just give me the real math! That's what I need. 
The rest is noise. Let's maximize S/N!

Lars

-----Original Message-----
From: Jeff Gilbert <jgilbert@mozilla.com>
Date: Thursday, June 17, 2021 at 1:52 PM
To: Pierre Lemieux <pal@sandflow.com>
Cc: Lars Borg <borg@adobe.com>, Chris Lilley <chris@w3.org>, "public-colorweb@w3.org" <public-colorweb@w3.org>
Subject: Re: Conversions for HDR Canvas Specification

Yes, please!

On Thu, Jun 17, 2021 at 4:25 PM Pierre-Anthony Lemieux <pal@sandflow.com> wrote:
>
> Hi Jeff et al.,
>
> I see two complementary objectives:
>
> - specify mathematical expressions exactly, e.g. 4/3*pi*r^3, so that
> the can be computed to arbitrary precision
> - provide worked examples at a common precision, e.g. 4.188790205*r^3
> at 10 significant figures for float computation, so that interop can
> be achieved
>
> Makes sense?
>
> Best,
>
> -- Pierre
>
> On Thu, Jun 17, 2021 at 3:49 PM Jeff Gilbert <jgilbert@mozilla.com> wrote:
> >
> > I can't speak for others, but I don't want very precise *results* of
> > calculations per se, but rather I prefer to know the calculation
> > methods themselves, and their precise inputs. It's difficult to reason
> > about results without a clear path for how we got there.
> >
> > Eventually I do need the numbers to calculate with, but I got tired of
> > trying to figure out if matrices I found in documentation were right
> > for my particular usecases, and made this:
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjdashg.github.io%2Fmisc%2Fcolors%2Ffrom-coeffs.html&amp;data=04%7C01%7Cborg%40adobe.com%7C6f5f682ce70a49c51be108d931eaf115%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637595707406402752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=62AfqFobSVHCdCpGoPkE7zFcrYs9asnc%2F0SOHBTB0rw%3D&amp;reserved=0 (the
> > calculations are fairly legible in the JS source)
> >
> > Ideally we can give names to constructs, instead of, for example, "use
> > the following very precise matrix given to 10 sig-figs...". If there's
> > a constant that's 18.0/19.0, it's nice to know that, and not just see
> > 0.9473684210526315.
> >
> > I've found this to be a huge ongoing problem and source of confusion
> > in colorspace work, but that naming things and showing-my-work goes a
> > long way to helping.
> >
> > On Thu, Jun 17, 2021 at 3:30 PM Pierre-Anthony Lemieux <pal@sandflow.com> wrote:
> > >
> > > > Please, no long numbers!
> > >
> > > I do not understand this blanket statement.
> > >
> > > The accuracy of individual constants within an expression should be
> > > sufficient to achieve the desired accuracy for the entire expression.
> > >
> > > For example, it would make no sense to specify π = 3.14 in f(x) = π·d
> > > if f(x) is intended to compute the circumference of a circle to an
> > > accuracy of ±0.00001.
> > >
> > >
> > >
> > >
> > > On Thu, Jun 17, 2021 at 2:39 PM Lars Borg <borg@adobe.com> wrote:
> > > >
> > > > Please, no long numbers!
> > > >
> > > > And I’m not alone on this.
> > > >
> > > >
> > > >
> > > > Lars
> > > >
> > > >
> > > >
> > > > From: Chris Lilley <chris@w3.org>
> > > > Date: Thursday, June 17, 2021 at 3:00 AM
> > > > To: "public-colorweb@w3.org" <public-colorweb@w3.org>
> > > > Subject: Re: Conversions for HDR Canvas Specification
> > > > Resent-From: <public-colorweb@w3.org>
> > > > Resent-Date: Thursday, June 17, 2021 at 3:00 AM
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 2021-06-16 11:53, Simon Thompson - NM wrote:
> > > >
> > > > Hi all,
> > > >
> > > >
> > > >
> > > > I’ve added a list of suggested colour forward and reverse transforms between extended-sRGB, extended-linear-sRGB and bt2100-hlg and a suggested simple tone-mapping for displaying bt2100-hlg on an sRGB display to issue #50 - https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2FColorWeb-CG%2Fissues%2F50&amp;data=04%7C01%7Cborg%40adobe.com%7C6f5f682ce70a49c51be108d931eaf115%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637595707406402752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hkplXghqz16%2BA24AMPqBlQk1fkV6KzmhINRR4bXyazA%3D&amp;reserved=0.  I’ve tried to follow the style of the example in TTMLv2 provided by Pierre.
> > > >
> > > >
> > > >
> > > > I can recalculate the matrices to a different number of significant figures if necessary – is there a consensus on accuracy levels for web operations?
> > > >
> > > > In general, since "space of the printed publication"is no longer a concern, I prefer to list to full precision.
> > > >
> > > > I have seen several problems arising from round-off errors and round-tripping, so there is no good reason to round off.
> > > >
> > > >
> > > >
> > > > Would Dolby colleagues be able to add the bt2100-pq versions to the list?  There is a PQ example in Pierre’s TTMLv2 link.
> > > >
> > > >
> > > >
> > > > Best Regards
> > > >
> > > >
> > > >
> > > > Simon
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Simon Thompson
> > > > Senior R&D Engineer
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Chris Lilley
> > > >
> > > > @svgeesus
> > > >
> > > > Technical Director @ W3C
> > > >
> > > > W3C Strategy Team, Core Web Design
> > > >
> > > > W3C Architecture & Technology Team, Core Web & Media
> > >