El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió: > > But you're not proposing to add a toggle to gradients alone, you're > > proposing to put them*everywhere*. > > Yes.
And your reason is that users have to decide how operations are performed, no matter the result, no matter if it makes any sense or it doesn't. So what about other aspects like alpha association then? Should toggles be added everywhere for that too so the users can decide if alpha will be associated or unassociated? > > I'd like to see this discussion heading towards a real world list of > > examples of real needs for such options that can't be satisfied with > > anything else than these toggles. > > You are presupposing that the devs can foresee every possible use to > which a user might put a given editing operation. No, I'm saying that users like us should describe real world situations where certain options are needed in order to convince developers of the necessity of such options. "Let me do whatever I want" is not a good argument. The need of linear and perceptually uniform gradients is a real need. You can easily document when you need one or the other and create simple examples. Now, give me a good example why scaling should be better done in perceptual gamma (other than preserving legacy appearance, which is the ugly situation that took us here in the first place). You'll find soon that aside from keeping legacy appearance, the situations where you need operations to actually work in perceptual gamma are rare. So in practice, combining linear and perceptual back and forth during your work is not something you need all the time. Tell me for instance why in your UI proposal you merged a layer using the screen blending mode in perceptual gamma. What's the need there, what's the effect achieved? Each case is different and should be designed according the needs. That's what design is about. Addressing needs and crafting solutions. Again: "I want to do whatever I want with the tool" is not a good starting point. You can use your laptop as a hammer if you want, but it's not designed for that use and you can't expect designers to contemplate that use when they plan the thing. > Currently the user does already have linear vs perceptual choices > through the GIMP UI for most editing operations (scaling is always > linear, drawing a gradient is always perceptual). > > Currently the user can use or not use the gamma hack. And the user can > use linear or gamma precision. That's two time two equals four > possibilities for the user to try for each and every editing operation. Again: developers have already said that the gamma hack and even the precision modes are a temporary situation and they are not final. You're exposing your case based on the wrong assumption that those things are going to stay as they are. > Now tell me without taking the time to try all four possibilities: > > How does the user get a linear gradient? (sorry, you can't) That's a reasonable question. It's easy to show why true linear gradients are necessary. > How does the user get linear gamma channel mixer? > How does the user get perceptually uniform Filter/Noise/Add RGB noise? I think you're asking the wrong questions. The real question is: Why and when operations should be performed in perceptual gamma? The answer seems to be (at this point at least) legacy appearance. Most of the times. So, if the goal is to release a GEGLized GIMP that provides the same results as 2.8.x, tools have to work like that. I don't like it and I'd prefer that a true linear workflow is implemented where nothing has to be flipped to perceptual unless there's a good reason. And I bet that those good reasons would be rare, real exceptions that could be treated as such. Why don't we use the energy and time we're using for these discussions for documenting an artist workflow based on linear RGBA (as most of the modern digital compositing packages use)? _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list