From kde-kimageshop Thu Sep 24 22:46:30 2009 From: Moritz Moeller Date: Thu, 24 Sep 2009 22:46:30 +0000 To: kde-kimageshop Subject: Re: Whither Krita? Message-Id: <4ABBF6C6.4010606 () virtualritz ! com> X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=125383243429641 On 09/25/2009 07:00 AM, Sven Langkamp wrote: > I think the "from scratch" was targeted at you reyes proposal. REYES rendering can be used to render procedural brushes. This would be part of the brush engine. From scratch? Depends on you definition of that term. There are 4 OSS REYES implementations I'm aware of. Lots of code to look at and steal from. Plus, since it is only 2D what one needs, lots of simplifications to the aforementioned code. :) > It's always the question how much you want expose the node system to the > user. Some users might be overwhelmed by it. Totally. But you can easily have a Beginner Mode with a layer stack that works like Photoshop or the like. This is essentially just a single chain of nodes w/o branches. If you allow layer groups, you get nesting. AfterEffects allows netsted compositions. You can even view them as a node graph (at least you could, in the past). But you can't edit them. Adobe had an internal version that allowed editing the node tree a few years back, essentially making AfterEffects a full-blown node-based editor. However, product managament was too scared this would alienante the current user base and there were othe reasosn too, why it ultimately never shipped (performance certainly one of them, AfterEffects is dead slow compared to something like Nuke). What I'm getting at is: in Beginner Mode you have a layer stack. At any time, you can view this as a node tree to better undertand how the wto relate to each other. This node view is read only, in Beginner Mode. In Normal Mode, the node tree becomes editable. Once edited, the edits, if they can't be reflected in the stack metaphor, require Normal Mode to be tweaked. All parts of the node tree that were created in Beginner Mode and not affected by the edits are still shown in the Layer palette. This is btw more or less straight from the white paper I wrote for Eclipse 4.0 (the image editing app, not the IDE), in 1998. There are many ways to hide complexity from a user w/o sacrifcing power > Editing draw strokes might be nice if you do it like MyPaint only for > the last stroke. It gets more complicated to use if you want to modify > single path points, just try to modify a calligraphy stroke in Karbon. I'm not sure what complication you talk about? The brush editing I propose has got nothig to do with the lame (sorry) way Karbon or any other vector app I ver used (Corel, Illustrator, Inkscape) handle these strokes, after initial creation. The Eclipse 4 whitepaper contained a wole bunch of ideas on editing natural media strokes that were far beyon point edting. In fact, while a needed feature, point edting is probably the one method artists using natural media would want to use least. And that is probably what you were getting at. If you have stroke whose thickness you are happy with, you can redraw just a part of it. Drag-Select the part of the stroke you want to edit (along the length), put down your stylus, redraw. There are bunch of options how this can be mapped back to the stroke. One way would be to just connect the stroke drawn with the bits that weren't selected. Another way is to have a guide marker run along the stroke at a constant pace and the user just provides feedback for the paramter they want to edit, on the tablet (e.g. position, pressure, angle, tilt, etc.) Yet another way would be to map the length of the edited bit to the distance the stylus moved on the tablet by a factor. If the stylus is not at the same position at the end, the part of the original stroke that comes after just gets moved to fit. Yet another way would be to just warp the stroke into the selected bit (the unselcted bits of the stroke stay absolutely put). This is admittedly hard to provide visual feedback for, while drawing. There were 4 or 5 other methods. What they all had in common was that the artist used the stylus continuously to do the editing and by that I mean he did not use the stylus to select and move individual points of the spline definiting the pricinpal direction. One thing to keep in mind is that positoon, width and angle are just the very basic parameters of a stroke. But a procedural brush possibly has dozens of others. Allowing these to be edited, in a natural way, using the stlyus continuiosuly, is a core interface metahphor a good procedural brush system has to employ, imho. But this is talking about the UI already, I was, so far just talking about implementation. :) > Saving the path would get a possible maintainance problem as future > paintops have to work in the same way to keep the image looking the > same. If you send someone a picture he needs all the paintops you used > to create your image, so you would have to included the whole image as > fallback. That problem exists with text layers too. You need the fonts to render them correctly. That is why Text layers are saved as bitmaps too, in PSD files. And such dependencies and version mismatches for file format features are the reasons why a PSD file always contains a flattened image of the whole composition. Essentially, anything that depends on a plug-in componnent which can not be assumed available on a system opening the image must be stored in a flattened way. As with text, I'd actually store the outlines of the letters used, or even the whole font, if the font allowed embedding (this is alegal problem, not a technical one). Similarly, for procedural brushes, one could store as much parametrically, as possible to re-create the brush at the intended rendering res for the image (say, 300ppi) if the paintop wasn't available. And certainly, this should be an option, so one can save files of much smaller size if all dependecies can be assumed to be present, when opening the image again. .mm _______________________________________________ kimageshop mailing list kimageshop@kde.org https://mail.kde.org/mailman/listinfo/kimageshop