RE: [Algorithms] 16Bit Cross Fade

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Aha ! 

I should learn to never assume anything... 

:-)

> -----Original Message-----
> From: Paul Johnson [mailto:pa...@st...]
> Sent: 13 August 2001 16:55
> To: 'gda...@li...'
> Subject: RE: [Algorithms] 16Bit Cross Fade
> 
> 
> What cache ?  (I'm on a strongarm 206 pocket pc !)
> 
> -----Original Message-----
> From: David Hunt [mailto:da...@hu...]
> Sent: 13 August 2001 15:06
> To: gda...@li...
> Subject: Re: [Algorithms] 16Bit Cross Fade
> 
> 
> Aren't the cache misses on the random accesses to those 2 
> large tables going
> to totally swap any cumbersome shift/mask/sum sequence?
> You might get away with a 256 byte table?
> 
> 
> David
> 
> ----- Original Message -----
> From: Tom Forsyth <to...@mu...>
> To: <gda...@li...>
> Sent: Monday, August 13, 2001 2:24 PM
> Subject: RE: [Algorithms] 16Bit Cross Fade
> 
> 
> > For any additive-style blend (i.e. factor1*src + 
> factor2*dest), you can
> > always split any pixel format into byte chunks, look up the 
> result in a
> > 64k-entry table, and then add the two results together. 
> e.g. for a 16-bit
> > format (any 16 bit format, even 565):
> >
> > WORD wTableHi[65536];
> > WORD wTableLo[65536];
> >
> > wResult = wTableHi[ (wSrc>>8) | (wDest&0xff00) ] +
> >     wTableLow[ (wSrc&0xff) | (wDest<<8) ];
> >
> > Yes, those tables have to be words, not bytes - wTableHi 
> has interesting
> > values in its low bits, and the two results must be _added_ 
> together, not
> > ored.
> >
> > This keeps the sizes of the tables down to sane 
> proportions, though 256k
> is
> > still not exactly tiny :-)
> >
> > Tom Forsyth - Muckyfoot bloke.
> >
> > What's he up to now (and can I have a go)?
> > http://www.eidosinteractive.com/downloads/search.html?gmid=86
> >
> > > -----Original Message-----
> > > From: Wojciech Wylon [mailto:ww...@ga...]
> > > Sent: 13 August 2001 14:02
> > > To: gda...@li...
> > > Subject: RE: [Algorithms] 16Bit Cross Fade
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: gda...@li...
> > > [mailto:gdalgorithms-list-
> > > > ad...@li...] On Behalf Of Paul Johnson
> > > > Sent: Monday, August 13, 2001 1:51 PM
> > > > To: 'gda...@li...'
> > > > Subject: RE: [Algorithms] 16Bit Cross Fade
> > > >
> > > > Hehe. That's similar to what I'm doing at the moment, but I
> > > know there
> > > is a
> > > > better way - just not what that way is ;)
> > > >
> > > > -----Original Message-----
> > > > From: John White [mailto:jo...@de...]
> > > > Sent: 13 August 2001 11:28
> > > > To: gda...@li...
> > > > Subject: RE: [Algorithms] 16Bit Cross Fade
> > > >
> > > >
> > > > I did some code to do this.
> > > > The approach I took was to do simple bitmasking to do 
> the effect.
> > > >
> > > > For example to do a 50/50 blend between two images you 
> can do (this
> > > assumes
> > > > 565 pixel format).
> > > > outpix = ((pix1&0xf7def7de)>>1) + ((pix2&0xf7def7de)>>1);
> > > >
> > > For 24 bits: create two 256 LUT and for when you blend 
> images calc the
> > > blend values for alpha and for 1-alpha - than use
> > > these two tables when
> > > you blend
> > >
> > > Somethink like that ...
> > > for(i = 0; i < imageSize; i++)
> > > rgbDest[i].Set(LUT_ALPHA[rgbSrcA[i].r] +
> > > LUT_1_ALPHA[rgbSrcB[i].r],
> > >    LUT_ALPHA[rgbSrcA[i].r] +
> > > LUT_1_ALPHA[rgbSrcB[i].r],
> > >    LUT_ALPHA[rgbSrcA[i].r] +
> > > LUT_1_ALPHA[rgbSrcB[i].r]);
> > >
> > > For 16 bits(or 15 bits) you create eg. two 32 LUT and two 64
> > > LUT and you
> > > have first split to R, G and B and next merge it back.
> > >
> > > You can also consier: convert both pics to 8 bit version 
> and create
> > > 256x256 LUT table: for(i = 0; i < imageSize; i++)
> > > rgbDest[i] = LUT_256_256[rgbSrcA[i]*256 + rgbSrcB[i]];
> > >
> > > Or you can do it in some other possible ways...
> > >
> > > WW
> > >
> > >
> > > > // For a 75:25 blend you can do
> > > > outpix = ((pix1&0xf7def7de)>>1) + ((pix1&e79ce79c)>>2) +
> > > > ((pix2&e79ce79c)>>2);
> > > >
> > > >
> > > > For every other combination of ratios (e.g. 25:75,
> > > 12.5:87.5, etc...)
> > > a
> > > > similar expression to the above can be used. Just have 
> a different
> > > inner
> > > > loop for each combination.
> > > >
> > > > For MMX 4 pixels can be done simultaneously and no LUTs 
> are needed.
> > > >
> > > > A smoother effect can also be done by using the written to
> > > destination
> > > as
> > > > the source on the next iteration.
> > > >
> > > > John
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: gda...@li...
> > > > 
[mailto:gda...@li...]On Behalf Of
> > Paul
> > > Johnson
> > > Sent: 13 August 2001 10:12
> > > To: 'gda...@li...'
> > > Subject: [Algorithms] 16Bit Cross Fade
> > >
> > >
> > >
> > > I need to do a *software* blend between two 16bit images. The effect
> > I'm
> > > after is to reveal a picture that's 'behind' another one by
> > making the
> > > apparent alpha value of the back one blend from 0 to 1.
> > >
> > > I can obviously allocated a 64Kx64K look-up table for this,
> > but memory
> > might
> > > be a bit of a problem, at least for another year or two. I remember
> > from way
> > > back that this effect could be generated with either 1 or 2 256x256
> > tables
> > > working on the hi and lo bytes respectively.
> > >
> > > Given that the green amount is split over both the lo and
> > hi bytes, I
> > just
> > > can't seem to work out how to do this. Anyone done it before ?  Got
> > some
> > > code to look at ?
> > >
> > > Many thanks in advance...
> > >
> > > Paul Johnson
> > > Guy who works at
> > > Stainless
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list