Status Update for 2.0 and 1.6

[Boudewijn Rempt]

On Saturday 30 December 2006 11:45, Cyrille Berger wrote:

> Well tonemapping has allways been considered on my todo for 2.1... For
> 2.0 it's ldr2hdr, on the other hand, bala on irc (who also wrote a
> filter which will soon be imported in svn, in krita-plugins for
> starting) is willing to give a try to tonemapping.

Nice! Yay for bala :-)

> > State of trunk:
> >
> > * Pigment is coming along nicely -- even though the hdr colorspaces don't
> > compile for me
>
> We need to find the solution to that one, has for me the two floats
> colorspaces are completed and fully functionnal (except for the profile
> part for display convertion).

Yes -- I'm baffled by this. Even a completely clean checkout & a completely 
new build dir give this error. My gcc version is 4.1.2, btw.
>
> > * Not everything changed and fixed in 1.6 has been ported yet to trunk
>
> We need to put together the list of those things:
>  - three filters : levels, halftoning and colorify
>  - smudge
>
> As for bug fixes, I forward port them straight away to avoid forgetting
> them.

I've got a couple of bug fixes on my list that I haven't ported yet.

> > * I've decided to make KisPaintDevice a true QPaintDevice. We need to add
> > resolution to KisPaintDevice to make that truly work: for now a
> > KisPaintDevice is 72 dots to the inch.
>
> Any reason behind that ? (out of curiosity)

The main reason is that it makes integration with flake a lot easier -- as 
well as with other Qt tools. I'm also hoping it'll make it easier to do some 
paintops I'm thinking about.

>
> > * Still to implement compression in the tile backend; also we need to
> > figure out how to place stuff from the tiles in the graphics card memory
> > for shaders to work on. (Have a hierarchy of texture - memory -
> > compressed memory - swap for tiles).
>
> and we might want to use _mm_malloc (from mm_malloc.h) to get alligned
> data for sse instructions

Good point. Bart -- are you listening? :-)

> > * Convolution will suck until we can lock a certain area of memory or do
> > convolution in the graphics card.
>
> and until we do the convolution in two passes, vertical and horizontal,
> but that's on my todo for a much later date.

But we ill still need some refactoring to make the locking possible?

> > * adjustment layers somehow got fragile, probably related to selection
> > stuff. Besides, it's silly that we paint with gray levels on masks, but
> > with opacity on adj. layers. We need to make that the same
>
> Well we have more or less decided to use mask for adjustement layer in
> 2.0 instead of drawing on them, haven't we ?

We have -- but this is a point for 1.6...

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20061230/b5569000/attachment.pgp