🚀 go-pugleaf

Dennis,

I suppose that this works only with with 24 bits picture.

won't it be faster to work on 32 bits picture (each color has it's alpha
value)?

maybe you can have a look at Graphics32 (it supports only MMX, not SSE or
SSE2).


Armindo

Hi ADS



ADS wrote:

> Dennis,
>
> I suppose that this works only with with 24 bits picture.
>

Yes my functions are tied together with the datatypes.

>
> won't it be faster to work on 32 bits picture (each color has it's alpha
> value)?
>

Like this?

 TColor2 = array[1..4] of byte;

If think not, but i will try it out.

Both pixels one wants to blend has an alpha value - which one should we use ?
(if they differ)

>
> maybe you can have a look at Graphics32 (it supports only MMX, not SSE or
> SSE2).

What is Graphics32? - it sounds interesting.

>

>
> Armindo

Dennis

> Like this?
>
>  TColor2 = array[1..4] of byte;

yes


> If think not, but i will try it out.
>
> Both pixels one wants to blend has an alpha value - which one should we
use ?
> (if they differ)

Source one.

> > maybe you can have a look at Graphics32 (it supports only MMX, not SSE
or
> > SSE2).
>
> What is Graphics32? - it sounds interesting.

Hum hum, it's a great library made by Alex Denisov.
is MMX alpha Blending works well so let me know if your SSE or SSE2 works
faster.

http://www.g32.org

Armindo

You can also look at http://esibert.developpez.com/delphi/mmx2/image.zip to
see an example that show filters on 32 bits bitmap.

Armindo

ADS wrote:

> Dennis,
>
> I suppose that this works only with with 24 bits picture.
>
> won't it be faster to work on 32 bits picture (each color has it's alpha
> value)?
>

If one has an application with the ability of blending two pictures i guess
the user would fill in some Alpha value. This value is bound to the action of
blending two pictures and not to the pictures themselves - i think. Therefore
it is logical to me to not put Alpha values into pictures. If the user starts
this application, loads two pictures, chose Alpha=x and starts blending, we
would have to iterate through one or both pictures and fill in Alpha values
and then start the blending process. We could also merge the two processes.
Now we are copying a lot of data and this is only a good thing if we are
about to repeat the blending process with the same alpha values.
But it seems like 32 bit pictures with (Alpha values) are a normal thing.
Which benefits do we have from this?

>
> maybe you can have a look at Graphics32 (it supports only MMX, not SSE or
> SSE2).
>
> Armindo

> But it seems like 32 bit pictures with (Alpha values) are a normal thing.
> Which benefits do we have from this?

The main advantage is that you have a specific alpha value for each pixel
(interesting for making sprites or alphablending a specific region of the
source bitmap.

the other advantages is that you directly works with a DWord or an integer,
in MMX it's more interesting to work in 8 bits, 16 bits or 32 bits.

the other thing if you plan to port to kylix, it works on 8, 16 and 32 bitys
not 24....


Armindo

"Dennis" <marianndennis@email.dk> wrote in message
news:3D7E1807.24A08941@email.dk...
>
>
> ADS wrote:
>
> > Dennis,
> >
> > I suppose that this works only with with 24 bits picture.
> >
> > won't it be faster to work on 32 bits picture (each color has it's alpha
> > value)?
> >
>
> If one has an application with the ability of blending two pictures i
guess
> the user would fill in some Alpha value. This value is bound to the action
of
> blending two pictures and not to the pictures themselves - i think.
Therefore
> it is logical to me to not put Alpha values into pictures. If the user
starts
> this application, loads two pictures, chose Alpha=x and starts blending,
we
> would have to iterate through one or both pictures and fill in Alpha
values
> and then start the blending process. We could also merge the two
processes.
> Now we are copying a lot of data and this is only a good thing if we are
> about to repeat the blending process with the same alpha values.
> But it seems like 32 bit pictures with (Alpha values) are a normal thing.
> Which benefits do we have from this?

Alpha values in bitmaps are used mostly for compositing pictures, basicly it
alows antialiasing of the edges so where you have a round button the edges
of the button will blend with the background so as to provide a smooth edge.
Most comon is the pre-multiplied alpha type alpha channel where the alpha
value is how much background to add, so if for example in a 3d rendering
package a pixel is only half covered by the rendered object that pixel would
end up with an alpha 128. Which basicly means this pixel is half forground
and half background.

chris

"chris jones" <flak@clara.co.uk> wrote in message
news:3d7e2f03$1@newsgroups.borland.com...
> // load and unpack the alpha (16 bit alpha) or insert 'psllq mm2,8;' for 8
> bit alpha
> movd mm2,alpha;
> punpcklwd mm2,mm2;
> punpckldq mm2,mm2;

line wrap messed it up a bit :)

// load and unpack the alpha (16 bit alpha) or insert 'psllq mm2,8;' for
// 8 bit alpha
movd mm2,alpha;
punpcklwd mm2,mm2;
punpckldq mm2,mm2;

"Dennis" <marianndennis@email.dk> wrote in message

> This is my basic Pascal implementation.
>
> function BlendDKCI1(const Source1, Source2 : TColor; AlphaInt : Byte) :
> TColor;

Is it possible to blend several pixels (the whole bitmap) with something
like this:

procedure Blend(Src1, Src2, Dst : PByteArray; Num, Alpha : Integer);
var
  i : Integer;
begin
  for i := 0 to Num-1 do
    Dst[i] := Src2[i] - ((Src2[i] - Src1[i]) * Alpha) shr 8;
end;

If it's possible, I can imagine a very efficient code using SSE2.


--
Regards
Torjei Kvinen