(sorry for lack of In-Reply-To, I'm jumping in late on this list) Will Stokes wrote (citing Dave Coffin):
> There's a simpler way to make dcraw modular and thread-safe: Run it > as a separate process. That's something I played with a bit when toying with an idea for a RAW processor some year ago. (No, nothing much worth showing came out of that.) My idea was to make a relatively minimal patch to dcraw.c that could hopefully be easily reapplied for each new version Dave releases. To make dcraw suitable to be used like a library, but still run as a separate process, I added the option to have it read a decompressed RAW image from, and write the RGB image to, pre-existing shared memory buffers. (Instead of reading and writing files.) (The ids of the shared memory regions would be passed as command-line parameters.) I also added the possibility to process just a subrectangle of the RAW image, to enable the host application to use dcraw to quickly produce just small "magnifying glass" style portions of a final processed image. And finally I added options to run dcraw in phases: - Decode and decompress the RAW file into a shared memory buffer of still Bayerize data. - Do the actual debayerization work of converting such a buffer to RGB The idea was that the decoding and decompressiong, which takes significant time, could be done just once for a RAW file, and then the debayerization could be rerun as necessary on the same data with different parameters as necessary when the user tweaks the settings in the host application. If anybody is interested, I could provide the code for this. At least back in 2004, it was a relatively "light" patch to dcraw.c, 343 lines in diff -u0 format, and worked as intended (Unix/Windows cross-platform). --tml _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
