On Thu, 26 May 2016, Graeme Geldenhuys wrote:
On 2016-05-26 12:08, Michael Van Canneyt wrote:
BUT:
depending on UsePalette, it contains indexes in the palette or RGB Data.
Oh, I forgot about Palette usage. I’ll have to check for that in my
code. Does setting UsePalette := False at runtime auto convert palette
data to RGB data? I had a look at TFPCustomImage.SetUsePalette() but it
is not immediately obvious what it does at runtime (after image data was
already loaded).
Yes it does, but this is very slow.
It is definitely possible that you are wrong.
:-) Definitely not the first time that happened.
Yes. The Pixels array is a palette. The colors array is RGBA.
Good to know the difference, thanks.
4) What is the order in which the colour channel information is stored
in memory? RGB, BGR, RGBA, BGRA, ARGB, ABGR etc?
You should not worry about this. The whole idea is that you do not use the
internal format, but just use the colors array:
But that would be super slow.
Yes. But sometimes it is all you've got; e.g. when drawing on an image.
The reason for all these questions. I've got a image loaded in a
TFPMemoryImage instance. I need to pass the the raw pixel data buffer to
a 3rd party library for further processing. But I need to tell that
3rd party library a bit about the data I'm giving it (colour channel
size, colour channel order etc).
This is not supported for TFPMemoryImage.
Well, I seem to have it almost working (see my other message with
attached image). I didn’t know about the TFPCompactImgBase descendants -
I’ll give them a try instead. That seems more like what I need.
It probably is.
For completeness, in fpImage: when doing 16 bit image, then
(16-bit color value)=(8-bit color value) shl 8 + (8-bit color value)
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
