Photographic features and other non-paint features)

[Boudewijn Rempt]

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?

> I really hate seeing HDR photo work dropped as a use case, as that is
> what I was most hoping to get out of Krita.

Yes, everyone has things they would hate to see dropped, and everyone has some 
things they would love to go in: but we _need_ to get _focussed_. We cannot be 
all things to all people and do all things equally well. Every feature we have 
already or come up with needs to be checked by the vision, and that is a 
change in culture, but we need that. Or else Krita will still be a jack of all 
trades but a master of none when the project turns twenty.

So, arguments along the lines of "I would hate X to be dropped" or "I would 
love to have Y" are not something we should take into consideration.

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

> Right now nothing else comes
> close. GIMP doesn't support HDR (not last I looked anyway), Cinepaint is
> old and buggy, and digikam is destructive (and trying to shoehorn in
> what you need for a full-featured HDR workflow would make it something
> besides a photo manager). 

We do not have to fill in every niche that's left open by the existing set of 
other applications. We have to create an application that executes on the 
vision.

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.

> For that matter, GIMP is also destructive;
> Krita is the only paint app I know of that isn't. (Rawstudio is
> non-destructive though with limited flexibility, but has no paint
> abilities or layers which makes it useless for multi-exposure HDR.)
> 
> > And the list of filters that I don't think are so useful for our vision:
> > * cubism
> > * pixelize
> > * raindrop
> > * oilpaint
> > * emboss ?
> > * small tiles
> > * round corner
> 
> I think pixelize should stay; I think it has legitimate artistic uses.
> Do we really want Krita to be *only* natural media to the exclusion of
> more 'traditional' digital work (i.e. abandon being able to use Krita to
> the exclusion of GIMP)?

We want Krita to be:

"Krita is a KDE program for sketching and painting, offering an end–to–end 
solution for creating digital painting files from scratch by masters."

"Fields of painting that Krita explicitly supports are concept art, creation 
of comics and textures for rendering."

"Modelled on existing real-world painting materials and workflows, Krita 
supports creative working by getting out of the way and with snappy response."

That is what we want Krita to really be. 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. Do we want to spend time on fixing up the progress reporting, 
serialization/deserialization and performance of filters that are a port of 
something first implemented in a thesis in the early nineties and that is 
available everywhere (down to the Hyves Photo Uploader :-)? 

I think we should spend our time solving the real problems that Krita has 
before it can become an application that fulfills the vision first, in other 
words, focus on important things.

> That said, if it is just a question of filters that ship "built in"
> versus ones you get with GHNS, well then that's not so much an issue :-).

I guess these filters will be really easy to reimplement using openshiva, they 
are very simple, so GHNS is an option, and there is always the plan to create 
extensions.krita.org where the C++ plugins can be kept alive and compilable. 

In the mean time, we need to focus on delivering Krita 2.3 -- the first 
version of Krita we no longer have to apologize for "Have you tried Krita? 
It's quite slow and unstable, but it might just do what you need..." -- that's 
something I don't want to have to say anymore after 2.3.

> enki wrote:
> > A good artist thinks outside the box, he may want to use pixelize with
> > squares of 200 pixels.
> 
> A good artist may want 1/3-inch "pixels" and be working at 600 dpi :-).
> +1 here, IMO 200 px really isn't that unreasonable.

We need to focus. Really we need. We should not try to legalistically find 
loopholes in the vision statement to add this and that: that will not result 
in a good and focussed application in six months. When we do our core stuff 
really well, we might talk about re-integrating fringe stuff.

-- 
Boudewijn Rempt | http://www.valdyas.org