Make it easier to serialize in-memory Configs that contain Lut1DTransforms and Lut3DTransforms
メンテナーはふだん 4 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Config::serialize() と、issue で説明されているメモリ内の Lut1DTransforms および Lut3DTransforms の扱いから始めてください。どのシリアライゼーションまたは前処理のアプローチが意図されているのかを明確にし、その後、同等のシリアライズ可能な表現と YAML のアーカイブが成功したことをどのように検証するかを定義してください。
索引モデルが issue の本文から書いたものです。
説明
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...!
- 主要言語
- C++
- スター
- 2.1k
- フォーク
- 503
- 平均マージ
- 8日 3時間
- マージ済み PR（30日）
- 10
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
AcademySoftwareFoundation/OpenColorIO のほかの issue
-
Inconsistent run-time library usage for locale handling breaks GPU code generation on some systems.オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
AcademySoftwareFoundation/OpenColorIO#2351 · コメント 2 件 ·
メンテナーはふだん 4 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
AcademySoftwareFoundation/OpenColorIO#2340 ·
メンテナーはふだん 4 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
AcademySoftwareFoundation/OpenColorIO#2329 ·
メンテナーはふだん 4 日以内に返信
-
Build failure on GCC/MinGW (MXE): std::ifstream constructor mismatch with Platform::filenameToUTF()オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
AcademySoftwareFoundation/OpenColorIO#2283 ·
メンテナーはふだん 4 日以内に返信
-
Documentation
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
AcademySoftwareFoundation/OpenColorIO#2280 · コメント 1 件 ·
メンテナーはふだん 4 日以内に返信
AcademySoftwareFoundation/OpenColorIO の issue をすべて見る
似ている issue
-
Component: Python API
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
Vector35/binaryninja-api#8649 ·
メンテナーはふだん 3 日以内に返信
-
ai_p2 comp-parquet-reader-v3
難易度 2/5 半日 初心者へのやさしさ 66/100
ClickHouse/ClickHouse#124986 ·
メンテナーはふだん 1 日以内に返信
-
bug product: very_good_flutter_plugin
難易度 1/5 1〜3時間 初心者へのやさしさ 78/100
VeryGoodOpenSource/very_good_templates#654 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
AcademySoftwareFoundation/OpenImageIO#5550 ·
メンテナーはふだん 2 日以内に返信