Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color correction comments on the PNG spec 2nd ed. PR #3

Closed
svgeesus opened this issue Jan 14, 2021 · 5 comments
Closed

Color correction comments on the PNG spec 2nd ed. PR #3

svgeesus opened this issue Jan 14, 2021 · 5 comments
Assignees
Labels
bug Something isn't working commenter satisfied question Further information is requested

Comments

@svgeesus
Copy link
Contributor

Raised by: Henri Sivonen
Originally raised: Sun, 15 Jun 2003

Quotes from http://www.w3.org/TR/2003/PR-PNG-20030520/

It is recommended that explicit gamma information also be provided
when either the first or second methods is used, for use by PNG
decoders that do not support full ICC profiles or the sRGB colour
space. Such PNG decoders can still make sensible use of gamma
information. PNG decoders are strongly encouraged to use this
information, plus information about the display system, in order to
present the image to the viewer in a way that reproduces what the
image's original author saw as closely as possible.

I think it would be appropriate to warn implementors about the
undesirable consequences of focusing only on PNG colors when the the
PNG image is presented in some larger graphical context such as a
HTML+CSS page or an SVG graphic. Inconsistent color within such an
aggregate document looks worse than the colors of the entirety being
slightly off but consistently.

When the incoming image has unknown gamma (gAMA, sRGB, and iCCP all
absent), choose a likely default gamma value, but allow the user to
select a new one if the result proves too dark or too light. The
default gamma may depend on other knowledge about the image, for
example whether it came from the Internet or from the local system.

Instead of recommending guessing a "likely value", I think it would be
better to recommend that decoding applications that also handle other
color sources (eg. GIF, JFIF, CSS) treat the color values of unlabeled
PNGs consistently with other other unlabeled color sources. That is, it
would be desirable for a given RGB value to be presented as the same
color in a Web browser regardless of the RGB values source (CSS,
unlabeled JFIF, GIF, unlabeled PNG) in order to be able to mix various
color sources in a design.

The original PNG specification emphasized doing something with gamma
over making PNG images look good as components of a larger web page
design. As a result, some browsers (eg. Safari, older versions of Opera
and some really old Mac builds of Mozilla) treat PNG colors
inconsistently compared to all other color sources reducing the
usefulness of PNG images as components of larger designs. (More at
http://iki.fi/hsivonen/png-gamma.html)

@svgeesus svgeesus added the question Further information is requested label Jan 14, 2021
@svgeesus
Copy link
Contributor Author

@hsivonen

Naturally things have moved on since this very old comment was posted. However the specification still needs to be maintained so I am tracking down, and trying to resolve, any bugs that have been reported.

In terms of browser handling (the quoted text primarily refers, it seems, to a stand-alone image viewer) it seems this would be better handled in the referencing specifications?

For example CSS Color 4 currently states 4.5. Color Spaces of Untagged Colors

Colors specified in HTML, and untagged images must be treated as being in the sRGB color space ([SRGB]) unless otherwise specified.

An untagged image is an image that is not explicitly assigned a color profile, as defined by the image format.

also in 4.4. Color Space of Tagged Images

An tagged image
is an image that is explicitly assigned a color profile, as defined by the image format. This is usually done by including an International Color Consortium (ICC) profile [ICC].

For example JPEG [JPEG], PNG [PNG] and TIFF [TIFF] all specify a means to embed an ICC profile.

Image formats may also use other, equivalent methods, often for brevity.

For example, PNG specifies a means (the sRGB chunk) to explicitly tag an image as being in the sRGB colorspace, without including the sRGB ICC profile.

Tagged RGB images, and tagged images using a transformation of RGB such as YCbCr, if the color profile or other identifying information is valid, must be treated as being in the specified color space.

Does this sort of wording in referencing specifications cover it, or is there text that should be added (or deleted0 in the PNG specification itself to deal with your comment?

@hsivonen
Copy link
Member

Thanks for following up on this.

I think the quoted part about untagged color spaces from CSS Color 4 already fixes this to the extent that section is considered to override whatever the image format specs say.

However, I think it would also be good to say in the PNG spec itself something along the lines of: If an untagged PNG image appears embedded in a vector graphics or document format, the color values should be treated the same as untagged RGB values in that format.

@svgeesus
Copy link
Contributor Author

Sorry it took so long! @hsivonen please review this draft erratum to see whether the proposed wording satisfies your concern.

@svgeesus svgeesus added the bug Something isn't working label Jan 19, 2021
@hsivonen
Copy link
Member

Yes, it addresses my concern. Thanks!

@svgeesus
Copy link
Contributor Author

That erratum should be folded into the Editor's Draft.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working commenter satisfied question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants