sponsored work for Dmitry

Boudewijn Rempt boud at valdyas.org
Fri Sep 21 08:19:49 UTC 2012


On Friday 21 September 2012 Sep, Sven Langkamp wrote:
> On Thu, Sep 20, 2012 at 7:36 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
> 
> > The simple approach is the one I tried to implement: make selections have
> > a grayscale + alpha channel and use the combined value as the selection
> > value. This works with the current paint system because the current paint
> > system cannot handle precomputed alpha. Disadvantages: twice the memory
> > usage for selections, plus the calculation needed when determining the
> > selection value. But because it works within the way krita was designed to
> > work, it's not hacky, imo.
> >
> 
> It somewhat problematic as most of the code in Krita assumes that the
> selection/mask is just one channel.

Yeah -- that's where the separate step to combine gray + alpha come in. That would be the selection projection which would still be alpha-only. 

> That is an issue I ran into. The interleaved storage is a problem for
> vectorization were I'm not sure what's the best way to solve that. For
> example the alpha channel is computed completely seperate most of the time,
> also the SIMD registers might be a lot bigger than what we can use when we
> only load one pixel at once. I wonder if it might be better to use a planar
> storage for pixels.

Separating all channels into planes would be quite costly, I think -- we would need have a separate pointer per channel, and increment those pointers. We tried that with the painterly colorspaces and it was quite wasteful. That's why I was kind of thinking of a mixed mode: have the color channels interleaved and the alpha channel separately.


> > > 6) Memory footprint problem
> > >
> > > Well, speaking truly, I have seen only few memory problems in
> > > Krita.
> >
> > The really core issue here is that we take more memory to store pixels
> > than Gimp or Photoshop. I don't know how they do this -- I just know that
> > comparing the memory footprint after loading another image shows a big
> > difference. All the other things, undo history, brushes, canvas projection
> > caches aren't the issue for me.
> 
> 
> Might be that they compress tiles in memory or just work on a smaller image
> and do the work in the background. RLE could be used to compress in memory,
> but that requires planar data as the experiments with file saving have
> shown (shuffleing was slow).

I'm beginning to suspect planar + rle is used internally in photoshop..

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


More information about the kimageshop mailing list