How to compile ART?

I know ART supports the RAW files of OM-1 and the one installed using ART_1.13_Win64.exe works perfectly with those files. But the one I compiled locally from the source code can’t process the them. It either crashes or decode the files incorrectly (showing a purple frame). Could anyone please educate me how to compile ART correctly? Any advice/suggestion would be appreciated.

I’m compiling it on Windows 10 64-bit version using MSYS2.

The follows is the command used to compile it.

cmake -G “MSYS Makefiles”
-DLENSFUNDBDIR=share/lensfun
-DCMAKE_BUILD_TYPE=“release”
-DCMAKE_CXX_FLAGS="-msse2"
-DCMAKE_EXE_LINKER_FLAGS="-O3"
-DOPTION_OMP=“ON”
-DPROC_TARGET_NUMBER=“2” …

make -j8 install

Hi,
You need to enable libraw (-DENABLE_LIBRAW=1) and use the latest master version of libraw from github.

HTH

That solved my problem. Thanks a lot!

Could you also please share the options you pass into cmake? The local build I created crashes randomly. I’m guessing this might be related to the options I use.

My another question is related how to compile LibRaw. What are the options I should use?

Thanks!

Hi,
I’m typically building with mi-malloc as it gives better performance. Other than that, I’m just using the default flags for Release mode.
For libraw, I build using cmake, thanks to the LibRaw-cmake project on github.
If you notice crashes, see also the other recent thread on the topic. In particular, if you can produce a backtrace from within gdb, that would be helpful.
Thanks!

Could you please educate me how to enable mi-malloc when I compile ART?

Did you use any specific option when you compile LibRaw with LibRaw-cmake?

Thanks!

Hi,
Just build and install mimalloc, then set ENABLE_MIMALLOC=1 in CMakeCache.txt.
For libraw I think I used the default flags for release mode

This the information I collected before it crashes.
It looks like to me the crash is related to wavelet.
I’m guessing this issue might be caused by the compiler I use (gcc-11), since your build doesn’t have this problem.

Thread 196 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 880.0xf9c]
0x00007ff60085a37d in rtengine::wavelet_level::_ZN8rtengine13wavelet_levelIfE29SynthesisFilterHaarHorizontalEPKfS3_Pfii._omp_fn.0(void) () at C:/msys64/home/ART/rtengine/cplx_wavelet_level.h:252
252 for(int i = 0; i < skip; i++) {
(gdb) bt
#0 0x00007ff60085a37d in rtengine::wavelet_level::_ZN8rtengine13wavelet_levelIfE29SynthesisFilterHaarHorizontalEPKfS3_Pfii._omp_fn.0(void) ()
at C:/msys64/home/ART/rtengine/cplx_wavelet_level.h:252
#1 0x00007ffebc69e8d3 in ?? () from C:\msys64\mingw64\bin\libgomp-1.dll
#2 0x00007ffedfa74d53 in ?? () from C:\msys64\mingw64\bin\libwinpthread-1.dll
#3 0x00007ffee64daf5a in msvcrt!_beginthreadex ()
from C:\WINDOWS\System32\msvcrt.dll
#4 0x00007ffee64db02c in msvcrt!_endthreadex ()
from C:\WINDOWS\System32\msvcrt.dll
#5 0x00007ffee65e7034 in KERNEL32!BaseThreadInitThunk ()
from C:\WINDOWS\System32\kernel32.dll
#6 0x00007ffee6722651 in ntdll!RtlUserThreadStart ()
from C:\WINDOWS\SYSTEM32\ntdll.dll
#7 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Hi Alberto,

sidequestion:
does ART use/support mimalloc >= 2.0?
The last time i tried mimalloc was on 1.4 or something, current version is 2.0.6 and ART doesn’t detect it - if i understand CMakeLists.txt correctly it’s only looking for 1.4 releases.

Hmmm, i don’t know to be honest. I think I have 1.6, and for sure I haven’t tried 2.0. I’ll check and let you know

1 Like

On the latest version, my local release build on Windows 10 crashes at startup in the same function. I use latest msys (did pacman -Syu before compilation, so it is gcc 11). I don’t use LibRaw. ART window shows up for a moment and then it crashes. Here is stack trace from gdb:

Thread 7 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 12680.0x33a4]
0x00007ff6e3f3b4e8 in rtengine::wavelet_level::SynthesisFilterHaarHorizontal(float const*, float const*, float*, int, int) [clone ._omp_fn.0] ()
(gdb) bt
#0 0x00007ff6e3f3b4e8 in rtengine::wavelet_level::SynthesisFilterHaarHorizontal(float const*, float const*, float*, int, int) [clone ._omp_fn.0] ()
#1 0x00007ff9fa876e89 in ?? ()
from D:\MyDocs_Dev\msys64\mingw64\bin\libgomp-1.dll
#2 0x00007ff6e40f7a9f in void rtengine::wavelet_level::reconstruct_level(float*, float*, float*, float*, float*, float*, int, int, float) ()
#3 0x00007ff6e40fa2f5 in void rtengine::wavelet_decomposition::reconstruct(float*, float) ()
#4 0x00007ff6e3f3d22f in rtengine::ImProcFunctions::localContrast(rtengine::Imagefloat*) ()
#5 0x00007ff6e3e5023c in rtengine::ImProcFunctions::process(rtengine::ImProcFunctions::Pipeline, rtengine::ImProcFunctions::Stage, rtengine::Imagefloat*) ()
#6 0x00007ff6e3f21dad in rtengine::Thumbnail::processImage(rtengine::procparams::ProcParams const&, rtengine::SensorType, int, rtengine::TypeInterpolation, rtengine::FramesMetaData const*, double&, bool, bool) ()
#7 0x00007ff6e3d0075f in Thumbnail::processThumbImage(rtengine::procparams::ProcParams const&, int, double&) ()
#8 0x00007ff6e40caced in ThumbImageUpdater::Impl::processNextJob() ()
#9 0x00007ff6e41130d0 in std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::_Bind<sigc::bound_mem_functor0<void, ThumbImageUpdater::Impl> ()>, std::allocator, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) ()
#10 0x00007ff6e4111d4b in std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) ()
#11 0x00007ffa10e154cd in ?? ()
from D:\MyDocs_Dev\msys64\mingw64\bin\libwinpthread-1.dll
#12 0x00007ff6e4150704 in void std::call_once<void (std::__future_base::_State_baseV2::)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool>(std::once_flag&, void (std::__future_base::_State_baseV2::&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>&&, bool&&) ()
#13 0x00007ff6e4115b08 in std::_Function_handler<void (), rtengine::ThreadPool::enqueue<sigc::bound_mem_functor0<void, ThumbImageUpdater::Impl>&>(rtengine::ThreadPool::Priority, sigc::bound_mem_functor0<void, ThumbImageUpdater::Impl>&)::{lambda()#1}>::_M_invoke(std::_Any_data const&) ()
#14 0x00007ff6e418a0ad in rtengine::ThreadPool::ThreadPool(unsigned long long)::{lambda()#1}::operator()() const ()
#15 0x00007ff9f8691661 in ?? ()
from D:\MyDocs_Dev\msys64\mingw64\bin\libstdc+±6.dll
#16 0x00007ffa10e14d53 in ?? ()
from D:\MyDocs_Dev\msys64\mingw64\bin\libwinpthread-1.dll
#17 0x000001f45560b04a in msvcrt!_beginthreadex ()
from C:\WINDOWS\System32\msvcrt.dll
#18 0x000001f45560b11c in msvcrt!_endthreadex ()
from C:\WINDOWS\System32\msvcrt.dll
#19 0x00007ffa3af37bd4 in KERNEL32!BaseThreadInitThunk ()
from C:\WINDOWS\System32\kernel32.dll
#20 0x00007ffa3b4cced1 in ntdll!RtlUserThreadStart ()
from C:\WINDOWS\SYSTEM32\ntdll.dll
#21 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thanks for the info. Would you be able to try with a debug build?
Anyway, I’ll try to understand what is going on.

Just for your information, the crush I observed can’t be duplicated with the build created in debug mode. It CAN be duplicated either with build compiled in release or release with debug information mode.

Hi,

I built ART from source because otherwise it would not start on Ubuntu 22.04, but it is quite slow compared to the precompiled version I was using before. Here is how I built it: How to build ART on Ubuntu – ocroquette's technical Blog

Am I doing something wrong? How are the “official” versions built? Are the options documented somewhere?

Thank you!

Hi,
The flags you use look correct. Here are a couple of differences:

  • I use mi-malloc rather than tcmalloc as a custom allocator, because it provides more reliable performance. tcmalloc seems to suffer under some memory allocation patterns that are somehow triggered by art (unfortunately I didn’t have the time to investigate further)

  • I use the latest master version of libraw from github for raw decoding

  • finally, if your version of exiv2 doesn’t support your camera (for example for canon with cr3 output exiv2 needs to be built with special flags, not sure if the stock one has this enabled), art falls back to exiftool for metadata reading, which might also be a bit slower

HTH

Hi,

it should work now – thanks for reporting!

2 Likes

Thanks, i’ve reenabled mimalloc for the AUR package built from latest master. Gonna apply this to the release package as well if everything is fine.

It looks like to me the crash is partially related to the compiler and occurs when wavelet is used. RT crashes the same way after I upgraded msys2.

I updated msys2 today. The gcc version is 12.xx and it’s able to compile ART and RT properly. In other words, they don’t crash any more even if wavelet is turned on.

2 Likes

Thanks a lot for the info! I’ve just tried it - updated msys2 (gcc is now 12.1.0), rebuilt ART, and indeed it doesn’t crash anymore. Great!