Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise

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

On Wed, Oct 8, 2014 at 4:25 PM, scl <scl gplus gmail com> wrote:
> I consider this design decision critical for two reasons:
>
> 1) Extra conversions every now and then produce overhead -> increase
> computation time -> decrease performance.
> One part of GIMP's product vision is [high working speed] and I don't
> see how extra overhead can speed up things. And I would not claim GIMP
> and GEGL to be tigers, especially when it comes to large images.

Babls conversions are often transparent since they occur where data is
copied anyways and memory access is more expensive - the ones doing
unpremultiplication of alpha being among the exceptions (as well as
when we end up hitting reference paths where we are starting to use
new and not even attempted optimized combinations of formats.)

> For example adjusting brightness and contrast with preview of a
> 5184x3456 px photo happens immediately in PS CS5 (from 2010). GIMP
> 2.8.14 takes 7 seconds and the GEGL tool 'brightness-contrast' takes
> 16 seconds for the same image on the same machine.

Performance is a concern, but it is different parts of the
architecture that needs improvement for that type speed up...

With a GEGL GUI that is not GIMP I've experimented with the new
mip-map rendering capabilities recently added to GEGL and previewing
of on canvas brightness contrast or gaussian blur/unsharp mask on a
10000x5000 image is instant (it processes somewhere between the number
of pixels on screen and 4x that, not more). Allowing you to both
adjust the op, pan and zoom at will.

> 2) Extra computation steps can introduce computation and rounding
> errors and thus cause wrong results.
>
> These effects might be very low for each single operation, but will sum
> up when many operations are combined (which naturally happens when
> editing an image).

Accumulated errors would be a huge concern in 8bit compared to in
single precision floating point.

> I also think that it should be the user's decision whether s/he wants to
> apply an operation to a coloured image, a grayscale image or a mask.
> Leaving this decision solely to the developer (who's not necessarily an
> artist) doesn't satisfy the claim to be a high-end image manipulation
> program.

That decision is not set in stone because of the format asked for by
the GEGL operation, it is the task of GIMP on top of GEGLs
abstractions to provide the means to do so.

> Therefore I think it's better to let all operations work on the same
> appropriate colour space (big enough and computable precisely and
> efficiently) and do conversions only on the interfaces to the outside
> world: importing and exporting images, displaying, working with ICC
> profiles etc. IIRC there was a hint on that in one of the
> former posts to this topic - what where the reasons to not to do so?

The we have to juggle a large set of different types of pixel formats
already? The initial thinking was that linear working in RGB and HDR
was sufficient, that is what the current babl is sufficient for, one
uses ICC based conversions to get into the internal formats which are
supposed to have efficient management, programming naming and
conversions. And uses an external CMS for interacting with the
outside. As Elle has repeatedly pointed out, that is not sufficient;
and the scope of what is considered natively juggled pixel formats
must be extended.

/pippin