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

[scl <scl gplus gmail com>]

Hi Pippin,

I hope you don't see my lines as picking on your work, but as the
constructive criticism as it is meant. GIMP has performance issues,
especially with large images and modern camera sensors are just
delivering them.

On  8.10.2014 at 4:47 PM Øyvind Kolås wrote:
> On Wed, Oct 8, 2014 at 4:25 PM, scl <scl gplus gmail com> wrote:
> > 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.)

What I don't see is not there? - Let's not put the head in the sand.
The point is not whether they are transparent or not, but whether they
are necessarily done or not.
Also, how does memory access instead of converting come in here?


> > 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.

This is a display trick to give the user immediate control (and a good
idea for GIMP, too). However, the whole image has to be processed
anyway. Display tricks can hide an underlying problem, but not solve
it.

> > 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.

...which ends up in refusing the op or converting the data and the
circle closes here. Or is there something else?

> > 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?

I thought of the same (=a common) colour space for all ops, leading to a
commonly shared pixel format which makes conversions unnecessary.
You and Elle are the right people to find that space and fine tune its
implementation and I hope you both are open enough to find a good
solution together.

Kind regards

Sven