Photographic features and other non-paint features)

[Sven Langkamp]

On Tue, Mar 9, 2010 at 10:49 PM, Matthew Woehlke wrote:

> 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.)
>

They are not "impossible" as you can still install the plugins. There will
always be a usecase for which an application can't be used.
Sure there is a big overlap in what this kind of graphics appliction can do,
but at some point you have to make a cut and say that another application is
better at the job.

If we keep everything that Krita can do in some way now it would also be a
spreadsheet and chart editor (not broken, but not very usefulness either).


> > 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.)


I think for your usecase Gimp at least with gegl integration probably will
be closer to what you need than Krita.


>  > 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.
>

Currently only Photoshop comes close to being an integrated solution and
even Adobe cuts it into pieces e.g camera raw plugin, Lightroom, ImageReady
etc.
At the sprint it was pointed out that Painter is much more efficient than
Photoshop for painting.

Having different applications doesn't mean that the are disconnected. In big
move studios there is usually a production pipeline with many different
applications e.g there are different apps for modeling, compositing and
cutting the movie. They are used by different people and are optimized for
their tasks. On the other hand Blender does all these things in the same
application.
Both ways can work depending on your workflow.

I don't think that we should go the way to build a very broad application
that covers a bit of everything but does nothing right. What's most
important for Krita right now is too become really stable and fast, so the
narrower the focus the better. Once that is done there will be more people
creating plugins and at some point there might be a another application that
is either a seperate application or just a Krita with addtional photo
plugins, but we are not there yet.


> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100310/e868a6fe/attachment-0001.htm