ok, sudo ldconfig solved the problem.
Now, I tested ART on my images: no problem with images from Canon 300D, G16, G7X, and Fujifilm X-T1.
But I have problems with Canon 60D:
When I double click, ART crashes.
I attach a raw file:
img_0496.cr2 (12.2 MB)
Hi Alberto,
I see now that the raw file that I sent is not a real RAW, but is a mRAW or sRAW (already demosaicized)
Hi Alberto
previous issue solved.
Now there is a problem with
2020-07-31_20-05-18_P1040218.RW2 (10.5 MB)
I get a strong pink cast.
Thanks. All these issues are due to wrong black and white levels. It seems libraw is not always consistent in the way it reports them, and in art there’s the additional complication that we want to use the values from camconst when they are more accurate. So,it’s going to take a few rounds of adjustments to get this right for all cases. Please be patient…
2 Likes
If it can help, some remaining faulty files
20151121080509_Rajashthan.CR2 (10.6 MB)
20151121080532_Rajashthan.CR2 (10.6 MB)
Canon - Canon EOS R5 - 3 2.CR3 (70.6 MB)
rps_82A0711_21-11-2020-17.34.CR3 (26.0 MB)
1 Like
I would like to know if somebody ever succeeded to make a dynamic build of libraw on MSYS2/MINGW64?
If yes, could you upload your procedures?
Note: I suspect there is a problem with the naming of files with libtools on MSYS2 ( C:\myfile vs /c/myfile) which is not properly adressed by devs. Its the case also with last versions of lcms2.
So I should crosscompile on LINUX/mingw64, but not willing to do that!
As far as I know, once working on LINUX, cmake/make or meson/ninja procedures work on MSYS2.
they all work with libraw 0.21 snapshot. I’m inclined to add that as a minimum requirement at this point…
I spent a couple of days trying to get a MSYS2 libraw dynamic build to work a couple of years ago, one of the reasons I decided to keep rawproc in static builds.
Just curious: can people try Phase One iiq files?
I’ve recently been having trouble with the colors in Filmulator (which uses LibRaw) when I tested them and I’m not sure why; they used to work.
This works from the MINGW64 shell on LibRaw master (you probably also want zlib, lcms2, and optionally jasper installed):
$ autoreconf -ifv
$ CPPFLAGS+=" -DLIBRAW_FORCE_OPENMP" ./configure --prefix=${MINGW_PREFIX}
$ make
This will produce both static and dynamic libraries, much like the official MSYS2 package does.
You might want to change prefix to /usr/local or e.g. /opt/libraw according to your needs.
You can also check out GitHub - LibRaw/LibRaw-cmake: LibRaw cmake scripts, contributed by users, unmaintained by LibRaw
I compiled ART against libraw from the 0.21 snasphot, and I confirm it works on the files that failed for @gaaned92.
However, the histogram seems broken in the libraw branch, it’s fine in the dev branch.
I understand. But the problem is that at present only 0.20 is present in MINGW64 and I am not able to build it dynamically on MSYS2/MINGW64.
Thanks, I am going to try.
But the MSYS2/MINGW64 packages are built in an Unix environment I think.
I hope libraw devs will use modern build tools (cmake or Meson) instead of these outdated tools.
I suppose you build on Linux?
Yes
Nope, all built on MSYS2 itself AFAIK. Even if they are, so what? Just means the cross-compile toolchain works…
Don’t hold your breath. They’ve actually spun out and relinquished ownership of said LibRaw-cmake repository. Same goes for meson.
This is probably my fault, sorry. I’ll fix it asap
@sguyader sorry, I spoke too early. I thought I knew what could be going wrong, but in fact I don’t 
So, can you describe in more detail your problem? Thanks!
As they use pkgbuild, I suppose they are on an archlinux system. It’s not the only package using the autotools things that miserably fail on MSYS2/MINGW64 but can be cross compiled on Linux.
Too bad. This is certainly due to some personal conflict because I don’t see what could have been the technical issue.
-
If somebody can explain what is happening:
*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz and none of the candidates passed a file format test
*** using a file magic. Last file checked: C:/msys64/mingw64/lib/libz.dll.a*** Warning: linker path does not have real file for library -lws2_32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libws2_32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: C:/msys64/mingw64/x86_64-w64-mingw32/lib/libws2_32.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it. -
@sguyader are you able to cross compile for windows? If not I am going to try the cmake way. Thanks.
Yes, MSYS2 uses pacman and makepkg. They have indeed been ported from Arch, but run completely natively in MSYS2, there is no Linux or cross-compiling involved.
Sorry, I’m probably just slow, but I don’t understand what I’m seeing…is the image displayed correctly or not? If not, can you share it? If yes, what is it that you are expecting? Both histograms look weird to be honest, so if there’s a bug (and it seems so) it’s probably not related to libraw…