Hello! For starters, thank you for putting together a wonderful toolkit!
I'm working on a C# project that currently uses FreeImage for raw image processing, and converting it over to libraw so it can support newer raw image formats.
The application already has its own interpolation/debayering and other postprocessing code -- what I need back from libraw's C API is a straight shot at the unpacked raw image data. Unfortunately, all the code pathways through the C API only allow for access once the image has gone through dcraw_process(), and that isn't what I need back. I could write the raw image, call unprocessed_raw on the file, and then read the resulting TIFF file, but I'd rather not go out to the disk if I can avoid it -- its a lot of unnecessary overhead.
Would you be willing to extend the API with 10 lines of code ? This gives the C API a means to get directly at the raw data, and does everything a lot cleaner from C#.
ushort* libraw_get_raw_data(libraw_data_t* lr)
{
if (!lr)
return NULL;
if (!&(lr->rawdata))
return NULL;
return (lr->rawdata.raw_image);
}
Please advise, and thanks!
Pointer to raw data itself is
Pointer to raw data itself is useless without access to metadata (black/white level, bayer pattern, color data, white balance data, image size, etc, etc, etc).
So you'll need to access all internals anyway.
-- Alex Tutubalin @LibRaw LLC
... and this red thermos.
Thanks for the quick response!
For this project, I need three things from the raw data: image height, image width, and the bitmap. There's already C calls for get_raw_height and get_raw_width -- all I need past that is the raw bitmap.
Black/white level, bayer pattern, color data, and white balance data are all needed if you need to reconstruct a full color original image-- and for that, yes, dcraw_process() is absolutely the right thing to call, because it manipulates the bitmap to reconstruct the image. This app don't need that level of processing. I also tried using raw2image, and even that appears to do some light debayering work and modifying the base bitmap.
This project needs the raw, unmodified bitmap straight off the camera sensor. It doesn't need any of the white balance data or color information, nor is it trying to recreate the full color picture. However, what's critical is the turnaround time between shutter snaps- in between shutter snaps, the app needs to extract the raw image data, review it for just a couple things, make decisions, and get back to the business of taking pictures as quickly as it can.
The first pass at implementing libraw invoked the unprocessed_raw utility (using the -T switch) to convert the bitstream to a TIFF, and it does exactly what was needed. However, it also adds the overhead of writing to/reading from the disk twice, as well as wrapping the bitmap in a TIFF wrapper.
Ideally the app should get the image from the camera, extract the things it needs from the raw data in memory, and pass everything around in memory buffers. Adding that one routine to the API would streamline the entire process, and make that capability available for anyone else as well.
The C-api call you proposed
The C-api call you proposed may fit your specific needs, sure. It is not enough if someone want to create generic raw processing tool, that handle non-bayer data (or even if row pitch is not raw_width*2).
Current C-API is limited for single (but most frequently requested) task: create rendered RGB image from RAW. In general, it is possible to create C-wrappers for each LibRaw class data field, but this is out of our goal and scope, sorry. LibRaw is C++ library, no plans to make it fully functional when called from C.
-- Alex Tutubalin @LibRaw LLC