Depending on the offset of the active zone, camera model (obviously), and firmware - useful Bayer patterns can be different. Answering pattern questions, specific to model, firmware, or active zone, makes sense only if there is a bug in the library, and only with a "thank you!".
From LibRaw docs:
unsigned black;
Black level. Depending on the camera, it may be zero (this means that black has been subtracted at the unpacking stage or by the camera itself), calculated at the unpacking stage, read from the RAW file, or hardcoded.
my comment: if only one black level value is found / hardcoded / calculated, it is in this field. Before using it, you may want to check the content of cblack.
More from docs:
unsigned cblack[4102];
Per-channel black level correction. First 4 values are per-channel correction, next two are black level pattern block size, than cblack[4]*cblack[5] correction values (for indexes [6....6+cblack[4]*cblack[5]).
my comment: if 4 (per channel) black level values are found / calculated from sources other than Adobe EXIF tag (with one exception that is irrelevant for the matter at hand), for the camera you are interested in they are read into cblack[0 .. 3] in 0 1 3 2 index order (see code, permutations
FORC4 cblack[c ^ c >> 1] = get2();
do that. That's the way Mr. Coffin did it in dcraw, and we preserved it in LibRaw for compatibility.)
if cblack[0] is 0, and / or cblack[4 .. 5] are present (DNG), you can use cblack [6 .. ...]. You can follow the code under "case 0xc61a" to see the order cblack is populated in this case. For a regular DNG, the cycle in essence is
FORC(cblack[4] * cblack[5]) cblack[6+c] = getreal(type);
meaning, the order coming from Adobe EXIF tag is preserved. Again, preserved from dcraw for compatibility.
The CFA for the K5 is BGGR format (silly me for assuming RGGB). So I think the coefficients in cblack[6-9] are in that order. Is the order for cblack[0-3] RGGB - if so that explains the reversal I see - or am I still confused??
I believe that it tells me the order in the DNG file is RGGB (if I read it right) and this this maps directly into cblack[6-9]. It doesn't confirm the order for cblack[0-3] In fact I'm not even sure now about that order given what I see in the cblack array before and after calling adjust_bl() as per my post on 24 June, 2019 - 15:39 which I repeat the data of here:
(edited to remove flame - ib)
yes I did look at the code, but you could have maybe said something like:
Yes the order is different (or not), as you will see if you compare the processing for DNG black level at case xxxxx and the one for Black Point at case yyyyy
And then pointed me at the DNG spec to add more information. I still don't know for certain that cblack[0-3] is in a different order to cblack[6-9]
Quoting Adobe again, from a previous, "The origin of this pattern is the top-left corner of the ActiveArea rectangle. The values are stored in row-column-sample scan order". How do you interpret this? Please draw two different Bayer patterns and suggest how the tag should be filled based on the description above.
Have you already looked at processing of pertinent EXIF tags under "case 0xc619" and "case 0xc61a"? They simply read the EXIF tags, and thus my reference to Adobe DNG Specification is quite justified. Please read Adobe documentation and try to understand it.
I don't see the reason for your anger, but in any case please refrain from showing it here in future.
You know the purpose of documentation is so other people can read use and understand your stuff. It's no great surprise that you understand it!
You still didn't answer my question about the order of values in cblack[0-3] versus cblack[6-9]. I *think* that it is RGBG for cblack[0-4] and RGGB for cblack[6-9].
Of course if you had deigned to answer my questions in the first place instead of almost going out of your way to avoid doing so - saying along the way "Well I understand it ..." that would have saved me a lot of time which is what this forum is supposed to be about.
Dear Sir:
I don't find the description lacking.
For parsing cblack in DNG and for order used in EXIF tags please see DNG specification: "This tag specifies the zero light ... encoding level, as a repeating pattern. The origin of this pattern is the top-left corner of the ActiveArea rectangle. The values are stored in row-column-sample scan order."
Reading DNG specification may help answering your questions.
For DNG, cblack is filled under "case 0xc619" in parse_tiff_ifd.
Still seeking clarification here ... What order are the first four cblack elements in? RGBG, RGGB?
What order they in for cblack[6]-[9]?
What order are they supposed to be in for the exif tags?
Is there any clear write up explaining the cblack value array other than the code and the rather terse decription in the documentation which doesn't explain much ...?
I understand that you may be feeling "got at" here, but to be fair the OP does have a point in that the code definitely does suffer from a distinct paucity of comments - and while you say the libraw focus is on extracting data from raw files, there's still a very high proportion of the code dedicated to post-processing the raw image.
I truly don't expect you to drop everything and add reams of comments but if the next time you go near any code that lacks comments, adding some lines to explain how/why it's doing what it does would be most helpful to the rest of us.
Please don't put words into my mouth. We put a lot of effort into saving people some time, but we assume that libraw users have a good idea of what raw files are and how to process them, or use our samples, or learn as they go - if they want to implement their own processing but have no experience and theoretical knowledge necessary. Libraw by itself is not meant to be a textbook on raw decoding or raw conversion.
Meanwhile I answered your question right away, pointing out that your problem with magentish highlights here https://imgur.com/F3FjABw are because of how you normalize (denominator) and clip.
"Do your own research like I did mine" is not a good reason to keep large chunks of code absolutely undocumented to the point of inscrutability, mostly not for code that went through a couple of decades and will go through many more. None of us are going to devote 15 years of our lives towards reinventing the wheel and figuring out how you guys did some particular demosaicing algorithm that only you have and works great but doesn't begin to explain what it does and isn't documented anywhere. If you put so much work into researching and making something and shared it you might as well enable people to understand what was done and learn from it rather than telling them to disregard the work you present and to painstakingly retrace your steps or telling them "these large parts of our library are outside of the scope of our library so whatever".
It's not like the parts of the library that are within the core scope of the library are documented either, maybe you're all just too used to dealing with a practically comment-free 21 kLoC file (btw that's at least 20 times too long for a single file) to see what's the problem with that approach. But if you guys aren't interested in documenting 22 years of work beyond telling people how to use it on a basic level then I'm not going to convince you of anything. I'm not telling you you should write an encyclopedia about every function either, and I understand that as a commercial developer you have better things to do than to document an open source project, but a few comments here and there whenever you get the chance to help clarify why things are being done would go a long way, and it might just help you in the future when the meaning of tens of thousands of lines of esoteric code isn't fresh in your mind anymore. It's probably too late for that anyway, most of the people who wrote that stuff have probably long since moved on or forgotten how everything they wrote works.
LibRaw is not about processing, it is about decoding raw and some of the relevant metadata. If you don't want to do your own research it's your choice. I was doing mine for more than 15 years, and still continue to do it.
I'm not sure why you were cryptic about whether my description of what I should do is right, but anyway I tried it and it seems about right, see https://i.imgur.com/gidxryK.png (mine seems to have slightly brighter highlights compared with the rest of the picture, maybe my normalisation is better. I didn't have to do anything after the matrix multiplication btw, I guess the matrix is normalised). I also don't understand why you talk so much about normalisation given that it wasn't relevant to my problem, I didn't have to change anything about normalisation at all, knowing the correct order of operations and knowing to clip (and when) was what was crucial.
I didn't look at sample code, maybe I should have, I just didn't think of doing that because I'd expect such examples to show how to call functions, not how to replicate them, which is what I'm trying to do in my own mostly GPGPU-based way. Instead I debugged through libraw_dcraw_process() to see what it does, and let's just say that it's rather difficult to learn anything doing that given that the 21,420 lines of code in draw_common.cpp are hardly self-documenting, not to mention there are some things with which even the debugger is lost, like accessing the elements of variables (in libraw_cxx.cpp) such as O. or C. or S..
I don't blame you guys for the lack of explanatory comments in the source since I know dcraw was the same way, but while it's good that you documented the API, I think that libraw, as the main successor of dcraw, deserves more because it's so important, your work will outlive you, it's the go-to thing for processing images from any camera, and when we're all dead of old age digital archaeologists will be looking into whatever succeeds libraw to know how to decipher ancient digital photographs, not just how to use it because even now the way it does things shows its age. And so the problems I'm facing they will face too unless the people who understand the code document what it does. Just look at a function like recover_highlights(), I'm sure it does something quite good, but how would anyone know what it does? It doesn't have a single comment explaining what's going on, how is anyone supposed to maintain that? Look at it https://github.com/LibRaw/LibRaw/blob/master/internal/dcraw_common.cpp#L... and see how much you need to use your memory to remember what's the purpose of each of the blocks of loops. Even I am not fond of adding comments, but for blocks of code I'll put a small comment that says what the block of code below does, it just makes everything seem instantly clearer and less daunting.
Let's say someone (e.g. me) thinks "libraw is good, but I want to do most of the processing in floating-point arithmetic in real time OpenCL. I don't want to do original research into every aspect of processing, I just want to do what dcraw/libraw does for every phase of processing", then I need to understand what the code does, not just how to use it. I looked into a couple of the better demosaicing algorithms that libraw provides and it seems like there's literally nothing about at least one of these anywhere on the Internet. Some of them have a few comments, but only in Russian! All we have is the code itself and little to help us understand what it does let alone why it does it. I don't mean to criticise you guys, I really appreciate your hard work and how you guys answer all our questions, we'd have a much harder time without your help, I'm just saying that ideally you should write down what you understand about the code as comments while you still remember what it does. As it is the inner workings of libraw could hardly be more arcane.
I want to characterize my sensor. For that i need raw data but using MATLAB it give only bayer pattern pixel format. The Bayer pattern display three bands/sheets separately in one display but i need one raw image display. So, my question is choosing pixel format BayerRG16 and then displaying image in gray scale is better option?
If not then how i can i get raw images ?
Depending on the offset of the active zone, camera model (obviously), and firmware - useful Bayer patterns can be different. Answering pattern questions, specific to model, firmware, or active zone, makes sense only if there is a bug in the library, and only with a "thank you!".
From LibRaw docs:
unsigned black;
Black level. Depending on the camera, it may be zero (this means that black has been subtracted at the unpacking stage or by the camera itself), calculated at the unpacking stage, read from the RAW file, or hardcoded.
my comment: if only one black level value is found / hardcoded / calculated, it is in this field. Before using it, you may want to check the content of cblack.
More from docs:
unsigned cblack[4102];
Per-channel black level correction. First 4 values are per-channel correction, next two are black level pattern block size, than cblack[4]*cblack[5] correction values (for indexes [6....6+cblack[4]*cblack[5]).
my comment: if 4 (per channel) black level values are found / calculated from sources other than Adobe EXIF tag (with one exception that is irrelevant for the matter at hand), for the camera you are interested in they are read into cblack[0 .. 3] in 0 1 3 2 index order (see code, permutations
FORC4 cblack[c ^ c >> 1] = get2();
do that. That's the way Mr. Coffin did it in dcraw, and we preserved it in LibRaw for compatibility.)
if cblack[0] is 0, and / or cblack[4 .. 5] are present (DNG), you can use cblack [6 .. ...]. You can follow the code under "case 0xc61a" to see the order cblack is populated in this case. For a regular DNG, the cycle in essence is
FORC(cblack[4] * cblack[5]) cblack[6+c] = getreal(type);
meaning, the order coming from Adobe EXIF tag is preserved. Again, preserved from dcraw for compatibility.
Thank you
The CFA for the K5 is BGGR format (silly me for assuming RGGB). So I think the coefficients in cblack[6-9] are in that order. Is the order for cblack[0-3] RGGB - if so that explains the reversal I see - or am I still confused??
I believe that it tells me the order in the DNG file is RGGB (if I read it right) and this this maps directly into cblack[6-9]. It doesn't confirm the order for cblack[0-3] In fact I'm not even sure now about that order given what I see in the cblack array before and after calling adjust_bl() as per my post on 24 June, 2019 - 15:39 which I repeat the data of here:
should I expect the order of cblack[0]-cblack[3] to be the reverse of cblack[6]-cblack[9]???
If I'm not understanding what's going on here please correct my misunderstandings
David
(edited to remove flame - ib)
yes I did look at the code, but you could have maybe said something like:
Yes the order is different (or not), as you will see if you compare the processing for DNG black level at case xxxxx and the one for Black Point at case yyyyy
And then pointed me at the DNG spec to add more information. I still don't know for certain that cblack[0-3] is in a different order to cblack[6-9]
Dear Sir:
Quoting Adobe again, from a previous, "The origin of this pattern is the top-left corner of the ActiveArea rectangle. The values are stored in row-column-sample scan order". How do you interpret this? Please draw two different Bayer patterns and suggest how the tag should be filled based on the description above.
Dear Sir:
Have you already looked at processing of pertinent EXIF tags under "case 0xc619" and "case 0xc61a"? They simply read the EXIF tags, and thus my reference to Adobe DNG Specification is quite justified. Please read Adobe documentation and try to understand it.
I don't see the reason for your anger, but in any case please refrain from showing it here in future.
Well, actually I am asking about the color.cblack array provided by YOU to my application.
Clearly you think you're justified in saying that isn't something you answer questions on.
If I gave answers like that to my customers when I was providing tech support I would have been fired (quite rightly) by my management.
D.
Dear Sir:
In my previous post I quoted Adobe documentation on the matter. I'm afraid you are not paying attention. Your question is about EXIF, not LibRaw.
You know the purpose of documentation is so other people can read use and understand your stuff. It's no great surprise that you understand it!
You still didn't answer my question about the order of values in cblack[0-3] versus cblack[6-9]. I *think* that it is RGBG for cblack[0-4] and RGGB for cblack[6-9].
Of course if you had deigned to answer my questions in the first place instead of almost going out of your way to avoid doing so - saying along the way "Well I understand it ..." that would have saved me a lot of time which is what this forum is supposed to be about.
Dear Sir:
I think the place to ask is https://chdk.fandom.com/wiki/CHDK
PowerShot SX20 IS (CHDK hack)
Please advise what settings to use with CHDK hack, etc. in order for this to work properly.
Thank You!
Dear Sir:
I don't find the description lacking.
For parsing cblack in DNG and for order used in EXIF tags please see DNG specification: "This tag specifies the zero light ... encoding level, as a repeating pattern. The origin of this pattern is the top-left corner of the ActiveArea rectangle. The values are stored in row-column-sample scan order."
Reading DNG specification may help answering your questions.
For DNG, cblack is filled under "case 0xc619" in parse_tiff_ifd.
Still seeking clarification here ... What order are the first four cblack elements in? RGBG, RGGB?
What order they in for cblack[6]-[9]?
What order are they supposed to be in for the exif tags?
Is there any clear write up explaining the cblack value array other than the code and the rather terse decription in the documentation which doesn't explain much ...?
Thanks
I'm now using adjust_bl() before doing my black level subtraction, and I'm seeing:
should I expect the order of cblack[0]-cblack[4] to be the reverse of cblack[7]-cblack[9]???
I'd have expected it to be in the same order as the levels reported by exiftool (513, 513, 515, 516)
> I'd much appreciate some explanation of how cblack really works and how I should process these when operating on the raw image data?
You also didn't address that at all.
However variable black is ZERO and I don't believe it should be
Not 0,
513, 513, 515, 516
I understand that you may be feeling "got at" here, but to be fair the OP does have a point in that the code definitely does suffer from a distinct paucity of comments - and while you say the libraw focus is on extracting data from raw files, there's still a very high proportion of the code dedicated to post-processing the raw image.
I truly don't expect you to drop everything and add reams of comments but if the next time you go near any code that lacks comments, adding some lines to explain how/why it's doing what it does would be most helpful to the rest of us.
Cheers
Well that's a bitch something munged up the code I was requesting a sanity check on.
However it was (it turns out) mostly correct. Though I changed the scale_mul calculation to use dmin instead of dmax.
Cheers
Dear Sir:
Please don't put words into my mouth. We put a lot of effort into saving people some time, but we assume that libraw users have a good idea of what raw files are and how to process them, or use our samples, or learn as they go - if they want to implement their own processing but have no experience and theoretical knowledge necessary. Libraw by itself is not meant to be a textbook on raw decoding or raw conversion.
Meanwhile I answered your question right away, pointing out that your problem with magentish highlights here https://imgur.com/F3FjABw are because of how you normalize (denominator) and clip.
I will leave it at it.
"Do your own research like I did mine" is not a good reason to keep large chunks of code absolutely undocumented to the point of inscrutability, mostly not for code that went through a couple of decades and will go through many more. None of us are going to devote 15 years of our lives towards reinventing the wheel and figuring out how you guys did some particular demosaicing algorithm that only you have and works great but doesn't begin to explain what it does and isn't documented anywhere. If you put so much work into researching and making something and shared it you might as well enable people to understand what was done and learn from it rather than telling them to disregard the work you present and to painstakingly retrace your steps or telling them "these large parts of our library are outside of the scope of our library so whatever".
It's not like the parts of the library that are within the core scope of the library are documented either, maybe you're all just too used to dealing with a practically comment-free 21 kLoC file (btw that's at least 20 times too long for a single file) to see what's the problem with that approach. But if you guys aren't interested in documenting 22 years of work beyond telling people how to use it on a basic level then I'm not going to convince you of anything. I'm not telling you you should write an encyclopedia about every function either, and I understand that as a commercial developer you have better things to do than to document an open source project, but a few comments here and there whenever you get the chance to help clarify why things are being done would go a long way, and it might just help you in the future when the meaning of tens of thousands of lines of esoteric code isn't fresh in your mind anymore. It's probably too late for that anyway, most of the people who wrote that stuff have probably long since moved on or forgotten how everything they wrote works.
LibRaw is not about processing, it is about decoding raw and some of the relevant metadata. If you don't want to do your own research it's your choice. I was doing mine for more than 15 years, and still continue to do it.
I'm not sure why you were cryptic about whether my description of what I should do is right, but anyway I tried it and it seems about right, see https://i.imgur.com/gidxryK.png (mine seems to have slightly brighter highlights compared with the rest of the picture, maybe my normalisation is better. I didn't have to do anything after the matrix multiplication btw, I guess the matrix is normalised). I also don't understand why you talk so much about normalisation given that it wasn't relevant to my problem, I didn't have to change anything about normalisation at all, knowing the correct order of operations and knowing to clip (and when) was what was crucial.
I didn't look at sample code, maybe I should have, I just didn't think of doing that because I'd expect such examples to show how to call functions, not how to replicate them, which is what I'm trying to do in my own mostly GPGPU-based way. Instead I debugged through libraw_dcraw_process() to see what it does, and let's just say that it's rather difficult to learn anything doing that given that the 21,420 lines of code in draw_common.cpp are hardly self-documenting, not to mention there are some things with which even the debugger is lost, like accessing the elements of variables (in libraw_cxx.cpp) such as
O.orC.orS..I don't blame you guys for the lack of explanatory comments in the source since I know dcraw was the same way, but while it's good that you documented the API, I think that libraw, as the main successor of dcraw, deserves more because it's so important, your work will outlive you, it's the go-to thing for processing images from any camera, and when we're all dead of old age digital archaeologists will be looking into whatever succeeds libraw to know how to decipher ancient digital photographs, not just how to use it because even now the way it does things shows its age. And so the problems I'm facing they will face too unless the people who understand the code document what it does. Just look at a function like recover_highlights(), I'm sure it does something quite good, but how would anyone know what it does? It doesn't have a single comment explaining what's going on, how is anyone supposed to maintain that? Look at it https://github.com/LibRaw/LibRaw/blob/master/internal/dcraw_common.cpp#L... and see how much you need to use your memory to remember what's the purpose of each of the blocks of loops. Even I am not fond of adding comments, but for blocks of code I'll put a small comment that says what the block of code below does, it just makes everything seem instantly clearer and less daunting.
Let's say someone (e.g. me) thinks "libraw is good, but I want to do most of the processing in floating-point arithmetic in real time OpenCL. I don't want to do original research into every aspect of processing, I just want to do what dcraw/libraw does for every phase of processing", then I need to understand what the code does, not just how to use it. I looked into a couple of the better demosaicing algorithms that libraw provides and it seems like there's literally nothing about at least one of these anywhere on the Internet. Some of them have a few comments, but only in Russian! All we have is the code itself and little to help us understand what it does let alone why it does it. I don't mean to criticise you guys, I really appreciate your hard work and how you guys answer all our questions, we'd have a much harder time without your help, I'm just saying that ideally you should write down what you understand about the code as comments while you still remember what it does. As it is the inner workings of libraw could hardly be more arcane.
I want to characterize my sensor. For that i need raw data but using MATLAB it give only bayer pattern pixel format. The Bayer pattern display three bands/sheets separately in one display but i need one raw image display. So, my question is choosing pixel format BayerRG16 and then displaying image in gray scale is better option?
If not then how i can i get raw images ?
Pages