Re: [Algorithms] converting 32bpp textures to 8bpp textures with 32bpp CLUTs
Brought to you by:
vexxed72
From: Jamie F. <j.f...@re...> - 2000-11-30 09:41:39
|
Certainly could do that. Just wondering if anyone could put their hand on their heart and say 'this method's great' :) Problem with the method though: consider a texture where for each transparent texel there is an opaque pixel with the same RGB, which remains the closest palette entry in the second pass. The method you describe would leave a completely opaque texture. Not quite sure how contrived that example is. Will be simple enough to code and test, once our... urm... GPU interface packets are attached nicely :) Jamie Tom Forsyth wrote: > Can't you just do the palette selection, and then scan all the original > pixels. Where a pixel is completely opaque in the original source, ensure > that its palette entry is also opaque (i.e. if the palette entry was > alpha=253, change it to have alpha=255). Then refind the closest pixel > matches, just in case. Seems simple enough to code and test, at the very > least. > > Tom Forsyth - purely hypothetical Muckyfoot bloke. > > This email is the product of your deranged imagination, > and does not in any way imply existence of the author. > > > -----Original Message----- > > From: Jamie Fowlston [mailto:j.f...@re...] > > Sent: 29 November 2000 12:41 > > To: algorithms > > Subject: [Algorithms] converting 32bpp textures to 8bpp textures with > > 32bpp CLUTs > > > > > > We're soon going to be trying to generate 8bpp textures with 32bpp > > palettes from 32bpp original images. Obviously, 8bpp textures > > don't have > > an alpha channel; this has to be represented in the palette. > > > > Standard colour reduction, but with 4 channels, not 3, worries me. I > > suspect we'll end up with textures which are all (slightly) > > transparent. > > We could play with the weighting function, but I don't think it really > > addresses the fundamental problem. > > > > An alternative is to split the palette, so that a certain number of > > colours are reserved for opaque entries. Then we do two > > standard palette > > calculations, one to get the opaque entries, one to get the > > transparent > > entries. We could have the palette split artist controllable, and / or > > calculate a decent automatic split by some weighting function. > > > > So... anyone who's done this sort of thing before want to drop a few > > hints? :) > > > > Jamie > > > > -Virus Scanned and cleared ok > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list -Virus Scanned and cleared ok |