LibRaw does not relies on file extensions, but on file internals.
digiKam's rawfiles.h may be a good starting point for ext list (not sure it is complete): https://github.com/KDE/digikam/blob/master/core/libs/rawengine/rawfiles.h
Is there a list somewhere of the standard file extensions for the filetypes that libraw supports?
Could you please shot dark frame (with lens caps on) and share the file with us (Dropbox/Google drive/WeTransfer and send link to firstname.lastname@example.org).
Generally, 12 levels below 'relative zero' looks normal, raw histogram will show more details.
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.
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
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:
Alex, I suggest you add these to your example on the API intro page:
// Convert from imgdata.rawdata to imgdata.image:
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.
(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;
Here it is loaded as 16-bit data after:
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.
resulted in a deep red image. Not correct at all.
If I load it with just this...
...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:
Here's what I'm reading from more or less the same region:
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.