> On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek <thebodzio@xxxxxxxxx> > wrote: > >> Considering the use cases where fine grained control over the > >> resulting offset plates/actual ink used for C,M,Y,K to be a subset > >> of the more general cases where individual ink control is desired > >> (spot-colors (including metallic, glossy and other overprints) as > >> well as duo tone and more). > > I also have high hopes for GEGL, but I'd rather have it use some > > more abstract color model for that. I know it's not so simpleâmaybe > > even undoableâthat way, but I do like the idea of color model that > > has complete coverage of visible spectrum. > > Using a color model with full coverage of the visual spectrum would be > an extension along the lines of RGB and the responses of the human > visual system/physics, entirely additive. Not entirely along the lines I'm afraid. First of all it strongly depends which RGB we're talking about. Even if we take scRGB into account there's still some considerable parts of visible spectrum that can not be described by scRGB's triad. I know scRGB is tempting for it's quite broad and seems easy to implement in RGB dominated world, but I've got a premonition that using device agnostic color space would pay off more. But againâI don't know that :). > Spectral processing is not > similar to subtractive models like CMYK I can't agree more. > models needed for simulating > print, mixing aspects, subsurface scattering, ink interactions and > more (some of which are better indirectly modeled by ICC transforms > backed by actual test-runs). Some effects can be modelled that way (maybe even all). Other thing is if they actually are. Getting specific paper profile is most of the time undoable. Maybe something could be done in that matter? For example instead of painfully standard âcolor settingsâ dialog in preferences and âassign profileâ, âconvert to profileâ options some new layout would work better? Maybe instead of going to a kind of âimage modeâ menu, we should go to âcolor workspaceâ menu with all available profiles listed there? The truth is that whenever we use color model that is unable to describe whole visible spectrum we are using some cutout of this spectrum, a working space. Giving an option to just convert image to âgrayscaleâ or âCMYKâ seems to blur that truth and IMHO tries to bury color management concept. > >> with almost enforced > >> strict working spaces for the algorithms to ensure predictability. > >> The ability to do separation to CMYK, spot colors and more with > >> associated processing on such will most easily be done as > >> abstractions implemented using a planar approach where each ink is > >> represented by a graylevel buffer. > > > > True enough, but we mustn't forget about target material > > characteristics when considering print (and soft proofing), paint > > printing order and their attributes (opacity among them too). > > All of these, like the simulation of glossiness or reflectiveness of > metallic inks are things for the final separation/composite/simulation > though - which very well can take into account both substrate and > perhaps even an animated illuminant ;) Temptingâ temptingâ :) > Such soft-proofing would not > be a space that GEGL itself would be doing processing in however, even > though it might have op(s) to take the individual grey level buffers > to create an RGB simulation to be shown on a display,. taking into > account the RGB profile. > > Allowing the user to configure a largeish set of predefinable inks for > separation and simulation/softproofing would possibly allow some very > nice workflows in GIMP and other softwares using GEGL. Yup! That's what I hope for too. > Implementing the capabilities of doing such workflows is something > that only can happen after GIMP itself has more naive initial support > for storing its image data in GeglBuffers of higher bit depths. So if > someone wants to play with, research and make prototypes for such a > thing it would be a nice and welcome addition. I don't think that higher bit depths are more important for transformations than for storing color samples. If image is to be displayed, most of the time it'll end up being crammed into 3 8-bit values :). If it's about to be printed most often it'll be pushed into finite (and not so big) number of possible raster point sizes. I think transformations are really the things that are to benefit most from bigger number of possible sample values. Images of course too, but not everytime. Best regards! thebodzio
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
