On 03/06/2013 08:35 PM, Søren Sandmann wrote:
Bill Spitzak writes:
Søren Sandmann wrote:
No, I'm talking about keeping internal buffer as 32 bit pixels, and then
dithering the final conversion to 565, as opposed to having 16 bit
internal buffers and dithering gradients to that before compos
Bill Spitzak writes:
> Søren Sandmann wrote:
>
>> However, unless using 16 bpp for the internal buffers is really a
>> performance win, there doesn't seem to be any benefits to doing it this
>> way over just dithering the final image. And I definitely want to see
>> convincing numbers before beli
Søren Sandmann wrote:
However, unless using 16 bpp for the internal buffers is really a
performance win, there doesn't seem to be any benefits to doing it this
way over just dithering the final image. And I definitely want to see
convincing numbers before believing that 16 bpp for internal buffe
Siarhei Siamashka writes:
>> The specific dither algorithm I used was a variant of ordered dither
>> using the dither matrix from GdkRGB
>>
>>http://git.gnome.org/browse/gtk+/tree/gdk/gdkrgb.c?id=2.24.15#n968
>>
>> which is a 128 x 128 table containing 256 copies of the values from 0 to
>>
On Wed, 13 Feb 2013 01:08:20 +0100
sandm...@cs.au.dk (Søren Sandmann) wrote:
> Ben Avison writes:
>
> > Since we're discussing bit-exactness, I have a related question. One
> > nice group of instructions in ARMv6 are capable of doing things like
> >
> > a += (b * c) + (d * e)
> >
> > in a sing
On Tue, 12 Feb 2013 22:17:12 +0100
sandm...@cs.au.dk (Søren Sandmann) wrote:
> Siarhei Siamashka writes:
>
> >> > Moreover, anyone using r5g6b5 format is most likely either memory or
> >> > performance constrained, so they would not particularly appreciate the
> >> > more accurate, but slower co
On Wed, 13 Feb 2013 00:08:20 -, Søren Sandmann wrote:
One thing that would help would
be to make downconversions do rounding instead of bitshifting, that is,
to convert from 8 to 6 bits, do
v6 = floor ((v8 / 255.0) * 63.0 + 0.5)
but of course implemented with integer arithmetic:
Ben Avison writes:
> Since we're discussing bit-exactness, I have a related question. One
> nice group of instructions in ARMv6 are capable of doing things like
>
> a += (b * c) + (d * e)
>
> in a single cycle, where b, c, d and e are 16-bit quantities. This is
> potentially useful for certain
Since we're discussing bit-exactness, I have a related question. One
nice group of instructions in ARMv6 are capable of doing things like
a += (b * c) + (d * e)
in a single cycle, where b, c, d and e are 16-bit quantities. This is
potentially useful for certain types of compositing - except th
Søren Sandmann writes:
> (only an approximation because it converts to 8 bit before converting to
> 5/6 bits), which can be compared to the rounded version:
>
>http://people.freedesktop.org/~sandmann/dither-perfect.png
>
This should be:
http://people.freedesktop.org/~sandmann/dither-roun
Siarhei Siamashka writes:
>> > Moreover, anyone using r5g6b5 format is most likely either memory or
>> > performance constrained, so they would not particularly appreciate the
>> > more accurate, but slower conversion between a8r8g8b8 and r5g6b5.
>>
>> It's not an academic discussion btw. If we
On Sat, 02 Feb 2013 21:23:04 +0100
sandm...@cs.au.dk (Søren Sandmann) wrote:
> Siarhei Siamashka writes:
>
> >> pixel 0x03c0, the true floating point value of the resulting green
> >> channel is:
> >>
> >>0xc3 / 255.0 + (1.0 - 0x0f / 255.0) * (0x0f / 63.0) = 0.9887955
> >>
> >> but when com
Siarhei Siamashka writes:
>> == a8r8g8b8 OVER r5g6b5 ==
>>
>> When OVER compositing the a8r8g8b8 pixel 0x0f00c300 with the x14r5g6b5
>
> Did you actually mean x14r6g6b6?
Yes, thanks.
>> pixel 0x03c0, the true floating point value of the resulting green
>> channel is:
>>
>>0xc3 / 255.0 + (
On Thu, 24 Jan 2013 10:52:59 -0500
Søren Sandmann wrote:
> From: Søren Sandmann Pedersen
>
> The check-formats programs reveals that the 8 bit pipeline cannot meet
> the current 0.004 acceptable deviation specified in utils.c, so we
> have to increase it. Some of the failing pixels were capture
From: Søren Sandmann Pedersen
The check-formats programs reveals that the 8 bit pipeline cannot meet
the current 0.004 acceptable deviation specified in utils.c, so we
have to increase it. Some of the failing pixels were captured in
pixel-test, which with this commit now passes.
== a4r4g4b4 DISJ
15 matches
Mail list logo
