Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

PNG: write cHRM and gAMA when cICP can't describe the color space

未关闭
  • 哪里不对？
#5,558 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
cpp
领域
backend

调研方向

The issue points to ColorConfig::get_chromaticities() and get_transfer_function_gamma() from #5521 and #5557, plus the PNG, DPX, RLA, and Targa writers; it does not name source files or tests. First read those property changes and inspect how the writers currently choose color metadata. Agree on the two proposed behaviors before implementing; done means the agreed metadata is written safely and the read-back limitations described here are accounted for.

由索引模型根据 Issue 内容生成。

描述

Now that ColorConfig::get_chromaticities() and
get_transfer_function_gamma() exist (#5521, #5557), the PNG writer could use
them for color spaces its cICP chunk can't describe. Before writing the PR, I'd
like to agree on two behavior changes, because each changes what files carry
and how they read back.

What happens today. Writing a gray PNG from each of these color spaces with
OCIO's default config, and reading it back:

Written as The file carries Reads back as
lin_p3d65_scene, srgb_p3d65_scene cICP the same
lin_ap1_scene gAMA 1.0 lin_rec709_scene
g22_ap1_scene, g22_adobergb_scene nothing srgb_rec709_scene
lin_adobergb_scene, lin_ap0_scene nothing srgb_rec709_scene

So a file written from ACEScg reads back as linear Rec.709, and one written from
gamma 2.2 AdobeRGB as sRGB.

Proposal 1: PNG writes cHRM and gAMA when cICP can't describe the space.
When there is no cICP code and no ICC profile, the writer would take the
primaries from get_chromaticities() and a pure power from
get_transfer_function_gamma(), and write cHRM beside gAMA:

  • only together: primaries without a transfer function would be half a
    description, so a log or piecewise curve still gets no chunk;
  • not for Rec.709 primaries, where gAMA alone already says everything;
  • not for primaries cHRM can't store: it holds no negative or zero
    coordinate, so ACES AP0 (blue y is negative) is lost, with a debug message;
  • not for primaries the libPNG in use refuses. Older libPNG releases reject
    some valid ones, such as ACES AP1's red (x + y > 1), and that rejection
    aborts the write, so the writer would check them on a scratch structure
    first.

ACEScg, gamma 2.2 AP1, AdobeRGB and the other spaces above would then carry
their primaries, which browsers and image editors honor.

Proposal 2: writers tag any linear color space as gamma 1.0. Today the gamma
that PNG, DPX, RLA and Targa write is 1.0 only for lin_rec709_scene and names
equivalent to "linear" or "scene_linear". With get_transfer_function_gamma(),
any color space with a linear transfer function would get 1.0, so linear
AdobeRGB or ACES2065-1 would no longer write no gamma at all.

The catch: reading back. OpenImageIO's PNG reader ignores cHRM today, so
these files would still read back with Rec.709 primaries in OpenImageIO, now
with the right transfer function. #5516 proposes reading cHRM and gAMA as
metadata. DPX, RLA and Targa have no field for primaries, so a linear ACEScg
DPX would read back as linear Rec.709 (as a linear ACEScg PNG already does).

Questions

  1. Should PNG write cHRM before OpenImageIO's own reader reads it? Other
    readers would interpret these files correctly right away.
  2. Is gamma 1.0 with unstated primaries better than no gamma for linear color
    spaces in DPX, RLA and Targa?

These would be the first in-tree users of the properties #5521 added.

Assisted-by: Claude Code / Claude Opus 5.5

主要语言
C++
星标
2.4k
派生
716
平均合并
2 天 9 小时
30 天内合并 PR
91

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

AcademySoftwareFoundation/OpenImageIO 的其他 Issue

查看 AcademySoftwareFoundation/OpenImageIO 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。