It gets worse - some .CR2 images from the camera come back with filters set to 0x00000000 so they are interpreted as full colour images not CFA so I can't extract the non-deBayered image data and de-Bayer it myself.
Please could you explain why you felt the need to override the margins as you do here. I understand that this impacts on the code for determing a pixels colour depending on whether you are looking at the full sensor area as compared to the active area - but why is that a problem?
The previous code respected the margins set by the manufacturer whereas you are changing the margins which has a massive impact on this application as previously processed master darks, flats etc will no longer be compatible - this is disastrous as users do not always retain all their original darks, etc. so won't be able to rebuild them.
Sure I could modify open.cpp but that becomes a perpetual problem as we would need to remember to change it every time we refreshed the LibRaw code.
Please, please give a lot of thought to reverting this to previous behaviour - this really is a HUGE compatibility issue.
Libraw 0.20 identifies the pattern for a Canon EOS 60D as GBRG, whereas 0.19 identified it as RGGB. It seems highly probable to me that this doesn't just apply to the EOS 60D.
This is not some 'position', this is the reality.
It is difficult to unequivocally define what a "camera is supported" is.
That's why we are not trying to give an API for this
OK If that's your position, I guess I have to accept it (even if I don't greatly like it). However, in that case what is your proposed mechanism to determine if a given camera is supported?
The reason I use the camera list is that unless you tell me otherwise, it is the only mechanism that allows me to check whether a camera is definitely supported - if it IS in the list, it should work, and if it isn't in the list, it might work, or might fail spectacularly.
1. The list is simply to list the supported cameras, for the users to know. The list is guaranteed not to include all the cameras that are actually supported, only those which we were able to test and only the known aliases - such as camera phones which we were not able to test are not listed, even if the output is in DNG format.
2. There are no plans to make a machine-readable list, not for make/models, not for normalized make/models.
3. The intended use of normalized make/model parameters is explained in the Changelog.txt under "== Normalized make/model =="
4. Using normalized make/model parameter while searching in the camera list may be of some help, albeit very little of it.
apply_profile.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
I'm compiling the RC2 code with VS2017, and /W3. I'm getting a lot of warnings like these:
1>c:\users\amonra\documents\github\dss\libraw\src\demosaic\dht_demosaic.cpp(176): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\amonra\documents\github\dss\libraw\src\demosaic\dht_demosaic.cpp(747): warning C4305: '/=': truncation from 'double' to 'float'
Yes, of course I can disable these warnings, but I'd like to be sure it's OK do that?
Thanks for the update Alex and all the work you and the LibRaw team do! If you need samples just let me know I currently have two files I could provide. I look forward to an upcoming release with the lossy support added.
Hi Iliah,
Thanks for the pointers. I do have an understanding of color science. Its just that with dcraw having multiple properties that describe very similar things, I was just trying to ensure I was using the right ones.
You can start here: what does cam_xyz represent, what kind of colour transform, what is it applied to, and what's the result? Before you know the answer the life will be not easy. Put it another way, if you are dealing with colour, it's only logical to start with a bit of study of colour engineering, and not to rely on guessing from the code or trial and error.
Alex,
Please forgive me if I gave the impression that I am trying to replicate DCRAW/libraw.
I am creating my own RAW processing pipeline but I am relying on libraw to read the CFA and metadata for the color transformation to implement this pipeline.
Due to the lack of documentation, I am just trying to understand how these coefficients work or are meant to be used to make sure I am implementing my pipeline correctly.
For example, for the Google Pixel 3 camera, I had to derive the cam_xyz from rgb_cam. However, the resulting matrix resulted in a strong color cast probably because I did not undo the normalization after doing INV(rgb_cam).
Also, I assumed that cam_mul would be sufficient because they are the as shot WB multipliers but pre_mul appears to be needed because of the cam_rgb normalization.
Alex,
I noticed that during the computation of rgb_cam from cam_xyz in the cam_xyz_coeff function, there is a normalization that is applied when cam_rgb is computed and the pre_mul is updated. The annotated DCRAW site also does not provide much explanation about this.
The author's comment is "But I don’t fully understand what this tiny little section of code really does. I’d love to hear from someone who can explain it to me."
Given this I have some questions:
1. For camera's (like Google Pixel 3 above), where cam_xyz has to be derived from cmatrix (or rgb_cam) and xyz_rgb, how can I undo the normalization when calculating cam_xyz?
2. During cam_rgb normalization, the pre_mul is updated. So, I assume that the coeffs in pre_mul need to be applied to the RAW data before demosaicing and applying rgb_cam to convert from Camera Space -> sRGB?
It gets worse - some .CR2 images from the camera come back with filters set to 0x00000000 so they are interpreted as full colour images not CFA so I can't extract the non-deBayered image data and de-Bayer it myself.
Please could you explain why you felt the need to override the margins as you do here. I understand that this impacts on the code for determing a pixels colour depending on whether you are looking at the full sensor area as compared to the active area - but why is that a problem?
The previous code respected the margins set by the manufacturer whereas you are changing the margins which has a massive impact on this application as previously processed master darks, flats etc will no longer be compatible - this is disastrous as users do not always retain all their original darks, etc. so won't be able to rebuild them.
Sure I could modify open.cpp but that becomes a perpetual problem as we would need to remember to change it every time we refreshed the LibRaw code.
Please, please give a lot of thought to reverting this to previous behaviour - this really is a HUGE compatibility issue.
David
I understand your pain.
As stated in Changelog:
* Bayer images: ensure that even margins have the same COLOR() for both the active sensor area and the full sensor area.
The only way to achieve this is to ensure that left/top margins are even for bayer images and multiply of 6 for X-Trans images.
Please note, that margins can also change due to firmware update (if margins are read from file metadata).
So, the only way to ensure valid darks, master flats, etc etc is to use full sensor area, not active (visible) area for such data.
You may be pleased to know that very few cameras are affected by this change.
Also you may rollback this change by commenting out these lines in src/utils/open.cpp: https://github.com/LibRaw/LibRaw/blob/master/src/utils/open.cpp#L618-L640
This will not preserve from margins change due to firmware update.
Libraw 0.20 identifies the pattern for a Canon EOS 60D as GBRG, whereas 0.19 identified it as RGGB. It seems highly probable to me that this doesn't just apply to the EOS 60D.
The image processes incorrectly as a result :(
Hi all, got the message in DeepSkyStacker saying "sorry, LibRaw doesn't support your Sony ILCE-7RM2".
It's in the list above, but listed as A7R II. There any way around this?
This is not some 'position', this is the reality.
It is difficult to unequivocally define what a "camera is supported" is.
That's why we are not trying to give an API for this
OK If that's your position, I guess I have to accept it (even if I don't greatly like it). However, in that case what is your proposed mechanism to determine if a given camera is supported?
The reason I use the camera list is that unless you tell me otherwise, it is the only mechanism that allows me to check whether a camera is definitely supported - if it IS in the list, it should work, and if it isn't in the list, it might work, or might fail spectacularly.
Dear Sir:
1. The list is simply to list the supported cameras, for the users to know. The list is guaranteed not to include all the cameras that are actually supported, only those which we were able to test and only the known aliases - such as camera phones which we were not able to test are not listed, even if the output is in DNG format.
2. There are no plans to make a machine-readable list, not for make/models, not for normalized make/models.
3. The intended use of normalized make/model parameters is explained in the Changelog.txt under "== Normalized make/model =="
4. Using normalized make/model parameter while searching in the camera list may be of some help, albeit very little of it.
So what is the intended use of this list if not that?
David
You can try, but since this list is not intended for the use described above, we do not have an answer to this question.
My old code used imgdata.idata.make and imgdata.idata.model to compare against the compiled in list of supported cameras.
Should I now change that code to use imgdata.idata.normalized_make and imgdata.idata.normalized_model ?
Thanks
apply_profile.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
Is this to be expected?
I'm compiling the RC2 code with VS2017, and /W3. I'm getting a lot of warnings like these:
1>c:\users\amonra\documents\github\dss\libraw\src\demosaic\dht_demosaic.cpp(176): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\amonra\documents\github\dss\libraw\src\demosaic\dht_demosaic.cpp(747): warning C4305: '/=': truncation from 'double' to 'float'
Yes, of course I can disable these warnings, but I'd like to be sure it's OK do that?
Thanks
David
Yes, samples are welcome (although we have several ones).
If you do not want to share it in public, use WeTransfer service/free option and send samples to info@libraw.org.
Thanks for the update Alex and all the work you and the LibRaw team do! If you need samples just let me know I currently have two files I could provide. I look forward to an upcoming release with the lossy support added.
Hi Iliah,
Thanks for the pointers. I do have an understanding of color science. Its just that with dcraw having multiple properties that describe very similar things, I was just trying to ensure I was using the right ones.
Regards,
Dinesh
X-T4
losslesslossy compressed files are not supported for LibRaw yet.UPD: correction, lossless files are supported, lossy are not.
You can start here: what does cam_xyz represent, what kind of colour transform, what is it applied to, and what's the result? Before you know the answer the life will be not easy. Put it another way, if you are dealing with colour, it's only logical to start with a bit of study of colour engineering, and not to rely on guessing from the code or trial and error.
Libraw binary distribution for Mac is built using unedited Makefile.dist
make -f Makefile.dist worked on Intel and ARM. I merged both libs with lipo.
Should I change any settings in the Makefile from the default?
We do not have ARM mac hardware, so unable to test. I do not think we'll have it in very nearest future.
You need to rebuild LibRaw by yourself, use Makefile.dist as a starting point.
Hi,
I work currently on the port of my app for macOS 11 on ARM/Intel.
When will be a Universal Binary available?
Thorsten
pre_mul is not used for normalization. It derived from cam_rgb data (to get daylight wb coeffs)
Alex,
Please forgive me if I gave the impression that I am trying to replicate DCRAW/libraw.
I am creating my own RAW processing pipeline but I am relying on libraw to read the CFA and metadata for the color transformation to implement this pipeline.
Due to the lack of documentation, I am just trying to understand how these coefficients work or are meant to be used to make sure I am implementing my pipeline correctly.
For example, for the Google Pixel 3 camera, I had to derive the cam_xyz from rgb_cam. However, the resulting matrix resulted in a strong color cast probably because I did not undo the normalization after doing INV(rgb_cam).
Also, I assumed that cam_mul would be sufficient because they are the as shot WB multipliers but pre_mul appears to be needed because of the cam_rgb normalization.
I am just looking for more information on these.
Thanks for all your help thus far!
Dinesh
As far as I understood from the previous discussion, you're creating your own postprocessing for RAW.
I do not thing you need to replicate LibRaw/dcraw color processing pipeline.
Alex,
I noticed that during the computation of rgb_cam from cam_xyz in the cam_xyz_coeff function, there is a normalization that is applied when cam_rgb is computed and the pre_mul is updated. The annotated DCRAW site also does not provide much explanation about this.
The author's comment is "But I don’t fully understand what this tiny little section of code really does. I’d love to hear from someone who can explain it to me."
Given this I have some questions:
1. For camera's (like Google Pixel 3 above), where cam_xyz has to be derived from cmatrix (or rgb_cam) and xyz_rgb, how can I undo the normalization when calculating cam_xyz?
2. During cam_rgb normalization, the pre_mul is updated. So, I assume that the coeffs in pre_mul need to be applied to the RAW data before demosaicing and applying rgb_cam to convert from Camera Space -> sRGB?
3. When should I use cam_mul then?
Dinesh
Pages