On 10/19/2009 11:16 PM, D. Zimmer wrote: >>> Hello all, >>> >>> probably this has come up before, but I can't find it: >>> >>> my application has to display JPEG images, but does not load >>> them from disk files. They come in as blobs from a remote database. >>> >>> Is there a way to load these into an Fl_JPEG_image? >>> >>> Right now I am reduced to writing them to a temp file, and then reading >>> that into the image. But that is a bad solution: it assumes that I can >>> write to disk in this application. >>> >>> I read the code (fltk 1.1.9), there doesn't seem to be a straightforward >>> way, can't just hook up an istream, or something of that nature. >>> >>> Any advice? >>> >>> >> >> I expect you will have to modify Fl_JPEG_Image. FLTK 1.1.9 has >> Fl_JPEG_Image(const char *jpeg) which is hard-coded to expect a filename. >> Write a new constructor that takes your blob of JPEG data instead, and base >> it on the existing code from Fl_JPEG_Image. >> >> I'm pretty sure this can be done, and I think you will need to make the >> following changes: >> >> 1. get rid of references to the FILE pointer in the function (declaration, >> fopen(), flose()). >> >> 2. replace the call to jpeg_stdio_src() with code to fill the >> jpeg_decompress_struct with function pointers that will operate on your blob >> of JPEG data rather than a FILE pointer. >> >> I've never done it, but I expect you should be able to find examples on the >> internet... if not, how hard could it be (memcpy(), current position >> pointer, etc.)? If you download the actual jpeglib full source, the file >> djpeg.c provides function pointers for setting up the library to handle FILE >> pointer streams... work from that. >> >> You're probably in for a a few hours coding and testing though. >> >> good luck, >> Don. >> >> >> > > sorry, not djpeg.c but jdatasrc.c, which is part of the jpeg library included > with FLTK. >
Thanks Don, Yes I saw that. On first reading, it seems that jdatasrc.c needs to be modified in maybe 2 lines of code. Where the data come from doesn't seem to make much difference, except for 2 calls to read(). But I'll try that in the day :) Probably I will make a new class, parallel to Fl_JPEG_image. FL_JPEG_image only provides a constructor (at least in 1.1.9), nothing else. That's reasonably clean. The uglier part is ending up with something new that is more part of jpeglib than of fltk. Which is probably why this hasn't been done yet, at least in public. Bernd _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
