Thanks Alex,
DCRAW reports the dark value as being 600 but the raw values extracted with DCRAW show 588. You are probably right that this value could vary. It's just a shame that the values below this are clamped. Canon does not clamp it's low values...but they set the dark value to roughly 2048 which gives up some dynamic range in a 14b raw file. I asked NIKON if they would consider an "astrophotography" firmware update that keeps the 600 dark value but does not clamp the values until they get close to zero. This would preserve the entire bell curve noise histogram for virtually all cases. I don't expect a reply.
I came back several times to correct the post, but it didn't show up so I went back to work. :) I guess my posts are moderated first, eh?
Anyway, no, it's working fine.
Is there a list somewhere of the standard file extensions for the filetypes that libraw supports? As a practical matter, I send some files to some loaders, and others to other loaders.
Under development for OSX 10.11 and later (may be ported to Windows — it's built with Qt, and I'm trying hard to keep it portable by not using anything specific to OSX), available as a free beta (not sure what the eventual release terms will be, but certainly not onerous):
iToolBox is a general-purpose image editor with a non-modal, fast area selection model, a high degree of orthogonality facing the user (learn how to do one thing, you've learned how to do many things), and a powerful layered image system including geometric warp layers.
I expect iToolBox to be mostly feature complete (as far as the current roadmap goes) by the end of June, 2018. New betas are posted most days. I welcome bugs, comments, feature suggestions, etc.
I am using libraw; so far, I've had great success with .CR2 files from my Canon 6D MkI DSLR.
Adobe are offering a free self-standing converter http://download.adobe.com/pub/adobe/dng/mac/DNGConverter_10_3.dmg
You can also save DNG from ACR or Lightroom, but using a converter over an original file is the cleaner way.
If you have some camera profile in ACR / Lr active other than Adobe Standard it may also boost lightness.
Here's a comparison between the two. I turned around and looked at the guitar, and the libraw result is truer to the actual colors of the instrument than the lightroom first-pass rendering:
Good to know. Is there an example somewhere that shows how to do that in a step by step manner?
What I would like is to be able to load an image from the raw file as the camera generally would have the user see it using the user's white balance and so on, exposed as they see it on the camera's preview. Ideally, it would be ready to view and do further adjustments to if desired.
I found an error with my code; I can now read the data. Thank you for your prompt reply.
However, it appears to be Bayer sensor mosaic data; does libraw do conversion to adjusted, de-mosaiced 16-bit image data? Or is that something I am expected to do from the bayer mosaic data?
Here's part of the image as displayed in Adobe Lightroom:
1st: raw2image does not subtract black level, most likely you need to do that (by calling LibRaw::subtract_black() after raw2image).
Also, you may access raw data via imgdata.rawdata.raw_image (this is flat array with unaltered raw values; pixels outside of active area are included too).
max value of 5600 (before black subtracted) is about ~2 stops lower than this camera data range, so your image is, most likely, heavy underexposed.
Windows compilers are not limited to MSVC/MinGW (Intel, clang /very different flavours on Windows/, PGI, Wacom....).
Although most compilers *should* mimics to some of mainstream ones, I'm not sure they really does it (right way and in all versions)
So, WIN32 is defined manually while building LibRaw to indicate that Win32-like environment is present.
We're open to patches: if someone wants to accurately replace #ifdef WIN32 to something better (to work automatically with most common compilers), we'll happily use this patch (too late for 0.19, but in future version)
Thank you for the explanation. I'm aware of the difference between WIN32 and _WIN32, but this use seems a bit irritating. Why not using _MSC_VER or some _MINGW macro to identify the compiler?
Yes, you need it in app too.
WIN32 does not means 'not 64 bit'.
Please note, that WIN32 and _WIN32 are not the same. _WIN32 is defined in both MS and MinGW/Cygwin compilers. BTW (old versions of) MinGW does not support unicode filenames. So, to use open_wfile() call (needed if you wish to support non-native-locale filenames) you need to define WIN32 macro.
Thanks Alex,
DCRAW reports the dark value as being 600 but the raw values extracted with DCRAW show 588. You are probably right that this value could vary. It's just a shame that the values below this are clamped. Canon does not clamp it's low values...but they set the dark value to roughly 2048 which gives up some dynamic range in a 14b raw file. I asked NIKON if they would consider an "astrophotography" firmware update that keeps the 600 dark value but does not clamp the values until they get close to zero. This would preserve the entire bell curve noise histogram for virtually all cases. I don't expect a reply.
Yes, all new forum topics (from all users) and new comments (from not-logged-in users) are premoderated due to enormous volume of forum spam.
I came back several times to correct the post, but it didn't show up so I went back to work. :) I guess my posts are moderated first, eh?
Anyway, no, it's working fine.
Is there a list somewhere of the standard file extensions for the filetypes that libraw supports? As a practical matter, I send some files to some loaders, and others to other loaders.
--Ben
Nikon D5300 black level/bias/'zero' value is 600 for ISO160 (the sample I've just checked).
Values slightly below 'zero level' are normal (in dark field something like bell curve around 'zero' is expected).
P.S. Sorry for late reply, for some unknown reason this question was not seen in comment moderation queue until today.
Is there any problem with these files? I do not see any, dcraw_emu -T ... works as expected.
Under development for OSX 10.11 and later (may be ported to Windows — it's built with Qt, and I'm trying hard to keep it portable by not using anything specific to OSX), available as a free beta (not sure what the eventual release terms will be, but certainly not onerous):
iToolBox is a general-purpose image editor with a non-modal, fast area selection model, a high degree of orthogonality facing the user (learn how to do one thing, you've learned how to do many things), and a powerful layered image system including geometric warp layers.
I expect iToolBox to be mostly feature complete (as far as the current roadmap goes) by the end of June, 2018. New betas are posted most days. I welcome bugs, comments, feature suggestions, etc.
I am using libraw; so far, I've had great success with .CR2 files from my Canon 6D MkI DSLR.
Adobe are offering a free self-standing converter http://download.adobe.com/pub/adobe/dng/mac/DNGConverter_10_3.dmg
You can also save DNG from ACR or Lightroom, but using a converter over an original file is the cleaner way.
If you have some camera profile in ACR / Lr active other than Adobe Standard it may also boost lightness.
How would you have me convert it? What tool, etc. I'm using OS X 10.12
Alex,
Here's a comparison between the two. I turned around and looked at the guitar, and the libraw result is truer to the actual colors of the instrument than the lightroom first-pass rendering:
http://fyngyrz.com/images/comparisonnow.png
Alex, I suggest you add these to your example on the API intro page:
// Convert from imgdata.rawdata to imgdata.image:
// ----------------------------------------------
iProcessor.raw2image();
iProcessor.imgdata.params.use_camera_wb=1;
iProcessor.subtract_black();
iProcessor.dcraw_process();
Kudos. Fine work you've done. :)
Could you please convert this image to DNG and look at the value of the baseline exposure tag? LibRaw doesn't apply that correction of lightness.
imgdata.params.use_camera_wb=1;
(default white balance is daylight)
Also, Lightroom applies 'adobe hidden camera exposure correction': https://photographylife.com/adobes-silent-exposure-compensation
Here it is in lightroom, you can see the histogram, well exposed, no adjustments;
http://fyngyrz.com/images/in-lightroom.png
Here it is loaded as 16-bit data after:
iProcessor.raw2image();
iProcessor.subtract_black();
iProcessor.dcraw_process();
As loaded:
http://fyngyrz.com/images/as-loaded.png
So it doesn't look properly white balanced at all. What am I missing?
Good to know. Is there an example somewhere that shows how to do that in a step by step manner?
What I would like is to be able to load an image from the raw file as the camera generally would have the user see it using the user's white balance and so on, exposed as they see it on the camera's preview. Ideally, it would be ready to view and do further adjustments to if desired.
This sequence:
iProcessor.raw2image();
iProcessor.subtract_black();
iProcessor.dcraw_process();
resulted in a deep red image. Not correct at all.
If I load it with just this...
iProcessor.raw2image();
...I can, with a serious gaussian blur and a window and level adjustment, turn it into something close to what it should be.
So I'm still missing something.
LibRaw::dcraw_process does full postprocessing pipeline (white balance, demosaic, color conversion...)
I found an error with my code; I can now read the data. Thank you for your prompt reply.
However, it appears to be Bayer sensor mosaic data; does libraw do conversion to adjusted, de-mosaiced 16-bit image data? Or is that something I am expected to do from the bayer mosaic data?
Here's part of the image as displayed in Adobe Lightroom:
http://fyngyrz.com/images/from-lightroom.png
Here's what I'm reading from more or less the same region:
http://fyngyrz.com/images/from-libraw.png
I have not done a black level subtraction, inasmuch as that would dim the image even more.
1st: raw2image does not subtract black level, most likely you need to do that (by calling LibRaw::subtract_black() after raw2image).
Also, you may access raw data via imgdata.rawdata.raw_image (this is flat array with unaltered raw values; pixels outside of active area are included too).
max value of 5600 (before black subtracted) is about ~2 stops lower than this camera data range, so your image is, most likely, heavy underexposed.
LIBRAW_OPENMP define should be defined only if you use OpenMP builds.
Fuji compressed decoder contains critical section. This section is implemented via
#pragma omp critical // --> if LIBRAW_OPENMP defined
and via own locking mechanics if OpenMP is not used.
Windows compilers are not limited to MSVC/MinGW (Intel, clang /very different flavours on Windows/, PGI, Wacom....).
Although most compilers *should* mimics to some of mainstream ones, I'm not sure they really does it (right way and in all versions)
So, WIN32 is defined manually while building LibRaw to indicate that Win32-like environment is present.
We're open to patches: if someone wants to accurately replace #ifdef WIN32 to something better (to work automatically with most common compilers), we'll happily use this patch (too late for 0.19, but in future version)
Thank you for the explanation. I'm aware of the difference between WIN32 and _WIN32, but this use seems a bit irritating. Why not using _MSC_VER or some _MINGW macro to identify the compiler?
AFAIK, Delphi developers use LibRaw C-API (do not know it needs additional wrapper level or not)
Yes, you need it in app too.
WIN32 does not means 'not 64 bit'.
Please note, that WIN32 and _WIN32 are not the same. _WIN32 is defined in both MS and MinGW/Cygwin compilers. BTW (old versions of) MinGW does not support unicode filenames. So, to use open_wfile() call (needed if you wish to support non-native-locale filenames) you need to define WIN32 macro.
Does this mean that applications should also #define WIN32 before including libraw.h? At least for x64 builds this might not be the case by default.
Erwin
LibRaw's Makefile.mscv also defines WIN32:
COPT=/EHsc /MP /MD /I. /DWIN32 /O2....
(while Makefile.mingw is not)
This is the way we distinguish native win32/VisualStudio build environment from emulated linux-like one (with time.h and other posix calls)
Fantastic! Thank you!
We decided to sync our color data with Adobe for Canon 6D: https://github.com/LibRaw/LibRaw/commit/4b76e9b385a062fdb60be8240b6ecaf3...
Pages