Re: [Gimp-developer] features



> To elaborate on that, file management is not graphics editors job.
> It's a whole separate tool. For photos I use digikam.

A file browser (Adobe "Brigde") makes sense in Adobe apps because
they're all inter-connected and having an improved file management
tool to exchange assets between tools (more efficiently than the
questionable windows file explorer) is useful.
Anyway, Bridge as far as I can remember was a heavy slug and it didn't
bring much benefit.
Our "design suite" applications aren't connected like Adobe's and
won't be in the foreseeable future.

Regarding the rest of the feature requests, most of them are available
as third party plugins.
There are serveral interesting RAW packages. UFRAW has a module that
imports directly to GIMP, pretty much like Adobe Camera Raw does.
Maybe the rest of the available packages (Darktable, Rawtherapee, etc)
could get some similar modules to interface with GIMP.
That would be interesting.

The non-destructive tools would be really welcome.
You seem to miss one important request for photographic workflow:
working with higher bit depth.
Current 8 bpc isn't enough for high quality manipulation.

Fortunately, making GIMP's core less destructive is high in the
priorities list for next versions.
I'm not a developer, but I'd suggest you to focus your effort on
backing the full migration to GEGL which will give much better quality
and non-destructive editing. The rest can and will be constructed on
top of it.

> You really want to stop using Photoshop
> terminology and switch to plain English :)
> Are we talking about smart objects i.e.
> embedding other documents as layers?

@Prokoudine: Smart objects in Adobe are external "linked" assets. For
instance you can import a vector logo from a different app and the
raster application will rasterize it dinamically. If you change the
external file, the changes will be reflected in the "smart" layer.
It's an interesting concept and can be also used to convert an
internal layer as a dynamic object, in order to apply the
transformation stack without destroying the original pixels.
iirc that's pretty much the idea with GEGL too, so we're fine :)


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