Make it easier to serialize in-memory Configs that contain Lut1DTransforms and Lut3DTransforms
还没有人认领这个 Issue。
评估
调研方向
从 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
- 派生
- 502
- 平均合并
- 4 天 4 小时
- 30 天内合并 PR
- 5
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 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 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 84/100
-
难度 2/5 1-3 小时 新手友好度 82/100
-
Build failure on GCC/MinGW (MXE): std::ifstream constructor mismatch with Platform::filenameToUTF()未关闭
难度 2/5 1-3 小时 新手友好度 78/100
-
Documentation
难度 1/5 1 小时以内 新手友好度 72/100
AcademySoftwareFoundation/OpenColorIO#2280 · 1 条评论 ·
查看 AcademySoftwareFoundation/OpenColorIO 的全部 Issue
相似的 Issue
-
(S1 - Need confirmation)
难度 2/5 1-3 小时 新手友好度 68/100
CleverRaven/Cataclysm-DDA#89212 ·
维护者通常 1 天内回复
-
Status: Needs confirmation Status: Needs triage
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
ai_p2 comp-dictionary
难度 2/5 1-3 小时 新手友好度 78/100
ClickHouse/ClickHouse#127261 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
NVIDIA-Omniverse/usd-brep#23 ·
-
难度 2/5 1-3 小时 新手友好度 68/100
qbittorrent/qBittorrent#25121 ·
维护者通常 2 天内回复