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

[scl <scl gplus gmail com>]

On  7.10.2014 at 8:43 PM Øyvind Kolås wrote:
> On Tue, Oct 7, 2014 at 8:13 PM, scl <scl gplus gmail com> wrote:
> > On  4.10.2014 at 5:59 PM Øyvind Kolås wrote:
> >
> > > Almost, developers decide which pixelformat is appropriate for their
> > > operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale
> > > formats as well as formats used with digital video with different data
> > > types; currently the set of babl formats.
> >
> > perhaps I missed or forgot something: what happens if a GEGL operation
> > is called with a wrong pixel format - will the operation refuse to work
> > or the data be converted to an appropriate format?
>
> tl;dr: converted to an appropriate format.

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

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

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.

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?

On  5.10.2014 at 6:49 PM Øyvind Kolås wrote:
> You've already been invited, and I invite you again to spend some time
> with the rest of the GIMP team and others with interest in color,
> photography and graphics in Toronto, end of april next year for the
> next Libre Graphics Meeting.
+1. What can go wrong? Sometimes meeting the people and talk things over
at a coffee or beer is better than throwing arguments back and forth.
It's also a great chance to meet creatives and color experts from other
libre-graphics-projects and hear their opinions.

Kind regards

Sven


[high working speed]:
http://gui.gimp.org/index.php/Vision_briefing#value_.2B_traits