Photographic features and other non-paint features)

[Matthew Woehlke]

Boudewijn Rempt wrote:
> On Tuesday 09 March 2010, Matthew Woehlke wrote:
>> Cyrille Berger wrote:
>>> Lets start the list of (purely) photographic related features:
>>> * lens correction
>>> * tone mapping
>>> * bracketing to HDR layer
>>> * Gaussian / Wavelet noise reduction
>>
>> I'm not sure I understand, do you mean these will be kept? At least tone
>> mapping I hope will stay! (That has implications for any HDR color
>> spaces, even things that don't originate as photos. Why shouldn't I be
>> able to paint in HDR? Also... Adam made the note about textures; if
>> texture drawing is supposed to be a first class citizen, then I think we
>> need to assume that people will be wanting to draw HDR textures in the
>> not so distant future, if they don't already.)
>
> I am not sure where tonemapping fits in. But even if it is tangentially
> important: how important it is to focus on right now? Is it comparable to the
> best tonemapping support there is? Are we good enough at our core business, so
> do we have spare time left for things that aren't directly implied by our
> vision statement?

To be clear: I'm not suggesting you change priorities, just don't drop 
useful things because they don't fit with the current priorities.

(I'm not talking about things that are broken. Cleaning up stuff that is 
actively *bad*, or for example preventing an important refactor, is one 
thing. Making it /impossible/ to use Krita for a use case because it 
isn't currently /ideal/ for that use case, just for the sake of "a more 
streamlined experience", is another.)

> And Krita is not for photo work. Sorry -- use pfsgui for HDR photo work with
> tonemapping.

Um... seriously? I can't say I've ever gotten decent results out of it.

What I need 
(http://wiki.koffice.org/index.php?title=Krita/High_dynamic_range#Manual_Process) 
is rawstudio with an HDR-space-capable (or better-than-rgb8, at least) 
paint program underneath so I can work with alpha mask layers... both 
generating them from other information (e.g. luma -> alpha) and, as 
needed, painting directly on them. Cinepaint *almost* provides this, 
except that it is destructive (have to do tone mapping in rawstudio, 
export, and blend in cinepaint), but worse it is buggy and unusable as a 
result.

For a while, Krita seemed to have promise that it would be able to fill 
my needs. In fact, sans bugs, slowness, etc., the only missing elements are:
- Dynamic layer clones (i.e. layer node that is a dynamic copy of 
another point in the layer pipeline; something that I think would be 
useful for painting as well).
- Copy arbitrary channel to arbitrary other channel (or mask).
- Apply filters to individual channels.

Am I now going to be SOL? Because no other program I know of comes 
anywhere near as close as Krita to providing what I need.

Sigh.

(White Balance might be missing, but that is *definitely* useful for all 
types of art, and shouldn't be hard to implement.)

> We don't care if people have to use Gimp or Mypaint or Ramen or
> Hugin or Psfgui or Digikam in addition to Krita, especially not if
> they do things well we have only a half-baked implementation of.

In the short term that's understandable. In the long term, having to use 
multiple applications in a workflow is usually a pain. I don't think 
it's unusual for a half-baked but integrated solution to outperform 
superior but disconnected solutions, if only in the efficiency gains of 
not having to switch between workflows constantly.

> In other words, "Krita can almost do Z a little, while no other app can do it
> at all" is not an argument for retaining Z, if Z does not fit the vision we
> have for the application.

I hope you can see how disappointing that is from my perspective.

Again. Worry about your priorities one at a time and cut what actively 
gets in the way of that, but please, don't cut for the sake of cutting, 
and don't forget the big picture.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Sorry, fresh out of .sigs. Maybe tomorrow.
(paraphrased German saying)