ART feature requests and discussion

Software ART
849

here ART-W64NightlyBuilds/ – Keybase.pub

  • select a generic build, it contains a normal generic build and a debug build
  • once extracted in a directory, from a command window , go to this dirdirectory
  • then gdb.exe rawtherapee-debug.exe
2 Likes
850

Thanks @gaaned92, there are symbols in the executable in that build indeed, gdb loaded them. So I ran art-debug.exe through gdb, it took quite a while to reproduce the issue (maybe because it was working 20 times slower than usual). But the stacktrace is the same:

(gdb) bt
#0 0x00007ff75f71fc99 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Which suggests that the address is already invalid because stack is corrupted. In this situation something like valgrind or asan might help, both of which are not available on windows.

I also tried disabling all the modules one by one (even demosaicing), and also changing thread count in settings from 0 to 1, but nothing helped, it always crashes.

851

Can you send me a raw and arp combination that triggers the crash? Thanks!

852

Sure, it happens on any of my photos and on any profile. Here is the one with arp of Neutral profile:

DSC_4058.NEF (28.2 MB) DSC_4058.NEF.arp (10.8 KB)

I noticed, that it’s much more likely to crash when I open a photo for the first time after start of the program.
I would suggest these steps to reproduce:

  1. Open raw file, set neutral profile, close file, close ART
  2. Start ART again, open raw file (with double click) and start rapidly zooming right away (maybe even a fraction of second before the photo is completely loaded and displayed).

For me it will crash with probability of ~ 90%

When I was testing it through gdb, ART was working much much slower, and I had to spend maybe 5 or 10 minutes trying before it crashed. I have i9 9900k, and so I think if ART is not working that fast on your machine (especially if you test it in vm with windows) - this might be the reason why you can’t reproduce it.

853

Yes, the speed is the key here. On my side art crashes only if I zoom in, and zoom in again when the engine has started to refresh the preview window (but maybe it’s just a feeling). On my side, again, it crashes more easily when I use “smoothing” with many layers and masks, things that can take time to refresh.

854

Thanks for the additional info. I am still unable to reproduce it so far unfortunately… anybody has seen this happening on linux btw?

855

Just a quick question re Retinex and Wavelets: are there any plans to transfer the RT features into ART?
Understanding Retinex is not very easy (for me) but the results in RT can be stunning sometimes. I think the Dehaze feature does not replace Retinex entirely (?)

856

Hi,
I had ART 1.8.2 compiled by myself. I just updated to 1.8.4 using the linux tarball, but it doesn’t have the lens correction DB available (although lensfun seems to be included in the package…). Is there something to do?

$ cat AboutThisBuild.txt

Version: 1.8.4
Branch: master
Commit: b0bdd1fda675
Commit date: 2021-04-04
Compiler: cc 7.5.0
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: V3.22.2
Lensfun: V0.3.95.0
Exiv2: V0.27.3
LCMS2: V2.12
Build type: Release
Build flags: -std=c++11 -Werror=unused-label -fno-math-errno -Wall -Wuninitialized -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG -ftree-vectorize
Link flags:
OpenMP support: ON
MMAP support: OFF
Build OS: Linux
Build date:

857

No, sorry

858

Can you post the contents of your options file? (should be in $HOME/.config/ART)

859

Thanks for pointing me to this file, the lensfun directory was empty, I updated accordingly and now it is all good!
Thanks again :ok_hand:

1 Like
860

Can I ask, why? Is there a specific reason?

861

In general, they are too low level for my taste, and so they don’t fit in the ART philosophy.
More specifically: for retinex, I just don’t understand how to use it; for wavelets, they are already used behind the scenes in various places.

Best

862

OK, thanks

863

On Linux I can zoom out to 1% then in to 1600% and back out to 1%, using the - and + keys, no problem.

864

Seems like linux is not affected, I’ve tried it on Arch Linux (in a vm) and couldn’t reproduce the issue.
But I use windows, and unfortunately latest versions of ART is basically unusable for me. Today I wanted to test something (in photography) and tried to do a couple of edits, and it crashed like five times in just two minutes of working. I can’t use it basically.
I tried to remove art folder from appdata, and it seems like it is harder to reproduce the issue with default settings, but it still crashes.

Since it’s relatively easy to install and use any version of ART, I would try to find when the issue was introduced, but there are no older windows binaries stored anywhere, only the latest dev and stable?

865

I’m sorry to hear that. I’ll try harder to reproduce this in my windows VM…

866

Just to understand: does this happen only when using “multi editor tabs mode” or also in “single editor tab mode”?

867

Hi,
I’m testing a workaround for this (I’m still not sure why it happens, so I’m not sure my hack will work either…), it would be great if you could give it a try and let me know if it improves the situation.
You can download an ART build from here:

https://drive.google.com/file/d/1XTPjpbBvZz1wJTnNpVT18bu1UHqh_OLX/view?usp=sharing

Just unzip it somewhere and run, no installation required

Thanks in advance!

868

Hi Alberto, thanks for looking into it.

Hmm, I tried switching this option and I have no crashes in “single editor tab mode” so far. Once I switch back to multiple tabs - it becomes very easy to get a crash.
Apologies for confusion, I said that it crashes with default settings in my last post, but I think I switched to multiple editor tabs.

I’ve tested it and I couldn’t get a crash (in multiple tabs mode). The new zooming behavior is not very convenient though :slight_smile: