These files are uncompressed 16-bit sensor dumps (for example, 3264*2448 = 7990272 pixels x 2 bytes per pixel = 15980544 bytes, exact size of file provided).
Also, according to manual (easy to find), camera does not provide raw recording, so raw files are some kind on debug mode or something like that.
I'm unable to see any meaningful image in these samples, it looks like flat field shot, or something like that. So it is not possible to determine if white/black level set correctly or not. Please provide something with well known subject.
Btw, there is zero guarantee that in a DNG that ColorMatrix2 corresponds to D65 illuminant, or that there is one corresponding to a D65 illuminant at all. It is just a recommendation, not a requirement.
Not sure it is good idea (unless specified explicitly by library user via some flag?)
cam_xyz contains built-in data (from colordata.cpp), dng_color filled by DNG tags, not sure DNG data should always overwrite built-in data.
Yes, raw_pitch field is filled only on unpack() phase: this data field describes layout of data in imgdata.rawdata.* array(s), not in input file and it is not known before unpack().
Thank you. I looked in to this more, it turns out the libraw->rawdata.color.cam_xyz field is blank with DNG images. I had to look at libraw->rawdata.color.dng_color
Sorry about the mistaken post!
I have a suggestion: Maybe put DNG's ColorMatrix2 (Daylight) in to the cam_xyz field? It might reduce confusion for some developers.
I am using build from latest source code from github.
In colour science CCT is derived from xy. xy calculation depends on the colour transform, raw to XYZ. This transform is not one-to-one because raw data isn't colorimetric. Different companies use different colour transforms for the same camera model. Say, the camera and ACR report different CTs for the same shot.
Your best bet is to shoot a camera at each CT setting, compile a table of CTs vs. wb coeffs, and interpolate.
What I want to do is to give user a Color temperature slider that needs to start with the color temp of the photo (say 5000K) and let him move in the range of say 2000-10000K.
So how do I compute this using the various data obtained in libraw_colordata_t? I thought cam_mul is a start?
If you're speaking about:
#elif (defined(__APPLE__) || defined(__MACOSX__)) && defined(_REENTRANT)
/* Latest XCode works with OpenMP, need to recheck here */
#undef LIBRAW_USE_OPENMP
This is not bug, but specially added because standard Apple toolchain does not support OpenMP
For other toolchains one may use -DLIBRAW_FORCE_OPENMP to enable this #if-branch:
#if defined(LIBRAW_FORCE_OPENMP)
...
I grabbed the OpenMP dylib there and it compiles fine. No need to download another version of llvm.
In fact, I finally got LibRaw to work. There is a bug in Libraw_types.h in which it failed to detect -fopenmp when compiling via Xcode. Fixing that LibRaw compiles just fine using Xcode 12.4 with OpenMP support.
The question I have now is: how to control the number of threads during decode? It seems the #pragma parallel will cause the number of threads creation the same as the number of logical processor. I don't want that many. Is there a way I can alter that during runtime before calling unpack()?
I'm unable to build openmp app with Xcode/clang because of omp.h missing. find / -name omp.h returns nothing.
So:
1) It is not possible to compile LibRaw with openmp using standard Apple tools (12.4 and 12.5)
2) If you was able to compile it: that means you have omp.h from some other build tools, we're unable to provide support in that case. You may add some #error preprocessor directives into LibRaw sources near #pragma omp to make sure it compiled with openmp or not.
2021-10-20 16:23:46.653740-0700 Test[14661:304853] Greetings from thread 0
2021-10-20 16:23:46.653954-0700 Test[14661:304941] Greetings from thread 1
2021-10-20 16:23:46.653985-0700 Test[14661:304943] Greetings from thread 3
2021-10-20 16:23:46.654015-0700 Test[14661:304942] Greetings from thread 2
2021-10-20 16:23:46.654045-0700 Test[14661:304944] Greetings from thread 4
2021-10-20 16:23:46.654069-0700 Test[14661:304947] Greetings from thread 7
2021-10-20 16:23:46.654085-0700 Test[14661:304946] Greetings from thread 6
2021-10-20 16:23:46.654102-0700 Test[14661:304945] Greetings from thread 5
My problem now is with libraw:
In the Makefile.dist, I uncommented CFLAGS+=-fopenmp and I added -Xclang to it, so it looks like:
CFLAGS+=-Xclang -fopenmp
It compiles fine, but when I linked my project, it'll link even I did not have libomp.dylib. So libraw is not really compiled with OpenMP support with the CFLAGS line above.
Could you please reformulate your question? What is the problem and how it is related to code you quote?
It is very difficult to discuss the problem in abstract without having sample files
It is hard to discuss anything related to RAW processing without having the sample file(s)
Thank you for the files, downloaded.
These files are uncompressed 16-bit sensor dumps (for example, 3264*2448 = 7990272 pixels x 2 bytes per pixel = 15980544 bytes, exact size of file provided).
Also, according to manual (easy to find), camera does not provide raw recording, so raw files are some kind on debug mode or something like that.
I'm unable to see any meaningful image in these samples, it looks like flat field shot, or something like that. So it is not possible to determine if white/black level set correctly or not. Please provide something with well known subject.
Sensor dumps are supported via pre-defined table of known file sizes, to enable half-size image support apply this patch:
diff --git a/src/metadata/identify.cpp b/src/metadata/identify.cpp
index 251f97b2..eab078c0 100644
--- a/src/metadata/identify.cpp
+++ b/src/metadata/identify.cpp
@@ -247,7 +247,8 @@ void LibRaw::identify()
{ 10134608, 2588, 1958, 0, 0, 0, 0, 9, 0x94, 0, 0, "AVT", "F-510C" },
{ 10134620, 2588, 1958, 0, 0, 0, 0, 9, 0x94, 0, 0, "AVT", "F-510C", 12 },
{ 16157136, 3272, 2469, 0, 0, 0, 0, 9, 0x94, 0, 0, "AVT", "F-810C" },
- { 15980544, 3264, 2448, 0, 0, 0, 0, 8, 0x61, 0, 1, "AgfaPhoto", "DC-833m" },
+ { 3995136, 1632, 1224, 0, 0, 0, 0, 8, 0x61, 0, 1, "AgfaPhoto", "DC-833m" },
+ { 15980544, 3264, 2448, 0, 0, 0, 0, 8, 0x61, 0, 1, "AgfaPhoto", "DC-833m" },
{ 9631728, 2532, 1902, 0, 0, 0, 0, 96, 0x61, 0, 0, "Alcatel", "5035D" },
{ 31850496, 4608, 3456, 0, 0, 0, 0, 0, 0x94, 0, 0, "GITUP", "GIT2 4:3" },
{ 23887872, 4608, 2592, 0, 0, 0, 0, 0, 0x94, 0, 0, "GITUP", "GIT2 16:9" },
Or use 'custom camera API'
Hi Alex,
I have fixed the link permissions. Sorry about that.
https://drive.google.com/drive/folders/1X1Tdy744XXb2AaMvE9ZIwsNRqjoYbFUe....
The files are quite large and sometimes these email filters block files. Do let me know if you still have trouble accessing the files.
Regards,
Dinesh
Unfortunately, the link you provided is not for everyone, I've requested access
Alternatively you can attach the samples to E-mail targeted to info@libraw.org
Nevermind, of course, is is prefixed, I don't know why I didn't see it:
libraw_COLORSorry for the noise!7r iii A is supported in the recent snapshot
Unaltered ('as unpacked') pixel values are stored in imgdata.rawdata array(s)
samples/unprocessed_raw.cpp example writes (unaltered) data to TIFF file, probably this is code example you're looking for
Please check https://www.libraw.org/blog
ilce 7rm3a - sony alpha 7r iiia is actually Almosen same like ilce 7rm3 - sony alpha 7r iii
Btw, there is zero guarantee that in a DNG that ColorMatrix2 corresponds to D65 illuminant, or that there is one corresponding to a D65 illuminant at all. It is just a recommendation, not a requirement.
Not sure it is good idea (unless specified explicitly by library user via some flag?)
cam_xyz contains built-in data (from colordata.cpp), dng_color filled by DNG tags, not sure DNG data should always overwrite built-in data.
Yes, raw_pitch field is filled only on unpack() phase: this data field describes layout of data in imgdata.rawdata.* array(s), not in input file and it is not known before unpack().
Thank you. I looked in to this more, it turns out the libraw->rawdata.color.cam_xyz field is blank with DNG images. I had to look at libraw->rawdata.color.dng_color
Sorry about the mistaken post!
I have a suggestion: Maybe put DNG's ColorMatrix2 (Daylight) in to the cam_xyz field? It might reduce confusion for some developers.
I am using build from latest source code from github.
In colour science CCT is derived from xy. xy calculation depends on the colour transform, raw to XYZ. This transform is not one-to-one because raw data isn't colorimetric. Different companies use different colour transforms for the same camera model. Say, the camera and ACR report different CTs for the same shot.
Your best bet is to shoot a camera at each CT setting, compile a table of CTs vs. wb coeffs, and interpolate.
What I want to do is to give user a Color temperature slider that needs to start with the color temp of the photo (say 5000K) and let him move in the range of say 2000-10000K.
So how do I compute this using the various data obtained in libraw_colordata_t? I thought cam_mul is a start?
White balance is not measured in Kelvins.
There is no omp.h file in standard toolchain
This is no longer true. Standard Apple Toolchain works with OpenMP. Just add -Xclang -fopenmp to the compile flags.
I have to add -DLIBRAW_FORCE_OPENMP in the Makefile.dist in order for it work for standard Apple Toolchain.
That aside, but how do I control the number of threads to use? It seems be always the same as the number of logical processors.
Probably we need to remove comment 'need to recheck': rechecked and, yes, it will not work in standard Apple-provided environment
If you're speaking about:
#elif (defined(__APPLE__) || defined(__MACOSX__)) && defined(_REENTRANT)
/* Latest XCode works with OpenMP, need to recheck here */
#undef LIBRAW_USE_OPENMP
This is not bug, but specially added because standard Apple toolchain does not support OpenMP
For other toolchains one may use -DLIBRAW_FORCE_OPENMP to enable this #if-branch:
#if defined(LIBRAW_FORCE_OPENMP)
...
Just follow the instructions on this link:
https://mac.r-project.org/openmp/
I grabbed the OpenMP dylib there and it compiles fine. No need to download another version of llvm.
In fact, I finally got LibRaw to work. There is a bug in Libraw_types.h in which it failed to detect -fopenmp when compiling via Xcode. Fixing that LibRaw compiles just fine using Xcode 12.4 with OpenMP support.
The question I have now is: how to control the number of threads during decode? It seems the #pragma parallel will cause the number of threads creation the same as the number of logical processor. I don't want that many. Is there a way I can alter that during runtime before calling unpack()?
I'm unable to build openmp app with Xcode/clang because of omp.h missing. find / -name omp.h returns nothing.
So:
1) It is not possible to compile LibRaw with openmp using standard Apple tools (12.4 and 12.5)
2) If you was able to compile it: that means you have omp.h from some other build tools, we're unable to provide support in that case. You may add some #error preprocessor directives into LibRaw sources near #pragma omp to make sure it compiled with openmp or not.
Xcode 12.4 actually works with -fopenmp, you need to add -Xclang option just before it.
I made a small sample code like this:
int main(int argc, const char * argv[]) {
omp_set_num_threads(8);
#pragma omp parallel
#pragma omp critical
NSLog(@"Greetings from thread %d", omp_get_thread_num());
return NSApplicationMain(argc, argv);
}
And I get this on the console:
2021-10-20 16:23:46.653740-0700 Test[14661:304853] Greetings from thread 0
2021-10-20 16:23:46.653954-0700 Test[14661:304941] Greetings from thread 1
2021-10-20 16:23:46.653985-0700 Test[14661:304943] Greetings from thread 3
2021-10-20 16:23:46.654015-0700 Test[14661:304942] Greetings from thread 2
2021-10-20 16:23:46.654045-0700 Test[14661:304944] Greetings from thread 4
2021-10-20 16:23:46.654069-0700 Test[14661:304947] Greetings from thread 7
2021-10-20 16:23:46.654085-0700 Test[14661:304946] Greetings from thread 6
2021-10-20 16:23:46.654102-0700 Test[14661:304945] Greetings from thread 5
My problem now is with libraw:
In the Makefile.dist, I uncommented CFLAGS+=-fopenmp and I added -Xclang to it, so it looks like:
CFLAGS+=-Xclang -fopenmp
It compiles fine, but when I linked my project, it'll link even I did not have libomp.dylib. So libraw is not really compiled with OpenMP support with the CFLAGS line above.
So what else is missing?
Pages