On Tue, 14 Aug 2001, Eric Faurot wrote:
> Hi all,
>
> Looking at libgpf, I noticed a few problems with the current
> highlevel API :
>
> - It doesn't handle palette formats.
It doesn't do that as the result (the picture) is stored in a visual.
> - We can't initialize a image to write with a given size/frame
> number.
gpfSelectImage() is for multiimage formats like gif. You can say I wanna
read the third frame of it. gpf handles a picture as a kind of streaming
data. The size is handled in lowlevel.
> - Writer and loader drivers must be separated to decrease
> the memory footprint on embedded systems, especially when
> encoding is complicated. ( maybe it was thought like this )
This is done in the lowlevel API.
> - The read/write callback should accept another void * argument
> to 'contextualize' the call. (I hate those context-less SAX
> parsers!)
See lowlevel API.
> - There should be a way to choose a pixel layout for the driver.
> When reading an image, it specifies the expected format.
> The driver should handle any required transformations.
> examples: - rgba -> rgb
> - gray -> rgb
> - rgb -> gray
> - palette -> rgb
> - palette -> rgba
> - rgb -> palette (maybe rather complicated if
> dithering
> or color reducing alogirithms are implemented)
> Other weird transformations are possible:
> ex: channel extraction rgb -> b
> Each channel can have a specific number of bits, the driver should
> perform color scaling accordingly.
I wrote libgcp to handle that. It still doesn't handle everything,
what is needed for libgpf.
> I propose the following, at least for reading:
>
> gpf_channellayout {
> char bitmeaning; /* r,g,b,a, y,u,v, C,M,Y,K... */
> char bitnum; /* number of bit for this channel */
> char layout; /* Endianness */
> char padding; /* ... */
> }
>
> gpf_pixelformat {
> int nbchannel; /* number of used channel */
> gpf_channellayout layout[GPF_MAX_CHANNEL];
> }
>
> gpf_fileinfo {
> int width,frames;
> int frames;
> int palette_size; /* -1 means no palette */
> gpf_pixelformat pixelformat; /* prefered format */
> }
>
> typedef gpf_channellayout * gpf_channellayout_t;
> typedef gpf_pixelformat * gpf_pixelformat_t;
> typedef gpf_fileinfo * gpf_fileinfo_t;
>
> /* fill 'buffer' with the palette values in the 'format' layout. */
> /* The buffer must be allocated to the correct size. */
>
> gpfGetPalette(gpf_handle_t handle, gpf_pixelformat_t format, void *
> buffer);
>
> /* instead of gpfSelectImage */
> gpfSelectFrame(gpf_handle_t handle, int frame);
>
> /*
> Start reading the image. the data 'data' will given to the callback
> as the first parameter as context. The pixel will be expressed in the
> required 'format'.
>
> Return value:
>
> O Ok
> -1 Read error (transfer interrupted, disk crash, hardware on
> strike...)
> -2 Format error (the file format is invalid )
> -3 Pixelformat error (tranformation is impossible for the given file)
>
> */
> int
> gpfRead(gpf_handle_t handle, gpf_pixelformat_t format,
> gpfReadCallback cbR,
> gpfIndicatorCallback cbI,
> void * data);
Not needed. This is handled by the driver internally. The driver converts
data into a rgb data stream.
Read the libgpf/doc/EN_design file. The way of handling is explained
there.
Hope, that helps.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
