Re: [Gimp-developer] [Gegl-developer] babl roadmap

[Øyvind Kolås <pippin gimp org>]

On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> The "sRGB as PCS" architecture outline in babl/docs/roadmap.txt will likely
> collapse under its own weight. The roadmap should be amended to reflect a
> more accurate assessment of the amount of work the planned architecture will
> entail.
>
> The babl roadmap says:
>
> "Babl currently only supports formats using the sRGB primaries, quite a few
> editing operations including gamma adjustments and multiply compositing
> relies on the chromaticities of the space used, permitting at least linear
> formats with other chromaticities is highly desirable"
>
> As the purpose of the roadmap seems to be guiding future development, the
> list of editing operations that rely on the chromaticities of the RGB
> working space needs to be expanded. The following list is not complete, but
> it's a start:

The place for this would be in the GIMP wiki; where the state of
migration from old type gimp plug-ins to GEGL ops, as well as other
tracking state of ops are maintained.
http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL

> The roadmap says "permitting at least linear formats with other
> chromaticities is highly desirable". It is unclear why "permitting" should
> be limited to "linear formats". All of the operations listed above depend on
> the working space chromaticities, regardless of whether the RGB values are
> linear or perceptually uniform.

This has to do with which capabilities one chooses to implement early,
since it would bring a functional system, the non sRGB TRC are nice to
have but not as fundamental as custom chromaticities. Not having
custom TRCs for custom formats; means that those formats would be
using the sRGB TRC until such support would be added.

> Indeed, some (and probably many) operations, that work just fine on linear
> unbounded sRGB values, are *very* dependent on the chromaticities when
> performed on perceptually uniform RGB values (for example drawing a
> gradient).
>
> Someone should check all editing operations for perceptually encoded RGB to
> figure out which operations depend on the chromaticities, and then add these
> operations to the list of operations that need to be special-cased in the
> planned "sRGB as PCS" architecture.

The per-op working pixel representation are part of GEGLs design, thus
it isn't really special casing - but specifying.

/Ø