Sorry if I wasn't clear on this - by correct scale I mean every image is scaled by the same factor so that 1 pixel intensity measures the same amount of physical light energy for all images.
After doing some research I found each file has a different value for "baseline exposure", and to convert them back to the same scale one needs to apply following correction:
Thank you so much for the quick reply. When I opened both files in photoshop and the preview app they were shown in the correct scale. Is there any way I can fetch that information from the DNG with libraw?
Thank you all for the answers. I read the binary with native C++ fstream (800x800 = 640000 values). then used __builtin_bswap16() to swap and obtain my bayer data which I was able to convert to RGB,
Many thanks
For byte swapping use something like ntohs() (actually this converts from big endian to your machine/host endianness, so it might be a noop if your machine is big endian as well) or, depending on your system/compiler, some incarnation of the bswap16() intrinsic/bultin function (e.g. __builtin_bswap16() for GCC, _byteswap_ushort() for MSVC, etc.)
Thank you again for your answers.
Actually, yes the data is encoded in int16.
I was able to read it in python swap bit ordering to bi endian. Any idea how I can achieve this in c++ ?
Also my guess for taking 2 bites with go for two consecutive bytes. Does this seam reasonable. I don' have all format specifications in hand.
Also, if your file is 2 bytes per pixel, uncompressed, you do not need LibRaw to read source data values. Your values are already here (in unsigned short format, probably you may need big/little-endian swap; I know nothing about your images and your camera)
Thank you Alex for your answer. I tried with open_bayer as I think the raw file has no metadata. With the code bellow I could see that readb as 1280000 values instead of 640000 for an image 800x8000. The final result with dcraw_process is not satisfactory. I wonder If and how I could retrieve the unpacked values and do the conversion myself.
FILE *in = fopen(fname, "rb");
fseek(in, 0, SEEK_END);
unsigned fsz = ftell(in);
unsigned char *buffer = (unsigned char *)malloc(fsz);
if (!buffer)
return 2;
fseek(in, 0, SEEK_SET);
unsigned readb = fread(buffer, 1, fsz, in);
if (readb != fsz)
return 3;
std::cout << "readb" << readb << std::endl;
LibRaw rp;
rp.imgdata.params.output_tiff = 1;
int ret = rp.open_bayer(buffer, fsz, 800, 800, 0, 0, 0, 0, 0,
LIBRAW_OPENBAYER_BGGR, 0, 0, 0);
if (ret != LIBRAW_SUCCESS)
return 4;
if ((ret = rp.unpack()) != LIBRAW_SUCCESS)
printf("Unpack error: %d\n", ret);
if ((ret = rp.dcraw_process()) != LIBRAW_SUCCESS)
printf("Processing error: %d\n", ret);
char outfn[256];
sprintf(outfn, "%s.tif", fname);
if (LIBRAW_SUCCESS != (ret = rp.dcraw_ppm_tiff_writer(outfn)))
printf("Cannot write %s: %s\n", outfn, libraw_strerror(ret));
else
printf("Created %s\n", outfn);
ret = rp.dcraw_process();
// Check for error using LIBRAW_SUCCESS. I never get an error here
ret = rp.dcraw_ppm_tiff_writer(fname);
Microsoft RAW extension is produced by Microsoft, we're not involved in this process in any way (Microsoft uses the public version of LibRaw).
So, we're completely not responsible for MS RAW Extension.
I have the exact same issue with A7VI RAWs and the Microsoft RAW extension.
I figured out it's related to the new Sony lossless compressed RAW format.
A7IV compress or uncompressed RAW are displayed fine, but A7IV lossless compress RAWs are not displayed at all.
The LibRAW blog post from 22. Oct. 2021 says the new Sony losslesss compressed RAW format is now supported.
My guess would be Microsoft RAW extension includes a version that is too old.
OM-1 supported by this latest patch: https://github.com/LibRaw/LibRaw/commit/adcb898a00746c8aa886eb06cc9f5a1c...
baseline exposure tag for DNG is parsed into imgdata.color.dng_levels.baseline_exposure (and also into tiff_ifds[ifd].dng_levels.....)
Sorry if I wasn't clear on this - by correct scale I mean every image is scaled by the same factor so that 1 pixel intensity measures the same amount of physical light energy for all images.
After doing some research I found each file has a different value for "baseline exposure", and to convert them back to the same scale one needs to apply following correction:
intensity = raw_intensity * (2^ baseline_exposure)
After this conversion intensities are now consistent across images.
I still have a few questions though:
- Does libraw expose "baseline_exposure" through API?
- I think above correction should be applied to post processed image, is that correct?
Cheers
I did not quite understand what is meant by the 'correct scale' in this context.
DNG tag 0xc61d values are extracted into
1) imgdata.color.maximum (for channel 0)
2) imgdata.color.dng_levels.dng_whitelevel[channel] (for selected DNG ifd)
3) tiff_ifd[ifd].dng_levels.dng_whitelevel[channel] (all IFDs)
Hi Alex,
Thank you so much for the quick reply. When I opened both files in photoshop and the preview app they were shown in the correct scale. Is there any way I can fetch that information from the DNG with libraw?
Cheers
Zac
Your DNG files have data range of 65535:
Tag 0xc61d:
| | 15) WhiteLevel = 65535 65535 65535
So, 65535 is an expected data range even without scaling.
There is no need to modify Makefile.msvc for 64-bit.
Just run nmake in corresponding (32 or 64 bit) Developer Shell (or use vcvarsNN.bat to set up environment variables)
We also provide LibRaw.sln (one may need to change tools version to Visual Studio used)
Already in github/master: https://github.com/LibRaw/LibRaw/commit/adcb898a00746c8aa886eb06cc9f5a1c...
Could we have support for OM-1 OM System (Olympus) soon?
Thank you! :) I get matching values after updating libraw to the current git master.
A7C (ILCE-7C) is not officially supported by 0.20.2, consider upgrade to current 'public snapshot' from github: https://github.com/LibRaw/LibRaw
0.20.2.
There is now more info on darktable's side: https://github.com/darktable-org/rawspeed/pull/250#issuecomment-1077723895
What version of LibRaw do you use?
Thank you all for the answers. I read the binary with native C++ fstream (800x800 = 640000 values). then used __builtin_bswap16() to swap and obtain my bayer data which I was able to convert to RGB,
Many thanks
procflags of open_bayer() should also do the swap for you in the above example: https://www.libraw.org/docs/API-CXX.html#open_bayer
For byte swapping use something like ntohs() (actually this converts from big endian to your machine/host endianness, so it might be a noop if your machine is big endian as well) or, depending on your system/compiler, some incarnation of the bswap16() intrinsic/bultin function (e.g. __builtin_bswap16() for GCC, _byteswap_ushort() for MSVC, etc.)
Thank you again for your answers.
Actually, yes the data is encoded in int16.
I was able to read it in python swap bit ordering to bi endian. Any idea how I can achieve this in c++ ?
Also my guess for taking 2 bites with go for two consecutive bytes. Does this seam reasonable. I don' have all format specifications in hand.
Also, if your file is 2 bytes per pixel, uncompressed, you do not need LibRaw to read source data values. Your values are already here (in unsigned short format, probably you may need big/little-endian swap; I know nothing about your images and your camera)
If your input data is 16 bit (2 bytes per pixel), 1,280,000 bytes is expected....
Thank you Alex for your answer. I tried with open_bayer as I think the raw file has no metadata. With the code bellow I could see that readb as 1280000 values instead of 640000 for an image 800x8000. The final result with dcraw_process is not satisfactory. I wonder If and how I could retrieve the unpacked values and do the conversion myself.
FILE *in = fopen(fname, "rb"); fseek(in, 0, SEEK_END); unsigned fsz = ftell(in); unsigned char *buffer = (unsigned char *)malloc(fsz); if (!buffer) return 2; fseek(in, 0, SEEK_SET); unsigned readb = fread(buffer, 1, fsz, in); if (readb != fsz) return 3; std::cout << "readb" << readb << std::endl; LibRaw rp; rp.imgdata.params.output_tiff = 1; int ret = rp.open_bayer(buffer, fsz, 800, 800, 0, 0, 0, 0, 0, LIBRAW_OPENBAYER_BGGR, 0, 0, 0); if (ret != LIBRAW_SUCCESS) return 4; if ((ret = rp.unpack()) != LIBRAW_SUCCESS) printf("Unpack error: %d\n", ret); if ((ret = rp.dcraw_process()) != LIBRAW_SUCCESS) printf("Processing error: %d\n", ret); char outfn[256]; sprintf(outfn, "%s.tif", fname); if (LIBRAW_SUCCESS != (ret = rp.dcraw_ppm_tiff_writer(outfn))) printf("Cannot write %s: %s\n", outfn, libraw_strerror(ret)); else printf("Created %s\n", outfn); ret = rp.dcraw_process(); // Check for error using LIBRAW_SUCCESS. I never get an error here ret = rp.dcraw_ppm_tiff_writer(fname);-2 is: LIBRAW_FILE_UNSUPPORTED
If your 'raw' file is just a sensor dump without metadata consider using open_bayer() call
Microsoft RAW extension is produced by Microsoft, we're not involved in this process in any way (Microsoft uses the public version of LibRaw).
So, we're completely not responsible for MS RAW Extension.
You may try to use our FastRawViewer instead.
I have the exact same issue with A7VI RAWs and the Microsoft RAW extension.
I figured out it's related to the new Sony lossless compressed RAW format.
A7IV compress or uncompressed RAW are displayed fine, but A7IV lossless compress RAWs are not displayed at all.
The LibRAW blog post from 22. Oct. 2021 says the new Sony losslesss compressed RAW format is now supported.
My guess would be Microsoft RAW extension includes a version that is too old.
So you're talking about Microsoft RAW Extension, right?
Using Windows 11 for importing and cataloguing, I cant view any Sony a7iv raw files. I can open them in photoshop, but I dont like shooting raw & jpeg
Pages