Re: [GD-DEVEL] Question about importing data from memory

Pierre wrote:
> Hi Jeff,
>
> On Nov 28, 2007 3:56 PM, Jeff Cunningham <[email protected]> wrote:
>   
>> Hi,
>>
>> I am processing some imagery that comes directly from sensors so that I
>> end up with it in an NxM array of unsigned integers of rgb values (for
>> example, array[0][0]=\xff0000 would be a red pixel in the upper-left
>> corner). Some of this imagery wants to end up on web pages with text
>> annotation, which is why I am looking at using the gd library.
>> Currently, I save these images as bmp files using my own code, convert
>> them to jpeg using imagemagick's convert utility, and they have no
>> annotations.
>>
>> Is there a way to get the data from my arrays directly into a gdImage? I
>> was looking through the API and could only find the function
>> gdImageCreateFromGdPtr:
>>
>> http://www.libgd.org/OldImageCreation#gdImageCreateFromGdPtr.28int_size.2C_void_.2Adata.29_.28FUNCTION.29
>>
>> but I couldn't find any description of the format of a GdPtr. I could go
>> to the source code, but in my experience when something isn't described
>> in the API, its often not stable, so I don't want to get off on the
>> wrong track.
>>     
>
> You can see an example in the PHP sources. It may sound complex at a
> first glance but the principle is relatively simple. It uses a custom
> IO Ctx and pass it to the gdImageCreate*Ctx function. The source can
> be read online here:
>
> http://cvs.php.net/viewvc.cgi/php-src/ext/gd/gd.c?revision=1.382&view=markup
>
> See the imagecreatefromstring function.
>
> One function that will considerably ease this task is
> gdImageCreateFromData, it is not yet implemented but it is planed for
> 2.1.x. This function let you create a GD image using your own buffer.
>
>   
>> I did take a look at a couple of the files like gdxpm.c for guidance,
>> and there it appears that one creates a gdImage and populates it by
>> creating a color table on the fly and writing indices instead of pixels.
>> The problems I can see with this approach are that - unless duplicate
>> color entries are allowed - there will be a significant overhead
>> involved in searching the table for an existing color each time before
>> creating a new one, which with Truecolor could be hugely inefficient.
>>     
>
> You can have duplicate colors in a palette. Each palette entry is
> independent from another. The amount of entries is limited to 256.
> TrueColor images may be more efficient in your case.
>
>   
>>  I didn't see any related discussions in the list archives. How do
>> people handle this kind of problem?
>>     
>
> I can try to implement the basic features for the new
> gdImageCreateFromData, it may ease your work and will give me some
> early feedbacks :-)
>
> Cheers,
> --Pierre
>
>   
Thanks, Pierre. I'll look at that code. How do you handle Truecolor 
images?  From what I've seen in your code it looked like they still used 
an indexed palette, only a much bigger one. Is this not the case? I 
definitely need to be working with 24-bit color (8-bits per r,g,b gun).

Yes, if you want to give me a prototype for gdImageCreateFromData, I 
would be happy to help in any way I can.

Regards,
--Jeff