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?
Sorry, missed these notices because of *very long* reply:
>> Also properties such as gimbal pitch, yaw, roll among others are removed.
>>Should I give you a copy of this image to take a look at the fields that are removed?
LibRaw::write_tiff_ppm() used in dcraw_emu creates very minimal set of EXIF tags.
There is no plans to extend this.
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
There is no such program in LibRaw 'sample code' programs.
One could implement such program using LibRaw or Adobe DNG sdk for raw (dng) decode and something like libtiff for tiff write.
Apologies for the long response.
Do you have a program that can just convert the dng file to tiff without changing any of the dng's exif metadata?
Sorry, missed these notices because of *very long* reply:
>> Also properties such as gimbal pitch, yaw, roll among others are removed.
>>Should I give you a copy of this image to take a look at the fields that are removed?
LibRaw::write_tiff_ppm() used in dcraw_emu creates very minimal set of EXIF tags.
There is no plans to extend this.
I just downloaded the sample image and the exif file; I ran the test and still get the same errors when I try to load the .tiff file.
I ran a exiftool -v and there were some warnings
[Warning = ValueConv GPSTimeStamp: Argument "undef" isn't numeric in addition (+)]
There's no such errors in the raw file
Here are tiff file produced by dcraw_emu -T (from github/LibRaw/master branch) and result of exiftool -v3 tiff-file: https://www.dropbox.com/sh/6q9d3hd10z8x06m/AAA7QgHY9yf_KFK38JmZ5WF9a?dl=0
There are no tags 0xa40.. in this file.
apologies about the output, I sent a sample DNG file through the contact link.
I am still getting errors when trying to open the .tiff files
I am using colmap; which uses freeimage to import supported files. DNG files are unsupported but TIFF's are.
I think those unknown() values trips up freeimage.
Pages