Re: [Gegl-developer] babl roadmap



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.

/Ø


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]