yahvuu wrote:

what an inspiring post.

> peter sikking schrieb:
>> I must also point out that this save + export change is also a
>> change in attitude for GIMP. it clearly supports that our high-end
>> users work in no-loss xcf all the time (if they want to store
>> results) and that also means avoiding doing things like merging,
>> flattening, applying masks, reducing colours. that is all part of
>> the export scenario.
> what about using the same mechanism for export as it
> is planned for managing the GEGL tree?
> I'm referring to http://gui.gimp.org/index.php/GEGL_analysed,
> especially your quote "ah, GEGL will solve that".

wow, that is ages ago I wrote or read that...

> That means for the user, all export functionality could be represented
> by a tiny GEGL tree/list which provides operations for flattening,
> color reduction, background creation, writing files and so on.
> This tree gets executed anytime the user exports her image.

what is interesting is your idea to use an operation chain to
automate the export. I say chain because for users this GEGl
graph stuff will be represented as a linear list. I say
automate because it has elements of script/macro creation in it.

one important thing to remember is that just getting GIMP to
export a png should not involve having to set up a macro.
that should just work in its improved dialog click-y way.

another thing we are seeing is that whenever there is a reduction
in fidelity (colour-bits or resolution) there is a need for users
to do optimisation (sharpening, corrective painting).

my rough plan for supporting that looks like overlaying the
image with a projection screen (lets not call it a layer)
that simulates the lowering of fidelity. then this projection
screen itself could contain several layers of optimisations
and corrections that users may want to take. the high fidelity
image data is still available for further development.


that recent ars technica review had a really clarifying metaphor
for cymk for print workflows. along the lines of: the cymk file
is the LP pressing of the rgb master tape. seeing this cymk
conversion as a fidelity reducing (colour gamut) 1-way conversion,
it looks like the projection screen plan above could be the beginning
of a working cymk support solution.


         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture

Gimp-developer mailing list

Reply via email to