sandm...@cs.au.dk (Søren Sandmann) kirjoitti 29.7.2012 kello 18.03:
> Antti Lankila writes:
>
>> Okay. I'll start splitting the work into pieces. I'll submit each as a
>> separate mail/patch as I get the changes done. Here's the first,
>> probably the least controversial change:
>
> Pushed, th
Antti Lankila writes:
> Okay. I'll start splitting the work into pieces. I'll submit each as a
> separate mail/patch as I get the changes done. Here's the first,
> probably the least controversial change:
Pushed, thanks.
Soren
___
Pixman mailing list
Søren Sandmann kirjoitti 14.7.2012 kello 12.02:
> Antti Lankila writes:
>
>> From 693af3995b46d531342d68ac83b794113d0a7a90 Mon Sep 17 00:00:00 2001
>> From: "Antti S. Lankila"
>> Date: Sun, 10 Jun 2012 22:31:38 +0300
>> Subject: [PATCH] Add support for sRGB surfaces
>
> This mostly looks goo
Antti Lankila writes:
> From 693af3995b46d531342d68ac83b794113d0a7a90 Mon Sep 17 00:00:00 2001
> From: "Antti S. Lankila"
> Date: Sun, 10 Jun 2012 22:31:38 +0300
> Subject: [PATCH] Add support for sRGB surfaces
This mostly looks good to me. The main highlevel comment I have is that
I'd like the
Søren Sandmann kirjoitti 25.6.2012 kello 20.47:
> Bill Spitzak writes:
>
>> A problem is the pseudo-random starting point. This is necessary so
>> that you do not get vertical stripes when the rows have the same
>> data. But if you want your composites to not change, it has to be
>> determinist
Bill Spitzak writes:
> A problem is the pseudo-random starting point. This is necessary so
> that you do not get vertical stripes when the rows have the same
> data. But if you want your composites to not change, it has to be
> deterministic. I'm not sure but perhaps a hash of the y coordinate of
Søren Sandmann wrote:
For the 8 bpc fetcher converting from 8 bit srgb to 8 bit linear loses a
lott of information, which is why the format is considered wide. But if
it somehow ends up being used with the 8 bit pipe (and currently it
will, because at the moment everything with a transformation
Søren Sandmann kirjoitti 20.6.2012 kello 23.48:
> "Antti S. Lankila" writes:
>
>> Can do. However, there will be a few places then which need to be
>> taught about the new ARGB_SRGB pixel type, unless we also modify the
>> PIXMAN_FORMAT_TYPE to filter out the color space bits. I did this to
>> k
"Antti S. Lankila" writes:
> Can do. However, there will be a few places then which need to be
> taught about the new ARGB_SRGB pixel type, unless we also modify the
> PIXMAN_FORMAT_TYPE to filter out the color space bits. I did this to
> keep changes minimal. I added the PIXMAN_FORMAT_SPACE macr
On 15.06.2012 22:40, Søren Sandmann wrote:
Comments on the patch:
- I think the code that generated the tables should be included, and the
tables generated as part of the build process.
Agree. I have reworked the build to do this.
- We can't break source level compatibility. Instead of ad
"Antti S. Lankila" writes:
> On 09.06.2012 14:16, Antti S. Lankila wrote:
>
>> Currently the color space processing is just a cheap integer hack
>> with gamma 2.0. It is sufficient for testing purposes, but not
>> production quality. I'm leaning towards tabularizing the official
>> sRGB-to-linear
Antti S. Lankila wrote:
I do want to point out one advantage of using, say gamma=2.2 in lieu of
the actual sRGB formulas in some situations: exponentiation permits
separate treatment of alpha and color components. For instance
(component * alpha)^2.2
is just
component^2.2 * alpha^2.2
and t
Søren Sandmann wrote:
OpenGL has two extensions that deal with sRGB [1, 2]. One adds a new
texture format, which has 8 bits per component and where the texture
sampler is supposed to raise the R, G, and B (but not A) components to
2.2 before filtering. The other allows framebuffers to marked a
Bill Spitzak writes:
> A problem with sRGB for line art is that drawing an inverted drawing
> will not look correct to users. White lines and text will look much
> too thin, while black lines and text look thicker. This appears to be
> because humans invert images in perceptual space. It is possi
On 10.06.2012 12:51, Antti S. Lankila wrote:
(component * alpha)^2.2
On re-reading: *sigh* swap 2.2 with 1/2.2 over the rest of the email.
--
Antti
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pix
On 10.06.2012 06:46, Bill Spitzak wrote:
A problem with sRGB for line art is that drawing an inverted drawing
will not look correct to users. White lines and text will look much
too thin, while black lines and text look thicker. This appears to be
because humans invert images in perceptual spac
A problem with sRGB for line art is that drawing an inverted drawing
will not look correct to users. White lines and text will look much too
thin, while black lines and text look thicker. This appears to be
because humans invert images in perceptual space. It is possible this
could be compensat
On 09.06.2012 14:16, Antti S. Lankila wrote:
Currently the color space processing is just a cheap integer hack with
gamma 2.0. It is sufficient for testing purposes, but not production
quality. I'm leaning towards tabularizing the official sRGB-to-linear
function and its inverse in a future pa
Hello everyone,
I have worked out a tentative patch to pixman which adds capability for
processing images in sRGB color space. This is still somewhat a
work-in-progress, but the basic functionality should be there.
Here's a quick overview of the content of the patch:
- PIXMAN_FORMAT tag is e
19 matches
Mail list logo
