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.
Unfortunately C++ Builder's C++ name mangling is not compatible with MSVC's. There are nasty ways to get an MSVC class in a DLL to be accessible, but I took the simple way out and extended the LibRaw C API to include the LibRaw_abstract_datastream gets() function, which seems to be all I need.
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).
datap is pointer to your datablock (context), for example data table to be filled w/ exif callback.
It is passed to callback as 1st parameter (void *, you'll need to explicitly convert type before use).
Input datastream is passed as last parameter to callback as (void*). You'll need it (so, your callback should be C++ function in that case) if you plan to read tag values. If you want to only collect tags/tag types, you may ignore this last parameter.
Know nothing about CodeGear C++, so could not help with it.
Alex,
I am trying to implement my own version of subtract_black. Following which I am trying to rescale the image to the range (0,1). For this, I need to know the black-level and white-level. Given, there are two properties that contain white-level information, I was curious to know which one to use if both maximum and linear_max are both populated.
Alex,
I am trying to apply my own black-level subtraction and image normalization. So, I just wanted to clarify on what image range I should apply the black-level subtraction. Also, I am not sure if I should use maximum or linear_max for normalization.
Alex,
For the black-levels that are specified in cblack[0]->cblack[3], do those also need to be applied starting at the visible region. I am assuming this is the case because the subtract_black_internal operates on imgdata.image which only operates on the visible image.
Also, for the white-levels, if linear_max is all zeros, then do I just assume maximum applies to all the channels.
Also, if both maximum and linear_max value is present, which value should I use?
Alex,
Thanks for this clarification. So it looks like my best bet would be to call raw2image() and subtract_black() to leverage libraw to do the black-level correction for me. I still would like to return the CFA data as a rows x columns matrix instead of the output of raw2image. I guess I have to add some custom logic to do the copying.
Also, it appears that raw2image() only returns the visible portion of the image. It typically has only 1 out of the 4 channels as non-zero. I am assuming this does not hold true for Fovean sensors or DNG files that are created from Sigma cameras?
Can I use the COLOR function for non-Bayer sensors? I have a DNG file that appears to be created from a Sigma camera. The output of COLOR(0, 0), COLOR(0, 1) returned 6.
Yes, this camera uses E-M5MarkII string in EXIF 0x0110 tag (Model).
LibRaw 0.20 (Beta1 just published) provides 'E-M5 Mark II' string in normalized_model[]
BTW, LibRaw::cameraList() is 'user readable', it contains some notes and special cases (like 'lossless only' or 'CHDK hack'). It does not targeted to be matched against model/normalized_model.
Yes, black/cblack reflects different black level specifications in RAW metadata
black - single black level
cblack[0-3] per channel BL in channel numbering order (channel numbers are returned by COLOR(..))
cblack[4-5] defines pattern BL (e.g. 6x6 for X-Trans)
As a rule: black is base level and cblack is correction, so if black is non-zero and cblack[.. is non-zero (for given channel or row/col), resulting BL for pixel/channel is a sum of black + cblack[channel] + cblack[pattern]. In practice all three are rarely present.
white is either format maximum (defined by bits per pixel), or maximum value defined by metadata (DNG whitelevel).
linear_max is 'specular white' read from metadata (if present in file)
Yeah, the weird histogram is from the inverted data. I think I'm going to have to deeply familiarize myself with what scale_colors does, because I think something in that process is relying on values that were generated prior to inverting the raw data.
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.
Wouldn't it be easier to recompile LibRaw using your compiler?
Thanks Alex
Unfortunately C++ Builder's C++ name mangling is not compatible with MSVC's. There are nasty ways to get an MSVC class in a DLL to be accessible, but I took the simple way out and extended the LibRaw C API to include the LibRaw_abstract_datastream gets() function, which seems to be all I need.
Andy
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.
datap is pointer to your datablock (context), for example data table to be filled w/ exif callback.
It is passed to callback as 1st parameter (void *, you'll need to explicitly convert type before use).
Input datastream is passed as last parameter to callback as (void*). You'll need it (so, your callback should be C++ function in that case) if you plan to read tag values. If you want to only collect tags/tag types, you may ignore this last parameter.
Know nothing about CodeGear C++, so could not help with it.
As mentioned above:
> linear_max is 'specular white' read from metadata (if present in file)
Hope this helps.
Alex,
I am trying to implement my own version of subtract_black. Following which I am trying to rescale the image to the range (0,1). For this, I need to know the black-level and white-level. Given, there are two properties that contain white-level information, I was curious to know which one to use if both maximum and linear_max are both populated.
Dinesh
I don’t know what exactly you are doing and what you mean by normalization.
Therefore, do as you think is right.
Alex,
I am trying to apply my own black-level subtraction and image normalization. So, I just wanted to clarify on what image range I should apply the black-level subtraction. Also, I am not sure if I should use maximum or linear_max for normalization.
Dinesh
Dinesh
I do not know what you want to achieve, so I could not answer (both) your questions.
Alex,
For the black-levels that are specified in cblack[0]->cblack[3], do those also need to be applied starting at the visible region. I am assuming this is the case because the subtract_black_internal operates on imgdata.image which only operates on the visible image.
Also, for the white-levels, if linear_max is all zeros, then do I just assume maximum applies to all the channels.
Also, if both maximum and linear_max value is present, which value should I use?
Regards,
Dinesh
This depends on beta feedback. Hope to finish Beta-RC-Release cycle in May.
Is there any schedule / target / roadmap currently for when the final release will drop?
Followup, 6 is intended value for non-bayer:
int COLOR(int row, int col) { if (!imgdata.idata.filters) return 6; /* Special value 0+1+2+3 */ ...COLOR() for non-bayer(x-trans) data is useless, check filters too before use.
Alex,
Thanks for this clarification. So it looks like my best bet would be to call raw2image() and subtract_black() to leverage libraw to do the black-level correction for me. I still would like to return the CFA data as a rows x columns matrix instead of the output of raw2image. I guess I have to add some custom logic to do the copying.
Also, it appears that raw2image() only returns the visible portion of the image. It typically has only 1 out of the 4 channels as non-zero. I am assuming this does not hold true for Fovean sensors or DNG files that are created from Sigma cameras?
Can I use the COLOR function for non-Bayer sensors? I have a DNG file that appears to be created from a Sigma camera. The output of COLOR(0, 0), COLOR(0, 1) returned 6.
Dinesh
Yes, you're the only person affected.
We do not log authentication data on our sites, so no way to recover the problem source. If you have your HTTP sessions dump it may help.
Hmmm.... That's what you said last time I reported this (about two years ago).
Oh well.
No plans for publishing binaries or source tarballs for beta.
Binaries and tarballs will be updated on 'release' status.
We use this site engine (drupal 7) for many sites for many years. Never seen such problem.
Hi!
Is it possible to try Windows binaries of v0.20 beta?
Or when binaries will be available?
Thanks.
Yes, this camera uses E-M5MarkII string in EXIF 0x0110 tag (Model).
LibRaw 0.20 (Beta1 just published) provides 'E-M5 Mark II' string in normalized_model[]
BTW, LibRaw::cameraList() is 'user readable', it contains some notes and special cases (like 'lossless only' or 'CHDK hack'). It does not targeted to be matched against model/normalized_model.
Yes, black/cblack reflects different black level specifications in RAW metadata
black - single black level
cblack[0-3] per channel BL in channel numbering order (channel numbers are returned by COLOR(..))
cblack[4-5] defines pattern BL (e.g. 6x6 for X-Trans)
As a rule: black is base level and cblack is correction, so if black is non-zero and cblack[.. is non-zero (for given channel or row/col), resulting BL for pixel/channel is a sum of black + cblack[channel] + cblack[pattern]. In practice all three are rarely present.
white is either format maximum (defined by bits per pixel), or maximum value defined by metadata (DNG whitelevel).
linear_max is 'specular white' read from metadata (if present in file)
Yeah, the weird histogram is from the inverted data. I think I'm going to have to deeply familiarize myself with what scale_colors does, because I think something in that process is relying on values that were generated prior to inverting the raw data.
wb_coeffs are in channel numbering order (as returned by COLOR(row,col))
Pages