Hi Steve, I had the same requirements for colorimetry applications and ended up writing a C++/CLI wrapper for libraw some time ago (i.e. direct API rather than PInvoke). Look for the LibRawWrapper NuGet package, should be usable in VB.NET, with imgdata.rawdata accessible via LibRawProcessor.RawData.
I have made some progress in VB.NET to get camera sensor data from "libraw.dll".
For example, I see image size data but all values in "libraw_rawdata_t" are 0 or Nothing, including pointer "raw_image". So therefore I don't see any pixel data.
Recall that I am only executing "libraw_init" , "libraw_open_file" and "libraw_unpack" as I only want to get the raw unprocessed data from the camera sensor.
I am not asking about how to use VB.NET, but whether I have included all typedefs from libraw_types.h.
I have created in VB.NET all the data structures that are defined in "libraw_data_t" (from "libraw_types.h").
I have also included all nested data structures that are referenced by those data structures in "libraw_data_t".
My question is: Are there any other data structures that I have to include from other C or C++ files to get the raw unprocessed data from the camera sensor? For example, in "unprocessed_raw.cpp", will I need to include data structures defined in "#include "libraw/libraw.h"?
Hi Alex,
thanks a lot for the fast response. Good to hear, that I can proceed with 32-bit. I am also surprised that there still seems to be the need for it.
My LibRaw is older. I started with https://github.com/hurlbertvisionlab/LibRawWrapper.git which includes LibRaw and is from July 2021. Will update the local copy of LibRaw with latest version from https://github.com/LibRaw/LibRaw.git and will let you know about the result.
Link to sample file is sent to info@libraw.org.
If your LibRaw is older consider upgrade via github (or just apply this patch)
The easiest way to build 32-bit LibRaw for windows is
1) start Visual Studio developer shell in 32 bit mode
(e.g: run cmd.exe and execute
call "C:\Program Files ... path to VisualStudio installation...\VC\vcvarsall.bat" x86
)
2) run nmake -f Makefile.msvc to build LibRaw
32-bit windows (and even more broadly, 32-bit apps) don't look relevant in 2022, nevertheless, it is still too early to completely stop 32-bit systems support.
LibRaw's main goal is RAW data extraction (plus metadata needed for RAW processing).
RAW conversion is very basic and no plans to improve it (or even touch it).
Generally speaking, raw color data is also out of LibRaw's scope (unless contained in RAW metadata), although we provide some basic data enough for basic processing.
I just put the cam_xyz into ColorMatrix1 and set the illuminant1 to D65.
The DNG output color is slightly off but acceptable.
I'm not sure if libraw can do this. Take the PixelShift2DNG application as an example, that one is built around libraw but only supports a few cameras, the ColorMatrix1 field can be easily copied from Adobe DNG Converter results.
Well, that's one possible solution, convert the images using Adobe DNG Converter first, then you have it.
rawtherapee which uses some custom dcraw success in extracting the compressed raw data,
but it fails in decoding the decompressed structure.
I modified it to dump the uncompressed raw (which display as garbage currently).
For a 25 mb pixels image, there is exactly 50 mbytes of decoded data being decoded.
which correspond to 2 bytes per pixel, which seems to be confirming the 16 bits per pixel.
I tried making a black frame and a white frame,
just to see if I could understand something, but the result are not that great:
The first bytes of the frames are looking like that:
So...
either they are crypted or salted,
either the colorspace is uncommon,
either I am missing something, which can be possible as I am far from an expert in this domain.
The data are there : (including the two RW2 files)
samples/unprocessed_raw.cpp code sample shows how to use imgdata.rawdata.raw_image array (other cases: 3/4 color images, float images are not covered by this sample)
Sorry, know nothing about VB.NET, so I don't know what your problems might be
The profile created is very close to sRGB profile (default tone curve is slightly different).
So, if the problem still exists: please make sure
a) you use real updated LibRaw, not outdated .dll or .so/.dylib somewhere in the shared library path
b) you have recompiled your application too: offsets in LibRaw object may change resulting in unexpected things
According to the update policy published on this site main page
It probably makes sense to take more detailed measurements
Thanks jantheman. I will contact you outside this forum.
Regards
Hi Steve, I had the same requirements for colorimetry applications and ended up writing a C++/CLI wrapper for libraw some time ago (i.e. direct API rather than PInvoke). Look for the LibRawWrapper NuGet package, should be usable in VB.NET, with imgdata.rawdata accessible via LibRawProcessor.RawData.
Sorry, know nothing about VB.NET
In C/C++ libraw/libraw.h is enough, all needed files will be included automatically via #include directives in libraw.h
Hi Lexa
I have made some progress in VB.NET to get camera sensor data from "libraw.dll".
For example, I see image size data but all values in "libraw_rawdata_t" are 0 or Nothing, including pointer "raw_image". So therefore I don't see any pixel data.
Recall that I am only executing "libraw_init" , "libraw_open_file" and "libraw_unpack" as I only want to get the raw unprocessed data from the camera sensor.
I am not asking about how to use VB.NET, but whether I have included all typedefs from libraw_types.h.
I have created in VB.NET all the data structures that are defined in "libraw_data_t" (from "libraw_types.h").
I have also included all nested data structures that are referenced by those data structures in "libraw_data_t".
My question is: Are there any other data structures that I have to include from other C or C++ files to get the raw unprocessed data from the camera sensor? For example, in "unprocessed_raw.cpp", will I need to include data structures defined in "#include "libraw/libraw.h"?
Apart from what Alex said, good colour can't be solved with a set of 3 by 3 matrices.
Hi Alex,
thanks a lot for the fast response. Good to hear, that I can proceed with 32-bit. I am also surprised that there still seems to be the need for it.
My LibRaw is older. I started with https://github.com/hurlbertvisionlab/LibRawWrapper.git which includes LibRaw and is from July 2021. Will update the local copy of LibRaw with latest version from https://github.com/LibRaw/LibRaw.git and will let you know about the result.
Link to sample file is sent to info@libraw.org.
Norbert
Could you please provide the sample file that is handled wrong in 32-bit mode? Use info@libraw.org for that :)
On Nov 26, 2021 we fixed one 32-bit related error via this commit: https://github.com/LibRaw/LibRaw/commit/30595a731f3bea78f0410426b73ef3af...
Probably it will fix the issue but we need sample file to be sure.
If your LibRaw is older consider upgrade via github (or just apply this patch)
The easiest way to build 32-bit LibRaw for windows is
1) start Visual Studio developer shell in 32 bit mode
(e.g: run cmd.exe and execute
call "C:\Program Files ... path to VisualStudio installation...\VC\vcvarsall.bat" x86
)
2) run nmake -f Makefile.msvc to build LibRaw
32-bit windows (and even more broadly, 32-bit apps) don't look relevant in 2022, nevertheless, it is still too early to completely stop 32-bit systems support.
LibRaw's main goal is RAW data extraction (plus metadata needed for RAW processing).
RAW conversion is very basic and no plans to improve it (or even touch it).
Generally speaking, raw color data is also out of LibRaw's scope (unless contained in RAW metadata), although we provide some basic data enough for basic processing.
I think for me the real question is why libraw only uses one color matrix? Why not use two like DNG 1.5 and before or even three like DNG 1.6?
I just put the cam_xyz into ColorMatrix1 and set the illuminant1 to D65.
The DNG output color is slightly off but acceptable.
I'm not sure if libraw can do this. Take the PixelShift2DNG application as an example, that one is built around libraw but only supports a few cameras, the ColorMatrix1 field can be easily copied from Adobe DNG Converter results.
Well, that's one possible solution, convert the images using Adobe DNG Converter first, then you have it.
According to Update Policy section at this site homepage: https://www.libraw.org/
Thanks. Do you have a timeframe for this snapshot release?
I tried to inspect a bit more the situation:
rawtherapee which uses some custom dcraw success in extracting the compressed raw data,
but it fails in decoding the decompressed structure.
I modified it to dump the uncompressed raw (which display as garbage currently).
For a 25 mb pixels image, there is exactly 50 mbytes of decoded data being decoded.
which correspond to 2 bytes per pixel, which seems to be confirming the 16 bits per pixel.
I tried making a black frame and a white frame,
just to see if I could understand something, but the result are not that great:
The first bytes of the frames are looking like that:
white frame:
00000000: dfce f87f 7b8c ffdb d77c 9d99 7c14 29bd ....{....|..|.). 00000010: 91a7 d027 0405 22d3 147d 3371 f16b 0b07 ...'.."..}3q.k..black frame:
So...
either they are crypted or salted,
either the colorspace is uncommon,
either I am missing something, which can be possible as I am far from an expert in this domain.
The data are there : (including the two RW2 files)
http://esby.free.fr/perso/GH6-RW2/
See
http://esby.free.fr/perso/GH6-RW2/P1000404-black.info
and
http://esby.free.fr/perso/GH6-RW2/P1000407-white.info
for the filesizes and basic descriptions
(the dng were producted by Adobe Dngconverter 14_3 under wine staging 7.2 )
In the meantime conversion with the most recent Adobe DNG Converter works.
Most likely not
Will GH6 raw format supported in the next release/snapshot?
Regards
Ugo
Nikon Z9/standard compression support will be published in next snapshot or release (whatever comes first)
Thanks. This gives me the confidence that I am looking at the correct data structure.
I have looked at unprocessed_raw.cpp, but it is slow going for me, not being a C or C++ developer, but I will keep at it.
I now have the confidence that I should be able to solve my issue in VB.NET.
Will keep you posted.
SteveR
Dear SteveR:
Quoting from datastructures API (https://www.libraw.org/docs/API-datastruct-eng.html#libraw_rawdata_t already quoted above):
unsigned short *raw_image;
Pointer to buffer with one-component (bayer) data.
Have you looked at the source code of the unprocessed_raw.cpp (also quoted above)?
Thanks. However, I don't believe I can create an instance in VB.NET of imgdata to be able to access the raw_image array
I can access the various data structures in VB.NET, as listed previously.
Does one of the data structures contain the RAW values from the sensor pixels?
libraw_rawdata_t is described in documentation: https://www.libraw.org/docs/API-datastruct-eng.html#libraw_rawdata_t
samples/unprocessed_raw.cpp code sample shows how to use imgdata.rawdata.raw_image array (other cases: 3/4 color images, float images are not covered by this sample)
Sorry, know nothing about VB.NET, so I don't know what your problems might be
Yes, this is completely new encoding format, nothing common with previous panasonic formats.
The profile created is very close to sRGB profile (default tone curve is slightly different).
So, if the problem still exists: please make sure
a) you use real updated LibRaw, not outdated .dll or .so/.dylib somewhere in the shared library path
b) you have recompiled your application too: offsets in LibRaw object may change resulting in unexpected things
Pages