Thursday, March 19, 2020
9:30am - 10:30pm PT (Los Angeles time / UTC-4:30pm)
Please join us for the next meeting of this virtual working group (VWG). Future meeting dates 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
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
@matthias.scharfenber outlined his simple algorithm (with the caveat that it should be a conversation starter rather than an actual proposal, because it is overly simplistic and has many issues). Will share a description on a separate ACES Central post.
@joachim.zell pointed out that AP0 is a relevant and necessary archival container and that data should be preserved, and also that we should use the best tools available to solve this problem right now, knowing that it may not be 100% perfect and also be obsolete in the future when a better workflow comes along.
@hbrendel and @joseph pointed out the necessity of knowing your source gamut (beyond just AP0 container) as well as your target gamut, otherwise you end up with a very general mapping that is good for some cases but much to extreme in others
Put out a call for examples of gamut mapping - ideas, failures, etc to show the group in a visual way
Noted that @SeanCooper has a jupyter notebook with some work to share soon - be on the lookout for that.
If we were to start taking meeting ‘notes’ to distribute after each meeting, is that more/less useful than the transcript/recording? (this accumulation of highlights is sort of what we’re thinking, to keep conversations going)
Acknowledgement that times are weird right now - anything we can do to make participation more productive or helpful please let us know, door for feedback always open!
Does everything from A to B: Pulls down the sensitivities we have, compile Mitsuba with them, renders and output the images. It is a quite slow operation because the Google Colab VMs are underpowered but a) it should work b) is reproducible c) can run on beefier hardware on GCP.
Glad to hear Agnosticism will cripple the capabilities of the algorithm or make some desiderata/requirements impossible to fulfill.
That would be very useful for people to catch up and get up to speed quickly. This very message @carolalynn is great in that respect!
This was continuing to irk me a bit as well, though I’m sure for different reasons.
As a general note, I was getting a bit concerned that we were muddying the waters a bit in our calls. Namely that we set the general guidelines to focus on a generic input/output agnostic A-Gamut to B-Gamut conversion, which is a fair delineation to draw, but the immediate conversation that follows is getting example media that exhibits “the problem”. This is probably just a failure of understanding the mixed conversation of the phone calls, but to me it seemed like we were talking about two different things.
I just want to be clear that if the goal for now is this generic anything-to-anything gamut conversion, we really shouldn’t be looking at media to judge it. We really only can/should be judging its performance on technical merits. That is, based on whatever technical requirements we set for the algorithm, and not any aesthetic or case-study specific way.
What I’m worried about doing, is say that we’ve created a “generic anything-to-anything” gamut conversion, when in reality all we’ve done is solve a very specific problem that was a problem circa 2020. In some ways it reminds me of the RRT’s design and its “sweeteners”, where it was proposed as generic rendering transform but in reality was designed to solve very specific issues of that time. Granted I wasn’t involved when that happened, but that’s roughly how I understand the situation.
Again, I’m not saying that we’re doing that, but I do want to make sure we don’t do it by accident. If we do want to prioritise solving very specific circa 2020 issues that solves “the problem”, that’s totally fine too, I just don’t want us to sell it as a “generic” solution.