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

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

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

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

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


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