Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

El vie, 01-05-2015 a las 05:40 -0400, Elle Stone escribió:

This is a color managment issue. It's fundamentally important. GIMP 
shouldn't make decisions like "use linear here and perceptual there", 
other than to offer the user good defaults.

A color management issue? You're proposing to let users do whatever they
want with the trc, no matter if it's right or wrong. That's a color
management issue! How do you ensure correct results when the user can
change that at will on every single operation performed?
And how do you plan to let users keep track of the flips they
intentionally added with a UI that is sequential and doesn't expose the
pixel format resulting from each operation?

I mean, instead of putting toggles on EVERYTHING, why not adding a tool
that says "from this point, the following operation/s will be performed
in linear/perceptual gamma"?

Because there is no "from this point" in RGB image editing. It is not 
the case that "until point X use linear RGB" and "after point Y use 
perceptual RGB" makes any sense.

Yes there is.
Most of the tasks performed by a user on an image are sequential,
specially with a UI like GIMP's.
Back when Peter Sikking was involved in GIMP UI, he proposed to
implement non-destructive editing as a stack of operations.
With a UI like that it would be really easy to visualize the gamma
toggles I mention.
They would be extra operations overriding the pixel format requested by
each operation, they would be optional and added on demand by users.

In a sense it's exactly the same you're asking, but implemented at a
workflow level rather than plaging the UI with toogles for everything.
It would be easier to visualize and follow too.

operation by operation decision. The user has a right and the *need* to 
know and be able to control what's being done with the user's own RGB data.

GIMP should NOT make such decisions behind the user's back, forcing the 
user to use linear RGB in one place and perceptually uniform RGB in 
another place without so much as a by your leave. GIMP can't know the 
user's technical purposes. GIMP can't know the user's artistic 
intentions. Right now the babl flips are a hobble, not a help.

"EVERYTHING NEEDS A TOGGLE" is an all-caps overstatement. What's next?
Toggles for associated or unassociated alpha on every single operation?
And let's go further: If the artist wants to do something in a different
color model "just because" the UI of *each tool* should reflect every
possible caprice?
A program should provide correct results and provide tools for some
creative deviations. That's not the same than saying that the program
should provide whatever results any user wants regardless if they are
technically correct or not.

You are proposing to add options to make operations deliberately give
wrong results just because the user wants it. You want to completely
take the decision of what's technically correct away from developers.
If I remember correctly you criticized pippin because he wanted to do
the same in the opposite end (make the program make all the decisions
and assumptions, deny the users the freedom to choose).

As a user, I would like to see a program that makes both the right
technical choices AND allows me some flexibility.
That's usually a job for a good UI, and that's why it's critical that
functions are designed with both techical correctness and user
interaction in mind, from day 1.
Nodal interfaces allow a great degree of flexibility by keeping
operations as single units that can be connected in different ways.
Current GIMP's UI is sequential. One thing comes after another.
Each operation (except layer blending) is sort of "modal". You do one
thing at a time, and you can't go back in time without undoing what
you've already done.
This means that any time you run an operation on pixels you'll get a
dialog with the possibilities of that tool.
The more possibilities the tool has, the more controls and more
cluttered interface.
That's what I'm against. No sane and fast workflow can result from
dialogs plagued by dozens of options. It's a problem that has to be
dealt in a different way.

We don't need tools that allow every different possibility. We need
different tools for every possibility.
The tools should remain simple and correct, and if you need to do
something crazy, there should be a tool to "bend" how things work.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]