On 10/05/2010 01:20 AM, David Gowers (kampu) wrote:
> In that case it really is a bug. Neither the input colors or output
> colors contain 255.
>
> The output color series is:
> 008700 008d00 009300 009800 009d00 00a200 00a700 00ab00 00af00 00b300 00b600
> ...
>
But the outputs contain 0's. And
On Tue, Oct 5, 2010 at 4:37 AM, Rupert Weber wrote:
> On 10/04/2010 04:17 AM, David Gowers (kampu) wrote:
>
>> Try making a flat region of color #2a7e23, selecting Pencil tool,
>> choosing Color mode and a large brush, and painting #11e500 repeatedly
>> over the same area.
>> [...]
>> In general,
On 10/04/2010 04:17 AM, David Gowers (kampu) wrote:
> Try making a flat region of color #2a7e23, selecting Pencil tool,
> choosing Color mode and a large brush, and painting #11e500 repeatedly
> over the same area.
> [...]
> In general, you can manifest this bug by picking a dark color,
> making a
On Thu, Sep 16, 2010 at 2:15 AM, Rupert Weber wrote:
> On 09/14/2010 09:23 PM, yahvuu wrote:
>> yep, that yields the desired RGB triple 255, 179, 128 for the example under
>> discussion (i.e. blending red over white using 'color mode').
>>
>> However, after reading some more code, i'm less than sh
On 09/14/2010 09:23 PM, yahvuu wrote:
> yep, that yields the desired RGB triple 255, 179, 128 for the example under
> discussion (i.e. blending red over white using 'color mode').
>
> However, after reading some more code, i'm less than shure it does so for
> the right reasons. Same goes with my pr
On 13.09.2010 15:28, Rupert Weber wrote:
> On 09/13/2010 01:05 PM, yahvuu wrote:
>> btw, the red returned from the current GEGL implementation is too dark:
[..]
> I am proposing the attached tiny patch to correct that
yep, that yields the desired RGB triple 255, 179, 128 for the example under
di
On 09/13/2010 01:05 PM, yahvuu wrote:
btw, the red returned from the current GEGL implementation is too dark:
the projection eventually converts to linear light "RGB u8" [1] and
these values get fed directly to the screen, which in contrast expects
gamma-corrected values -- that is, at least whe
On 12.09.2010 11:37, Rupert Weber wrote:
> Just discovered that the clipping in the new layer modes needs more work.
>
> It's not a problem with colors that originated in sRGB, but the layer
> modes can easily construct colors outside sRGB, or even
> invisible/virtual colors.
> The current behavior
On 09/12/2010 11:37 AM, Rupert Weber wrote:
> Just discovered that the clipping in the new layer modes needs more work.
Problem solved.
Not reposting the patch for now to keep the noise down, as I'm sure
there will be other small issues.
Rupert
___
Gim
Just discovered that the clipping in the new layer modes needs more work.
It's not a problem with colors that originated in sRGB, but the layer
modes can easily construct colors outside sRGB, or even
invisible/virtual colors.
The current behavior is different from floating point/GEGL implementat
About bablizing the layer modes: I spent a little time with babl and all
I can say right now is that it will definitely take a while to get that
done.
So far it's been like a set of Russian puppets, and I don't think I've
even reached the innermost yet.
I wouldn't dare to give an estimate, but g
On 09/06/2010 09:17 PM, Sven Neumann wrote:
> I am not so happy about the choice of the term "obsolete". The old layer
> modes are not obsolete. I'd suggest to use the term "legacy" instead.
I'm ok with either.
The obsoleteness is what I tried to find out earlier. Right now GEGL
doesn't support
Hi,
On Mon, 2010-09-06 at 17:42 +0200, Rupert Weber wrote:
> just wanted to get this out before another week passes, as I probably
> won't be getting to it before next weekend (or maybe the odd sleepless
> night).
>
> I posted an update to the patch to
> https://bugzilla.gnome.org/show_b
13 matches
Mail list logo
