On Wed, Oct 8, 2014 at 4:25 PM, scl <scl.gplus@xxxxxxxxx> 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 _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
