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

Make it easier to serialize in-memory Configs that contain Lut1DTransforms and Lut3DTransforms

Aperta
  • Qualcosa non va?
#2,221 0 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
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
cpp
Ambito
api

Direzione di ricerca

Iniziare da Config::serialize() e dalla gestione di Lut1DTransforms e Lut3DTransforms in memoria descritta nell’issue. Chiarire quale approccio di serializzazione o precondizionamento sia previsto, quindi definire come verificare rappresentazioni serializzabili equivalenti e il corretto archiviamento YAML.

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

Descrizione

Feature Request

Configs that directly employ Lut1DTransforms and Lut3DTransforms (i.e., held in memory) cannot be serialized to a YAML stream. This is in contrast to Configs that indirectly reference such transforms via FileTransforms or BuiltinTransforms.

It would be great if we had a few convenience methods to help users automatically and effortlessly create serializable representations of Configs that would otherwise refuse to serialize() to YAML.

A foolproof method for coercing an OCIO Config into a serializable + archivable representation is to bake CTFs of all Lut1DTransforms and Lut3DTransforms to a [custom?] relative location (prepending to the Config search path, if necessary), whose filenames match the cache IDs of Processors containing each transform; and swapping out the Lut1D/Lut3DTransforms for equivalent FileTransform references.

Alternatively, entire ColorSpace / ViewTransform / NamedTransform / Look transform definitions could be serialized to CTFs with more human-friendly filenames, based on the names given to higher-level Config constructs (e.g, "to.ctf")

Eventually, like #2219 hints at, it would also be very cool if we had methods for intelligently exactly representing / approximating Lut1DTransforms as other (serializable) OCIO Transforms, potentially permitting users to convert entirely unserializable Configs into more-serializable Configs, or to otherwise reduce the need to externalize LUTs or OCIOZ files in the first place. Ultimately, I'd love to see something like this tied in to whatever interface we provide for coercing unserializable Configs as a "preconditioning" step; but I think such efforts are probably worth their own GitHub issue...!

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.