I can provide the files (as long as they will not appear in a public forum). I think it would suffice to upload the two .CR3 files (35 MB each). Can you please show me a way to upload them?
There is libraw_open_wfile() that expects wchar_t filename.
LibRaw/github switched from iostreams-based LibRaw_abstract_datastream implementation to native-calls based implementation (LibRaw_bigfile_buffered_datastream) which is much faster under Win32.
Probably, your msys2's std::filebuf worked right with UTF-8 filenames, but this is miracle, not the expected behaviour.
is there a difference between 0.20.2 and git version for the wide char handling ?
Because if I compile my soft with LibRaw <= 0.20.2 I have no problem. If I compile with LibRaw git version I have an error trying to opening CR2 Raw with wide char in paths.
My code was not very useful I must admit, this is just my code used to read wide char path.
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.
Hi,
I can provide the files (as long as they will not appear in a public forum). I think it would suffice to upload the two .CR3 files (35 MB each). Can you please show me a way to upload them?
Lellid
We do not provide precompiled snapshot versions. Please contact vendor of your software to re-compile it with newer libraw.
Looks like your patch works like a charm.
Cheers,
Yes (if you do not use earlier github snapshots)
No problem: no risk no fun ;).
I will let you know.
Last question. Which version I could consider for your change?
LIBRAW_VERSION > LIBRAW_MAKE_VERSION(0, 21, 0)?As a result, you use very untested (and not supported) code path :)
I will test it.
In fact our code is cross-compiled with CI pipelines: can't use visual studio. Especially because we build it for linux too.
Followup:
I do not have msys2/mingw/similar tools installed, so not tested.
MS Visual Studio (community) is free, so it makes sense to use native vendor compiler for Win32
(should be) fixed by this commit: https://github.com/LibRaw/LibRaw/commit/30595a731f3bea78f0410426b73ef3af...
Oh thank you.
If you fix it, you'll make me happy.
Thanks for your feedback
Please, let me know.
Cheers,
OK, this need to be fixed.
OK thanks for your kindness.
But with libraw_open_wfile
I get:
undefined reference to `libraw_open_wfile'because in the LibRaw code there is
#if defined(_WIN32) && !defined(__MINGW32__) && defined(_MSC_VER) && \ (_MSC_VER > 1310) int libraw_open_wfile(libraw_data_t *lr, const wchar_t *file) { if (!lr) return EINVAL; LibRaw *ip = (LibRaw *)lr->parent_class; return ip->open_file(file); }So it can't work under msys2.
You may switch back via defining LIBRAW_USE_DEPRECATED_IOSTREAMS_DATASTREAM
But this is temp. solution: it will work with LibRaw 0.21, but will be removed in future releases.
Also: LIBRAW_WIN32_UNICODEPATHS is set if:
# elif _GLIBCXX_HAVE__WFOPEN && _GLIBCXX_USE_WCHAR_T
So if such macros are defined for your runtime, unicode paths should work.
There is libraw_open_wfile() that expects wchar_t filename.
LibRaw/github switched from iostreams-based LibRaw_abstract_datastream implementation to native-calls based implementation (LibRaw_bigfile_buffered_datastream) which is much faster under Win32.
Probably, your msys2's std::filebuf worked right with UTF-8 filenames, but this is miracle, not the expected behaviour.
Here my code
static int siril_libraw_open_file(libraw_data_t* rawdata, const char *name) { /* libraw_open_wfile is not defined for all windows compilers */ #if defined(_WIN32) && !defined(__MINGW32__) && defined(_MSC_VER) && (_MSC_VER > 1310) wchar_t *wname; wname = g_utf8_to_utf16(name, -1, NULL, NULL, NULL); if (wname == NULL) { return 1; } int ret = libraw_open_wfile(rawdata, wname); g_free(wname); return ret; #elif defined(_WIN32) gchar *localefilename = g_win32_locale_filename_from_utf8(name); int ret = libraw_open_file(rawdata, localefilename); g_free(localefilename); return ret; #else return(libraw_open_file(rawdata, name)); #endif }As you can see I use it when it is allowed. But on my side I always compile with msys2... So I don't have API.
Hummm If I well recall, LibRaw::open_file(wchar_t*) does not work with msys2.
And my code is compiled through msys2.
It looks like (I'm not sure, but the function names indicate this), you're converting filename from UTF-8 back to UTF-8.
If it worked at 0.20 then it was a miracle.
LibRaw has special LibRaw::open_file(wchar_t*) call under Win32, it is THE recommended way to go.
I do not know why UTF-8 filenames worked before. It should not.
Ok Sorry if I'm unclear.
My question is:
is there a difference between 0.20.2 and git version for the wide char handling ?
Because if I compile my soft with LibRaw <= 0.20.2 I have no problem. If I compile with LibRaw git version I have an error trying to opening CR2 Raw with wide char in paths.
My code was not very useful I must admit, this is just my code used to read wide char path.
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!Pages