Please don't drop Fujitsu Super-CCD support, if that's done, people who use my software won't be able to reprocess old images (which the astrophotography folks often do).
I'll take a look at raw2image_ex() to see I can understand it.
It's great that you get it from the CR2 file, but you didn't answer my question - does it represent the "white level" or not? And as an aside is it normal to see pixel values > that level?
I am checking the libraw open_file() and unpack() return codes - what warning field are you referring to? I looked the possible values for imgdata.process_warnings but none of those suggest a "camera not supported" condition.
Looking at the errors that are potentially returned (apart from LIBRAW_FILE_UNSUPPORTED which might be returned for a Canon .CR3 file until you add that support), I still don't see anything to tell me a camera isn't supported.
process_warnings - none of those conditions appear to tell me that a camera isn't supported, or should I interpret any value in process_warnings to indicate that the camera isn't supported?
black level data in LibRaw (and dcraw) is split into several pieces
color.black - 'base' black level (common for all channels)
color.cblack[0..3] - per channel level
color.cblack[6...] - pattern level for cblack[4] x cblack[5] pattern.
I did not understand your comments regarding white balance.
BTW, if you want to *only* replace de-bayer with your own code, but do not want to know other raw processing details (black level/bias, white balance, scaling, color profiles, etc, etc, etc)
than you may provide your own demosaic via callbacks.interpolate_bayer_cb
Your callback will be called instead pre-defined demosaic(s) built-in in LibRaw, while other processing steps will be called in sequence.
You may use LibRaw::lin_interpolate() code as an example.
Yes, I can read the code well enough to understand the basics of what scale_colors does to the de-Bayered 4 colour image array. My problem is to understand the code well enough to perform a "correct" transform on the raw_image array. As an example, it really is not clear what the gory details of the six component cblack array processing are - IOW why you don't/can't just subtract the basic black level and what the algorithm being used is precisely and so on. I'm sure that Dave Coffin and you are real experts on image processing, and fully understand the code and algorithms without needing lots of comments to understand the code in detail - we mere mortals struggle to grok such dense and relatively uncommented code.
Without that information I can only apply a trivial subtraction of the basic black level value from all the raw_image values and then scale linearly from 0- 65535! Clearly I cannot do any white balance calculation on the raw image as that requires that the data is already converted to 4 component RGB (does that mean it is LRGB?), and that I have access to the camera white balance data (unless doing "auto wb").
This is not about add-on library, but about data.
To replicate in-camera rendering you need to use:
a) same color profile (as used by camera firmware)
b) same exposure (midtone) compensation
c) same contrast curve
AFAIK, such data is not published by vendors. Generally, it is possible to measure this data using test shots (separate measure for each camera you want to support).
Document mode is not supported in our dcraw processing emulation (dcraw_process() call) because it makes things too complex.
Our unprocessed_raw.cpp and 4channels.cpp samples provides unprocessed raw data output (for bayer case), that is enough for most practical cases. It is also good starting point(s) for ones who want only unprocessed raw data access and do full processing.
Black subtraction: if LibRaw docs covering imgdata.color.black/imgdata.color.cblack[] is not enough, you may use LibRaw::subtract_black() source as an example. It operates with imgdata.image[] array, assuming that rawdata.raw_image[] values are already in place.
Also, LibRaw::raw2image_ex() do raw_image=>image population and black subtraction in single step.
AFAICT using the -4 flag means gamma coefficients both set to 1. So I *think* that means that gamma correction should make no changes. Is that correct?
Certainly -d and -D give quite different results - d is quite a bit brighter than the -D version - would that fit with black subtraction processing? Where in the code would I find the black subtraction (so I can do that processing myself on the RAW data?
Is it out of order to ask why the document mode code was removed?
Just to be sure, can you confirm that the code at line 2783 in libraw_cxx.cpp is the relevant code?
Thanks
Please don't drop Fujitsu Super-CCD support, if that's done, people who use my software won't be able to reprocess old images (which the astrophotography folks often do).
I'll take a look at raw2image_ex() to see I can understand it.
Dave
Yes, Fuji Super-CCD is completely different.
Look into raw2image_ex() source for details.
BTW, today, in 2019, it is good enough idea to drop Super-CCD support.
AFAIK, this is vendor-specified value for white point.
It's great that you get it from the CR2 file, but you didn't answer my question - does it represent the "white level" or not? And as an aside is it normal to see pixel values > that level?
For Canon cameras, imgdata.color.maximum is set by metadata provided by vendor in CR2 file.
Not doing so results in 'pink highlights' problem.
By default, LibRaw *uses* DNG color matrix, quote from docs:
1 (default): use embedded color profile (if present) for DNG files (always); for other files only if use_camera_wb is set;
RawDigger settings are different:
0 for 'built-int color profile'
3 for 'Embedded in RAW'
Thanks for your response!
Yes, I thought RawDigger used LibRaw.
I set no_auto_bright = 0, and it didn't really change the result. The LibRaw output is still much darker than the RawDigger output.
Are there any other settings I should be changing in LibRaw?
(Again, I suspect LibRaw is not using the DNG color matrix, but I'm not sure...)
This is (list of) 'surely supported' (tested) ones.
UPD: published 'just for information', LibRaw does not use this list internally.
Come on - you know what the word supported means as do I - after all you publish as list of supported cameras!
Could you please define 'supported' ?
I am checking the libraw open_file() and unpack() return codes - what warning field are you referring to? I looked the possible values for imgdata.process_warnings but none of those suggest a "camera not supported" condition.
Looking at the errors that are potentially returned (apart from LIBRAW_FILE_UNSUPPORTED which might be returned for a Canon .CR3 file until you add that support), I still don't see anything to tell me a camera isn't supported.
Thanks
process_warnings - none of those conditions appear to tell me that a camera isn't supported, or should I interpret any value in process_warnings to indicate that the camera isn't supported?
https://www.libraw.org/docs/API-datastruct.html#datastruct :
unsigned int process_warnings;
There is no such call.
Check open_file/unpack return code(s) and/or warning field.
black level data in LibRaw (and dcraw) is split into several pieces
color.black - 'base' black level (common for all channels)
color.cblack[0..3] - per channel level
color.cblack[6...] - pattern level for cblack[4] x cblack[5] pattern.
I did not understand your comments regarding white balance.
BTW, if you want to *only* replace de-bayer with your own code, but do not want to know other raw processing details (black level/bias, white balance, scaling, color profiles, etc, etc, etc)
than you may provide your own demosaic via callbacks.interpolate_bayer_cb
Your callback will be called instead pre-defined demosaic(s) built-in in LibRaw, while other processing steps will be called in sequence.
You may use LibRaw::lin_interpolate() code as an example.
Yes, I can read the code well enough to understand the basics of what scale_colors does to the de-Bayered 4 colour image array. My problem is to understand the code well enough to perform a "correct" transform on the raw_image array. As an example, it really is not clear what the gory details of the six component cblack array processing are - IOW why you don't/can't just subtract the basic black level and what the algorithm being used is precisely and so on. I'm sure that Dave Coffin and you are real experts on image processing, and fully understand the code and algorithms without needing lots of comments to understand the code in detail - we mere mortals struggle to grok such dense and relatively uncommented code.
Without that information I can only apply a trivial subtraction of the basic black level value from all the raw_image values and then scale linearly from 0- 65535! Clearly I cannot do any white balance calculation on the raw image as that requires that the data is already converted to 4 component RGB (does that mean it is LRGB?), and that I have access to the camera white balance data (unless doing "auto wb").
Regards
This is not about add-on library, but about data.
To replicate in-camera rendering you need to use:
a) same color profile (as used by camera firmware)
b) same exposure (midtone) compensation
c) same contrast curve
AFAIK, such data is not published by vendors. Generally, it is possible to measure this data using test shots (separate measure for each camera you want to support).
scale_colors():
1) subtracts black
2)applies white balance
3) scales values to 0...65535 range
1) RawDigger uses LibRaw postprocessing code
2) RawDigger's default is no_auto_bright = 0
Can you recommend any add-on libraw library, which can make better replication of JPEG?
Thank you! A very helpful couple of posts
BTW, I've already mentioned copy_bayer() call in previous reply: https://www.libraw.org/comment/5246#comment-5246
Document mode is not supported in our dcraw processing emulation (dcraw_process() call) because it makes things too complex.
Our unprocessed_raw.cpp and 4channels.cpp samples provides unprocessed raw data output (for bayer case), that is enough for most practical cases. It is also good starting point(s) for ones who want only unprocessed raw data access and do full processing.
Black subtraction: if LibRaw docs covering imgdata.color.black/imgdata.color.cblack[] is not enough, you may use LibRaw::subtract_black() source as an example. It operates with imgdata.image[] array, assuming that rawdata.raw_image[] values are already in place.
Also, LibRaw::raw2image_ex() do raw_image=>image population and black subtraction in single step.
AFAICT using the -4 flag means gamma coefficients both set to 1. So I *think* that means that gamma correction should make no changes. Is that correct?
Certainly -d and -D give quite different results - d is quite a bit brighter than the -D version - would that fit with black subtraction processing? Where in the code would I find the black subtraction (so I can do that processing myself on the RAW data?
Is it out of order to ask why the document mode code was removed?
Thanks again
Pages