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. bonus: 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. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
