Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Finalize ACES 2 FixedFunctions and remove warnings

Aperta
  • Qualcosa non va?
#2,275 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 4 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
computer-graphics

Direzione di ricerca

Esamina le definizioni fixed-function di ACES e il lettore e scrittore YAML, quindi ispeziona Config_tests.cpp alla ricerca di "experimental" e le descrizioni fixed-function in OpenColorTypes.h. Determina l’ordinamento finale dei canali, la normalizzazione e il comportamento di decomposizione; il lavoro è completato quando le funzioni sono finalizzate, gli avvisi sono rimossi e i marker sperimentali e le relative aspettative dei test sono ripuliti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Needs Discussion

When ACES 2 was implemented, there was some uncertainty in how to decompose the overall Output Transforms into FixedFunctions, and so the YAML reader and writer issue warnings when any of these are used:

FIXED_FUNCTION_ACES_OUTPUT_TRANSFORM_20
FIXED_FUNCTION_ACES_RGB_TO_JMH_20
FIXED_FUNCTION_ACES_TONESCALE_COMPRESS_20
FIXED_FUNCTION_ACES_GAMUT_COMPRESS_20

At this point, we should try to finalize what the fixed functions are and remove the warnings.

I like having a function to convert to JMh, but there are two things I find inconvenient about the current one:

  1. The results are in the hundreds (e.g., J goes up above 800, h goes up to 360) and this makes it inconvenient to use in other tools that would prefer more of a 0 to roughly 1 normalization.
  2. The more conventional channel layout is for hue to be first and lightness to be last. For example, the existing conversions to HSV and HSY use that channel layout.

Currently, in order to use the existing RGB_TO_JMH with the GradingHueCurveTransform, I need to put a matrix on either side to rescale and reorder the channels. My proposal would be to create a new function that is ordered hMJ and has h divided by 360 and J divided by roughly 500.

Similarly, my only concern about the others is whether the inputs/outputs are normalized in a way that is convenient.

As we are currently developing LMTs that may work in JMh, it would be helpful if the optimizer was able to decompose an ACES_OUTPUT_TRANFORM into one or more fixed functions that expects JMh (from an LMT) as input so that a pair of RGB_TO_JMH and JMH_to_RGB could be dropped. Currently, is it possible to replace an ACES_OUTPUT_TRANSFORM with RGB_to_JMH + TONESCALE_COMPRESS + GAMUT_COMPRESS + JMH_to_RGB?

Tagging @KevinJW and @remia for input.

Note: When implementing this, search Config_tests.cpp for "experimental" and clean up accordingly. Likewise remove "experimental" from OpenColorTypes.h fixed function descriptions.

Lingua principale
C++
Stelle
2.1k
Fork
503
Merge medio
8g 3h
PR unite (30g)
10

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di AcademySoftwareFoundation/OpenColorIO

Tutte le issue di AcademySoftwareFoundation/OpenColorIO

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.