Skip to content
This repository was archived by the owner on Jan 12, 2024. It is now read-only.
This repository was archived by the owner on Jan 12, 2024. It is now read-only.

Working color space vs. rendering color space #453

@imagico

Description

@imagico

Based on suggestion by @nebulon42 in openstreetmap-carto/openstreetmap-carto#2492 i am opening this issue here but i am not sure if this is within the scope of this project.

The problem is that the three aims

  • designing colors in a perceptually uniform color space
  • not having to deal with the color representation limitations of the rendering output as a designer
  • being able to use the full range of colors that can be represented in the output color space

are mutually exclusive.

The addition of support for husl colors in #422 tries to find a compromise but essentially sacrifices the first aim in favor of the second and third.

In more general terms this is the problem of having a working color space with a much wider gamut than the rendering color space (which in case of Mapnik is apparently always sRGB). This is not an uncommon problem in applications dealing with colors and the usual approach to this is called color management. Color management is not a solution for all of the problems related to this but it is a framework for managing them independent of the specific color spaces actually used.

So if you really want to address this matter in an universal way you will have to look into color management integration. If this is outside the scope of this project you should still consider:

  • providing the option to specify colors in perceptually uniform color spaces
  • performing color operations, in particular interpolation between colors of different chroma, in Lab color space by default.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions