ART feature requests and discussion

Hi @agriggio , I have an issue with banding but I don’t know if you can do something (as it’s maybe in a library that you just use but you don’t have control on it).
Sometimes I have pictures with very “flat” gradients : big area but the difference between the 2 extremes colors is very small. So my picture has dithering to avoid banding.
When I watch the picture in the preview window, I can see awful banding, it’s normal, the window must render fast. But if I zoom enough, the banding vanishes.
But if I save a big file (say 15360x6532) to a smaller size (2560x1440), and from a 32 bits floating point to 16 bits, the final picture will have banding.

I suppose that the banding shows up during the save (immediately, I don’t use the queue). Have you chosen the way it is saved, like you use a library and you can choose the final quality (I didn’t see anything about this in preferences), or not ?


Other thing, the engine likes to crash when I do big zoom-in quickly : I zoom-in, and I zoom-in, and… If I zoom-in when the engine hasn’t regenerated the preview window fast enough after the previous zoom-in, sometimes it crashes. More often when smoothing things like chrominance (guided) or RGB (guided) with masks are active.

Best regards,
François.

Hi,
Adding support for transparency would be nontrivial unfortunately, as the underlying image representation doesn’t include an alpha channel…

Hi @Teto, can you share and example and the export settings you use? Also, did you try the same in other applications?

I didn’t try it in other applications because ART is my last program used in my workflow, I finish my picture with it.
The settings I use are the one available in ART, aka, when I save immediately, I save in png 16 bit and that’s it, I don’t see other settings available somewhere else.
Here an example :
image
This snapshot is taken from the preview window, you can see banding.
If I zoom in yellow area I continue to have banding :
image
until I zoomed enough :
image
Now, if save the picture with downsize (here from height 6432 to 1440), in png 16bit and in V4medium for color profile (so a good one), the area looks like this :
image
The area is taken from my preview window but is coherent with the saved picture.
I can send to you the 2 files if you want, but the fact is that dithering of the picture is changed in banding when you downsize the picture, it would be useful to keep the dithering, if it’s possible.

(sorry, the pictures are in jpeg, I copy/pasted directly from my capture system)

Hello! Did you notice that these photos are all black? At least on my pc they are.

Other thing, the engine likes to crash when I do big zoom-in quickly : I zoom-in, and I zoom-in, and… If I zoom-in when the engine hasn’t regenerated the preview window fast enough after the previous zoom-in, sometimes it crashes. More often when smoothing things like chrominance (guided) or RGB (guided) with masks are active.

This sounds similar to this:

In my case, the program freezes when I zoom in quickly an image that uses a HaldCLUT file that has been deleted from disk.

Indeed, same here. Is this intentional?

No, and I opened the last one from here and it’s OK.
Anyway, I’ll give you a link for the source since it’s uploaded (my connection is slow).

Edit : I have a good screen displaying Adobe1998, not sRGB.

Edit 2 : I’ve sent to you the message with the link.

I’ve encountered this problem too. Reliable crash on any image when zooming back and forth fast. Happens on my default preset with just some basic modules enabled (exposure, tone curve, noise reduction, impulse noise reduction, white balance, auto matched camera profile, profiled lens correction, raw CA correction).

It was happening on dev 1.8.2-30-g9d21fa0e2, I’ve just upgraded to latest dev 1.8.4-22-g1344959c4, and the issue is still there.

Have you tried doing the same in RawTherapee? In my case, zooming quickly in RT works with no crashes.

Yes, no crashes in RawTherapee 5.8, and also in ART 1.5.4 no crashes as well.

I’ll try to reproduce and understand what is going on – thanks for the info!

I’m using Windows 10, BTW. Maybe these crashes don’t happen on Linux.

Hi, I tried reproducing both on Linux and Windows (7 though, I don’t have 10), but failed. Is there anybody that can provide more detailed instructions? Thanks!

Sorry, I forgot to mention that I use Windows 10. I found that it happens more likely when I open a photo which doesn’t have any sidecar yet, and so it gets the default config applied (for my camera in according to my dynamic profile rules) on this first opening. If right after the opening I scroll the wheel to zoom-in rapidly a couple of times - it will crash (in ~90% cases).
Here is a small video:
2021-05-07_15-32-23.mkv (1.9 MB)

Let me know if I can help in any other way. Thank you for your effort!

I think it might be related to file browser thumbnails update.

Besides, I also noticed that sometimes after the crash when I reopen ART - it is missing some files in the file browser (2 or 3 photos, so it shows 50 instead of 53 for example). Clicking on the refresh button makes all the photos appear again in file browser. I cannot reproduce it.

Would you be able to run this with gdb and produce a backtrace? (There are instructions on rawpedia if needed)

I don’t have symbols, so what I got so far is:

Program received signal SIGSEGV, Segmentation fault.
0x00007ff7f77b2ee1 in ?? ()

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

I use this build:
keybase.pub/gaaned92/ART-W64NightlyBuilds/ART_master_1.8.4-22-g1344959c4_W64_Skylake_210506.7z

I suspect it’s a stack corruption indeed (seems like stack pointer is already invalid), so something on the stack was written out bounds.

Thanks for the quick reply – if you manage to try a debug build, maybe we can get more meaningful info. I tried again reproducing but failed…

Is there a debug build for windows anywhere? I couldn’t find it. I may try to build it myself later.