h a l f b a k e r yWe are investigating the problem and will update you shortly.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Relayering
revise operations to apply to the desired layer | |
Bitmap graphics drawing packages very often use the concept of
layers, which are conceptually
stacked to form the final image.
Basically, you can draw different components of an image on
different layers, which can
be independently edited without interfering with the others.
This is all
well and good, but I find it's not unusual that I've
drawn something on the wrong
layer - and often this has messed up what was meant to be
there, so it can't just be cut
and pasted to the intended layer. Apparently this isn't just me
- this happens to good
artists too.
Most graphics packages already have an undo history, and
redo of 'undone' events. What I
propose is a feature where you could review individual
elements in the history, and
change which layer they were applied to.
I think in most reasonable architectures this would actually be
a relatively straightforward
feature to add.
[link]
|
| |
Yes, this sounds feasible. [+] |
|
| |
Everything I know about what you are suggesting I just learned form this post and I have a hard time wrapping my head around the fact that it's not already a thing. If you are the first person to propose this, then... |
|
| |
In what way is this halfbaked? |
|
| |
If every action generated its own separate layer, and if the layers could be "grouped" together, then a single layer could be shifted from its group to another group. |
|
| |
A brilliant idea. I'm no graphical artist but I hope it gets baked. |
|
| |
//In what way is this halfbaked?// |
|
| |
Does photoshop -or some other very expensive program I
haven't used- do this already?
Because I haven't seen it, and I was motivated to post by
seeing a forum thread with some very impressive graphical
artists talking about problems they have, and drawing on the
wrong layer was the most widely mentioned digital issue. |
|
| |
// In what way is this halfbaked? // |
|
| |
Well, there is of course a trivial doing it part. It might be possible to fix it in Gimp, if [Loris] still has his Gimp mask. |
|
| |
By the by, I think I saw a headline that Photoshop will be absolutely free soon. |
|
| |
I think I saw a headline that I wouldn't *believe* this one
weird trick. I didn't. |
|
| |
Glad I'm a CAD monkey & not a different sort of digital artist, then...
I can just select an element & change it's layer. Any time. Although, as I've discovered & not liked, I can't change the display "ordering" of layers in SolidWorks; so layers are more useful for "on or off" (& colours, line settings etc) than the more powerful "this layer on top of that layer". |
|
| |
This isn't about changing the order of layers.
I see that I should have made clear that this idea is primarily for bitmap graphics. The issue there is that operations are often complex, and commingle with the selected layer's prior contents. It doesn't seem to be uncommon to e.g. set up a draft layer with a rough sketch, add an 'inking' layer for careful outlining - then later discover that you've drawn almost everything to the draft layer anyway, and you've got no easy way of separating them.
So it just seems like it would be nice to be able to go back through the undo history, tell it ..."/here/, switch to the inking layer", and *poof* it's resolved. |
|
| |
a1, I think Concepts is a vector drawing package. That's not bad - I love vector graphics and for many purposes prefer them.
Yes, vector graphics don't have much of an issue with "destructively drawing on the wrong layer". Basically because each component of the image is its own layer, so you can more easily rearrange them later. Vector images also have many other advantages. |
|
| |
However, bitmap images have their advantages too, and you'll often have to work from a bitmap as a starting point. If you've got an image extracted from the real world (i.e. a photo), it'll be a bitmap.
At least in terms of internal representation, bitmaps are defined in size in a way which vectors are not - a vector image can be arbitrarily big. Another way of thinking of this is that some drawing operations are just more easily represented with a bitmap.
And many artists are just more comfortable with the bitmap process. It's important to cater to how users actually want to work. |
|
| |