Skybuck Flying wrote:
> This way finally all bit planes would be extracted.
>
> Hope this clearifies the idea a bit ;) :)
It was very clear, what you intended to do, but the whole thing
makes no sense. Normally you want to keep the bits together.
With your storage scheme, you'd introduce a width*height*24 bit
stride between bits belonging together. Furthermore, the planes
would ****ft with a modulo 24 within your DWORDs, which makes
things even worse.
Things are the following: Every pixel designates a vector of base
colours (RGB, RGBA, CMYK, LAB, etc.), each element of the vector
having a certain length (number of bits). Common values are 8,
16 or 32 bits. So your image is actually a H x W x C x B tensor,
now you can serialize such a tensor respective to a given base.
And normally you want to stream out data with the fastest
changing coordinate in regular access also the festest changing
in the stream. And that would be the bits. So your streaming
order would be B->C->W->H, but it's also common to stream
B->W->H->C, i.e. streaming out subimages for each channel.
It makes however no sense to stream
W->H->C->B, which is what you want to do. Practically this rips
the whole data apart, trashes the chache, and all in all is a
bad idea.
Wolfgang Draxinger
--
E-Mail address works, Jabber: hexarith@[EMAIL PROTECTED]
ICQ: 134682867
|
