preliminary libraw support -- call for testing

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.

I did some more testing with the latest build against libraw-snapshot 202110 against my Fuji RAFs and Pentax DNGs. Seems to work fine so far, did some edits and exports and all worked as it should.

I guess now that libraw 0.21 is required we have to wait moving forward this to master until this is released?

It’s already on master. If libraw >= 0.21 is not found, ART can still be built using the internal decoder…

It is? Why do i keep building the libraw branch? :smiley:

I even installed your AUR package (art-rawconverter-git) with libraw support by modifying the PKGBUILD (just adding -DENABLE_LIBRAW="ON") on the fly and it worked.

1 Like

yep, that is what i’ve planned to include in the AUR package…but need to adjust the package versioning first.

1 Like