preliminary libraw support -- call for testing

Here’s a windows build of the head of the libraw branch, if someone wants to test it: https://drive.google.com/file/d/1UFHltVcxJCeJ14J57NlNFLJBauvoG9Pc/view?usp=sharing
(just unzip it and run ART.exe)

I did not encounter any problems editing my Canon M50 CR3 files, this is excellent!

1 Like

I built last libraw snapshot with libraw-cmake on MSYS2/MINGW64 without problem.

It seems that dcraw.cc is still compiled. Is it still required?

No problem with editing the different files.

New W10 builds available here ART-W64NightlyBuilds/ – Keybase.pub

Hi, Alberto
I tried windows version, and I found no problems for Nikon D3200, 5500, Olympus E-P3, E-5 files.
But it cannot manage Sigma’s X3F files which ART 1.10.1 can manage.

Hi, thanks for testing! Can you share an x3f file that used to work?

You have to make sure libraw is built w/ x3f support, I think it’s off by default…

You are right. Needs to be set

I used free raw file samples in following site.

https://rawsamples.ch/index.php/en/sigma

For some reasons SDQ is missing, here is one: (~50Mb)

https://drive.google.com/file/d/1bQIadMidxh6s-83efpRXWpDDXCe7izaf/view?usp=sharing

And I submit some other Sigma’s raw files which are distributed in following site, and the author admit use them freely.

files:
https://drive.google.com/drive/folders/1SfTs0xucKuA1fayZdvIiZVrm-9T5D1rq?usp=sharing
(including an extra high resolution format X3I file.)

Thanks!

No problems with:

CR3 from Canon 90D
CR2 from Canon 6D Mk2
DNG from DJI Mini 2.

How you do that? I tried 1.10.18 and I don’t see any x3f - or is that because of SDQ?

(would love to have a good x3f editor, Sigma PhotoPro is terribly slow, Affinity Photo is OK, but for me not a real RAW processor)

Sigma’s X3F files aren’t all same. I think ART DCRaw version can manage Sigma Merrill’s X3F files, but Quattro, Quattro H’s files.
Libraw may manage all X3F files, perhaps. But X3I files…?

Possible. Although Affinity Photo uses Libraw and can read my SDQ X3F. So I keep my fingers crossed :wink:

Hi Alberto
After the merge vith libraw branch, the master branch version is 1.8.2-223-g53923f0cd, instead it should be 1.10.1-xx-g53923f0cd.

Is there something to do in local rep? Thanks

Version: 1.8.2-223-g53923f0cd
Branch: master
Commit: 53923f0cd
Commit date: 2021-11-07
Compiler: cc 11.2.0
Processor: Skylake
System: Windows
Bit depth: 64 bits
Gtkmm: V3.24.5
Lensfun: V0.3.95.0
Exiv2: V0.27.5.2
LCMS2: V2.12
LibRaw: V0.21.0.Snapshot202101
Build type: release
Build flags:  -m64 -mwin32 -msse2   -mfpmath=sse  -Wno-attributes  -Wno-aggressive-loop-optimizations -Wno-parentheses -std=c++11 -fno-tree-loop-vectorize -march=native -Werror=unused-label -fno-math-errno -Wl,--stack,4194304 -Wall -Wuninitialized -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas  -DNDEBUG  -O3 -ftree-vectorize
Link flags: -m64  -static-libgcc   -march=native  -s  -O3  -fno-use-linker-plugin
OpenMP support: ON
Build OS: Windows
Build date: 2021-11-08T08:00:54Z

I will delete the “version” stuff, it’s really useless. Besides, I don’t know git well enough to fix this (and I don’t really bother learning it)

But users are now familiar with the version numbering and will be puzzled if there is no longer a meaningfull version on the header of ART main Window.
I propose simply you tag 1.10.2 the last version.

1 Like

No problems with:

ORF files from Olympus Pen F.

Official releases will still have the version number, it’s only development releases that will just show the git hash.