Almost every camera employs anti-aliasing; that'd seem to =>approximately<= result in DNGs with one-quarter the effective pixel count, and color artifacts possibly(!) eliminated or greatly reduced—since that is of course the REASON for AA.
Gaussian blur should give a weak approximation of AA. For example, light falling on the top-left (Red) pixel wouldn't be shared with its upper and leftwards neighbors under AA; it'd all go to green & blue pixels that're right and down (in the common arrangement) from the Red.
But Gaussian blur would send a fraction of its light to all 8 Green + Blue neighbors, while reducing the light attributed to the original Red pixel. In that sense, there could be excessive fuzzing of the artificial image versus what a perfect lens + AA filter would produce.
some camera records four multipliers, while some (RGB/3 color) may use only three. In the second case, the cam_mul[1] (Green) should be copied to cam_mul[3] ('second green')
After that, cam_mul[] is usually normalized (i.e. divided to smallest value, so [1500,1000,1200,1000] will become [1.5,1,1.2,1])
And, yes, then color channels are multiplied to cam_mul[color] values.
unfortunately, we could not help. LibRaw Python bindings (rawpy) is not our product, so we completely do not know what is 'black_level_per_channel' vector (and other variables you mentioned)
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.
Could you please provide more detailed bracktrace to see what line in LibRaw constructor caused that?
I do not see any incorrect code in quoted line. Could you please provide some additional data (e.g. stacktrace?)
HEIC is not raw format, but processed image format (similar to JPEG)
Almost every camera employs anti-aliasing; that'd seem to =>approximately<= result in DNGs with one-quarter the effective pixel count, and color artifacts possibly(!) eliminated or greatly reduced—since that is of course the REASON for AA.
Gaussian blur should give a weak approximation of AA. For example, light falling on the top-left (Red) pixel wouldn't be shared with its upper and leftwards neighbors under AA; it'd all go to green & blue pixels that're right and down (in the common arrangement) from the Red.
But Gaussian blur would send a fraction of its light to all 8 Green + Blue neighbors, while reducing the light attributed to the original Red pixel. In that sense, there could be excessive fuzzing of the artificial image versus what a perfect lens + AA filter would produce.
(Happy to be corrected on this, btw)
some camera records four multipliers, while some (RGB/3 color) may use only three. In the second case, the cam_mul[1] (Green) should be copied to cam_mul[3] ('second green')
After that, cam_mul[] is usually normalized (i.e. divided to smallest value, so [1500,1000,1200,1000] will become [1.5,1,1.2,1])
And, yes, then color channels are multiplied to cam_mul[color] values.
Dear Sir,
unfortunately, we could not help. LibRaw Python bindings (rawpy) is not our product, so we completely do not know what is 'black_level_per_channel' vector (and other variables you mentioned)
LibRaw does not saves RAW files (inc. DNG), consider Adobe DNG SDK for that.
Here is the patch for 2000D/4000D: https://www.dropbox.com/s/erxiu7f63c4qao9/2000d.patch?dl=0
clipping is necessary to avoid 'pink clouds' problem
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.
Pages