Thanks for the response. It looks like FreeImage already sets that flag. But I think I was misunderstanding anyway. I thought that because (for a 12 bit image) the maximum wasn't 0xfff, but was 0xf00 which was then scaled to 0xffff that the data was being discarded. From a closer look at the source it looks like this is just because the black level (0xff) is subtracted.
Therefore it looks like the only way to "recover" the highlights is to use a method similar to libraws recover_highlights method. Unfortunately I need to do this after the data is converted to rgb, and if I understand correctly the recover_highlights method works on all four channels (though I'm not really sure what the variables kc and hsat are, and what the difference between kc and c is, if you could explain this I'd be thankful). Are you aware of any methods that work on 3 channel rgb data?
Never had the chance to say thank you for your help.
After talking to a friend, I recently regained interest in using LibRaw for personal R&D purpose. And this is exactly what I needed.
I am going to give it a try soon with some CR2 files from my rather old canon 350D.
There's a GPS datestamp in the spec too; the timestamp (which is "hour, min, sec", not "deg min, sec") is meaningless without the date.
I still suggest the info (altitude in meters, time in HMS) be added to the header file and the API docs. And for a later rev of the library, I suggest the GPS date be added. Until it is, the GPS time is unanchored in reality.
This documentation additions are just a matter of being clear and preventing the user of the library from having to dig all this up on their own, which is really unnecessary, as this stuff is pretty straightforward as long as it is described.
GPSAltitude:
Indicates the altitude based on the reference in GPSAltitudeRef. Altitude is expressed as one
RATIONAL value. The reference unit is meters.
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:
Thanks for the response. It looks like FreeImage already sets that flag. But I think I was misunderstanding anyway. I thought that because (for a 12 bit image) the maximum wasn't 0xfff, but was 0xf00 which was then scaled to 0xffff that the data was being discarded. From a closer look at the source it looks like this is just because the black level (0xff) is subtracted.
Therefore it looks like the only way to "recover" the highlights is to use a method similar to libraws recover_highlights method. Unfortunately I need to do this after the data is converted to rgb, and if I understand correctly the recover_highlights method works on all four channels (though I'm not really sure what the variables kc and hsat are, and what the difference between kc and c is, if you could explain this I'd be thankful). Are you aware of any methods that work on 3 channel rgb data?
Looks like libraw is not added to linker input
Thank you for the report, will inspect in depth
Some EXIF/Makernotes fields are parsed in LibRaw, some are not.
Exposure time is available via imgdata.other.shutter
imgdata.params.no_auto_bright=1 will, most likely, solve the problem.
Not sure it is possible to set via FreeImage
Most recent Sony cameras uses 'compressed ARW2.3 format' explained in this article: https://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection (scroll to 'Inside sony cRAW format' section)
Yes, 0-16xxx range is correct.
Never had the chance to say thank you for your help.
After talking to a friend, I recently regained interest in using LibRaw for personal R&D purpose. And this is exactly what I needed.
I am going to give it a try soon with some CR2 files from my rather old canon 350D.
There's a GPS datestamp in the spec too; the timestamp (which is "hour, min, sec", not "deg min, sec") is meaningless without the date.
I still suggest the info (altitude in meters, time in HMS) be added to the header file and the API docs. And for a later rev of the library, I suggest the GPS date be added. Until it is, the GPS time is unanchored in reality.
This documentation additions are just a matter of being clear and preventing the user of the library from having to dig all this up on their own, which is really unnecessary, as this stuff is pretty straightforward as long as it is described.
According to EXIF 2.31 specs http://www.cipa.jp/std/documents/e/DC-008-Translation-2016-E.pdf
GPSAltitude:
Indicates the altitude based on the reference in GPSAltitudeRef. Altitude is expressed as one
RATIONAL value. The reference unit is meters.
Yes, .sln-build makes thread safe library.
We know that auto_ptr is deprecated. We'll address this issue in next major change, not in 0.19
That's good to know. The reason why I ask is because at the application level, the file extensions are meaningful for dialog filters.
Thank you for the pointer to the list, that will be useful.
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 info@libraw.org).
Generally, 12 levels below 'relative zero' looks normal, raw histogram will show more details.
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.
Pages