- edited description
Segfault Local edit - Texture boost
Issue #35
resolved
Repeatable. Open file, go to Local edits, activate Color correction, go to and activate Texture boost, set all three sliders to max, then click Open detail window under the main window of Art >> boum!
Apart from this, without opening a detail window, the saved files differs a lot from the preview in Art. Might be related to this LUT.h thing below.
Backtrace:
Thread 106 "ART" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdde00700 (LWP 25937)]
0x0000555555fc883f in LUT<float>::operator[]<float, float, void> (
this=0x55555690db40 rtengine::Color::cachef, index=-nan(0x400000))
at /home/paul/art/rtengine/LUT.h:456
456 T p1 = data[idx];
(gdb) backtrace
#0 0x0000555555fc883f in LUT<float>::operator[]<float, float, void>(float) const (this=0x55555690db40 rtengine::Color::cachef, index=-nan(0x400000))
at /home/paul/art/rtengine/LUT.h:456
#1
#2
at /home/paul/art/rtengine/color.cc:1577
#3
#4
at /home/paul/art/rtengine/imagefloat.cc:854
#5
#6
at pthread_create.c:463
#7
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)
#0 0x0000555555fc883f in LUT<float>::operator[]<float, float, void>(float) const (this=0x55555690db40 rtengine::Color::cachef, index=-nan(0x400000))
at /home/paul/art/rtengine/LUT.h:456
#1
#2
at /home/paul/art/rtengine/color.cc:1577
#3
#4
at /home/paul/art/rtengine/imagefloat.cc:854
#5
#6
at pthread_create.c:463
#7
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)
Comments (13)
-
reporter
-
repo owner
- changed status to resolved
texture boost: fixed crash due to the generation of infinity values
Fixes
#35→ <<cset 8305574ffc6c>>
-
reporter
Segfault problem solved indeed. You’re faster than Microsoft!
Still a noticeable difference in preview and saved file (much darker), I’ll investigate that further.
-
repo owner
Notice the “1:1” icon in the texture boost tool… in other words, some discrepancy is expected (and hard to solve I’m afraid), especially when you push the sliders to the extremes…
-
reporter
I looked at both files (the raw in Art and the saved file) at 100%, because I noticed the 1:1 icon (and that’s where it crashed).
And putting sliders to their extremes is just part of testing your software! I want to rewrite my existing article about masks in ART, to include the brush mask as well. But this time I want to know exactly how they work and behave.
Regards, Paul.
-
repo owner
I looked at both files (the raw in Art and the saved file) at 100%, because I noticed the 1:1 icon (and that’s where it crashed).
Ah, sorry, that was unclear! I thought you meant that the zoomed-out preview was different from the 1:1 one.
A mismatch at 1:1 is indeed a bug, I’ll look into that.
EDIT: specifically, I was fooled by this quote:
Apart from this, without opening a detail window, the saved files differs a lot from the preview in Art.
-
reporter
Sorry if I was unclear. The thing I talk about is that the preview in Art (whole photo or at 100%) differs from the saved file.
Following: preview in Art, full photo, and resulting jpg file.
Under that: same at 100%.
-
reporter
- attached DSC_2544.art.masks-7.jpg.out.arp
And the arp file...
-
repo owner
it’s clear now, thanks!
-
reporter
Let’s drop this for the moment, I see this problem with one file but I can’t reproduce this behavior with other files (tried two).
What I notice is that the preview image at 100% turns very dark at several high values for Edge stopping, in the enclosed screenshot that value is 3.93 and iters are 4 (strength doesn’t seem to influence this).
At value 3.94 the image is much lighter but still too dark. Same for 3.95. A value of 3.96 turns the image near-black again. 3.97, 3.98, 3.99 again lighter, 4.00 near-black.
Seems to happen with iterations >1.
-
repo owner
@Paul Matthijsse I just pushed a new branch called
new-texture-boost, with a completely different implementation, that is much simpler, faster, and should not have the preview problems you are experiencing. I would be interested in your feedback about it. Note tough that this is not backwards compatible: it will still boost details/texture, but the results won’t be identical to the old version. I am not sure yet how to handle this, but for now let’s see if other people find it useful… -
reporter
Hello Alberto, two things. One: the preview equals the saved file now, so that’s okay. Two: it segfaults with the first slider set to -1.00, 2nd to 4.00, iters to 5. Again in that LUT.h file.
Thread 455 "ART" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff387e0700 (LWP 12669)]
0x0000555555fcc242 in LUT<float>::operator[]<float, float, void> (
this=0x555556907b40 rtengine::Color::cachef, index=-nan(0x400000))
at /home/paul/art.dbg/rtengine/LUT.h:456
456 T p1 = data[idx];
(gdb) backtrace
#0 0x0000555555fcc242 in LUT<float>::operator[]<float, float, void>(float) const (this=0x555556907b40 rtengine::Color::cachef, index=-nan(0x400000))
at /home/paul/art.dbg/rtengine/LUT.h:456
#10x0000555555ffdbc2 in rtengine::Color::computeXYZ2Lab(float) (f=-nan(0x400000)) at /home/paul/art.dbg/rtengine/color.cc:1417
#20x0000555555fd7e45 in rtengine::Color::XYZ2Lab(float, float, float, float&, float&, float&) (X=-nan(0x400000), Y=-nan(0x400000), Z=-nan(0x400000), L=@0x7fffb9ec01f0: -nan(0x400000), a=@0x7fffb9ae4c50: 1527.00439, b=@0x7fffba29b790: 3564.63037) at /home/paul/art.dbg/rtengine/color.cc:1547
#30x000055555605c02b in rtengine::Imagefloat::yuv_to_lab(int, int, float&, float&, float&) (this=0x7fff7c0506b0, y=410, x=1232, L=@0x7fffb9ec01f0: -nan(0x400000), a=@0x7fffb9ae4c50: 1527.00439, b=@0x7fffba29b790: 3564.63037)
at /home/paul/art.dbg/rtengine/imagefloat.cc:934
#40x0000555556059a45 in rtengine::Imagefloat::yuv_to_lab(bool) [clone ._omp_fn.16] (this=0x7904810ecc6c1600, multithread=211)
at /home/paul/art.dbg/rtengine/imagefloat.cc:922
#50x00007ffff29dd94e in () at /usr/lib/x86_64-linux-gnu/libgomp.so.1
#60x00007ffff25976db in start_thread (arg=0x7fff387e0700)
at pthread_create.c:463
#70x00007ffff22c088f in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) -
reporter
Hello, I see your msg just now. I'll have a look.
Op 24-03-2020 om 16:50 schreef agriggio:
- Log in to comment
