[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: New idea about Grayscale Selections problem
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2013-02-10 7:30:11
Message-ID: CAEkBSfW6_V2CygMqzbymNyLnxM00GstsPUBMndmkt_PQnN6diA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> This doesn't fix the problem as it's not a problem at dab level. Dab
> always need a alpha channel, otherwise you just get square blobs.
>
Heh, it seems like I forgot to tell the main idea, the dabs created with
the methods would have a different colorspace (grey + alpha), which would
be composed by multicolorspace composite ops.
> There is also Indirect painting which wouldn't be covered by that.
>
Yes, Indirect painting is still the problem.
> Other tools would still have the problem like the fill and gradient
> tool.
>
Actually, Fill and Gradient tools create internal "dabs" represented by
usual KisPaintDevice object. So it should work for them.
> I think the only way to solve this is that the tool will get a
> gray+alpha paint device. I more and more favor that we switch the
> pixel selection colospace to that. It's the only way to solve that for
> all tools without messing with composite ops.
>
Well, probably, we could think over the idea of having
KisSelection::paintDevice() again... But we should first consider a few
problems very carefully:
1) On the start of every transaction over KisSelection::paintDevice() the
selection should be flattened to have a paint device only.
2) On the start of every transaction over KisSelection::pixelSelection()
the selection should be flattened to have a pixel selection only.
3) (What should we do on the creation of a vector selection in a selection
having a pixel selection?)
4) All the flatten events should be undo/redo'able
5) The KisSelection::paintDevice() object should still be in some special
colorspace, that can be composed into alpha() colorspace properly.
Actually, problems 2 and 4 are to be solved anyway, because currently we
have a few bugs due to it.
Problems 1 and 2 should be somehow solved internally inside the
KisSelection, that it we shouldn't ask the user-code to flatten it every
time manually.
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<div class="h5"><br>
</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">This doesn't fix the problem as \
it's not a problem at dab level. Dab<br> always need a alpha channel, otherwise \
you just get square blobs.<br></blockquote><div><br>Heh, it seems like I forgot to \
tell the main idea, the dabs created with the methods would have a different \
colorspace (grey + alpha), which would be composed by multicolorspace composite \
ops.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> There is also Indirect painting \
which wouldn't be covered by that.<br></blockquote><div><br>Yes, Indirect \
painting is still the problem.<br> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Other tools would still have the problem like the fill and gradient<br>
tool.<br></blockquote><div><br>Actually, Fill and Gradient tools create internal \
"dabs" represented by usual KisPaintDevice object. So it should work for \
them.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the only way to solve this is that the tool will get a<br>
gray+alpha paint device. I more and more favor that we switch the<br>
pixel selection colospace to that. It's the only way to solve that for<br>
all tools without messing with composite ops.<br></blockquote><div><br>Well, \
probably, we could think over the idea of having KisSelection::paintDevice() again... \
But we should first consider a few problems very carefully:<br> <br>1) On the start \
of every transaction over KisSelection::paintDevice() the selection should be \
flattened to have a paint device only.<br>2) On the start of every transaction over \
KisSelection::pixelSelection() the selection should be flattened to have a pixel \
selection only.<br> 3) (What should we do on the creation of a vector selection in a \
selection having a pixel selection?)<br>4) All the flatten events should be \
undo/redo'able<br>5) The KisSelection::paintDevice() object should still be in \
some special colorspace, that can be composed into alpha() colorspace properly.<br> \
<br>Actually, problems 2 and 4 are to be solved anyway, because currently we have a \
few bugs due to it.<br>Problems 1 and 2 should be somehow solved internally inside \
the KisSelection, that it we shouldn't ask the user-code to flatten it every time \
manually.<br> <br> </div></div>-- <br>Dmitry Kazakov
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic