On Sunday 10 December 2006 15:00, you wrote:
> As you might have guessed, I haven't read any
documentation about krita
> before starting..
Well, that _should_ work. Not that the documentation isn't
quite good,
especially for an open source project, with lots of
informative little
tutorials and tips
> I'm not familar with internals of krita, so I don't
know how merging of
> different layers is handled. My first guess from your
explanations is that
> upon rendering (and saving to non native formats) the
pixels are converted
> into the "projection color space" and the
merging takes place in that
> colorspace?
Yes, that's right.
> Another possibility would be that composition is done
in a colorspace that
> is a superset of all layer colorspaces, and converted
down to the image
> colorspace afterwards.
We've thought about that, too, but there are problems with
that approach,
especially since a colorspace that's a superset of all
colorspaces in Krita
would be something like 32-bit XYZ or L*a*b -- and that
would make krita eat
a lot more memory than it does now. And if it's to be a
superset of the
colorspaces currently in the image, then we need to have a
kind of sliding
scale of capabilities.
> Well, logically this feature belongs into the image
dialog, however it
> needs some more thinking since many users will probably
don't know/have
> forgotten that krita supports layers with different
types.
Exaclty. It's not a common feature
> > The options are:
> >
> > * Keep it this way, adding a little bit to the
learning curve.
>
> Maybe with some additional description like "final
colorspace" or
> "projection colorspace", or something along
these lines might make this a
> bit more clear to users that forget about the layer
issues etc.
>
> I was only editing a single layer, in that case the
projection colorspace
> could be fixed to the layer colorspace.
>
> > * Remove the option to set the colorspace from the
image properties
> > dialog and always use the colorspace of the
background or bottom-most
> > layer. Make the the colorspace of hte image a
read-only label in the
> > image properties dialog. This removes a bit of
flexibility, but is easier
> > to grasp.
> >
> > * Move the option to set the image's native
colorspace to the color
> > conversion dialog. Make the the colorspace of hte
image a read-only label
> > in the image properties dialog
>
> Hmm, might be a better solution, since then the user
has to choose which
> colorspace he wants to change. Maybe a radio button to
select between
> "convert all layers" and "final image
colorspace" would be enough?
>
> Btw. which rendering intents are used for the
conversion into the image
> color space?
Good question. I'd need to check the source.
--
Boudewijn Rempt
http://www.va
ldyas.org/fading/index.cgi
_______________________________________________
kimageshop mailing list
kimageshop kde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop
|