ART feature requests and discussion

Got it:
commit 2c2fdd847b22608cf07d0a85d57305e72e559268
2020-11-23 crophanlder: avoid unnecessary pixbuf copies

Seems like its wrong buffer size specified here:
cropPixbuf = resize_lanczos(cropPixbuf, imw, imh, czoom);
and here:
cropPixbuftrue= resize_fast(cropPixbuftrue, imw, imh, czoom);

@agriggio, could you please take a look at it?

1 Like

Excellent work, thanks! I’ll take a look asap :+1:

… and yet, I don’t see any obvious reason why that change should be the culprit :man_shrugging:
The lines you mention use the correct size (imw and imh are the dimensions of the output buffer, not the input).
Can you try testing the latest master but using the version of rtgui/crophandler.cc attached here?
crophandler.cc (17.8 KB)

That’s unfortunate, seems like the issue is somewhere else, and is just masked and not reproducing without this change in 2c2fdd847b2.
I checked it again today to be sure - version 2c2fdd847 crashes in less than a minute of testing, previous version a17fea152 doesn’t (in ~20 mins of testing).

Tried, it crashes the same way unfortunately.

Thanks – that exactly what I was expecting :frowning: confirms that the change is not the culprit…

Hi again,

would you be able to describe in more detail your testing procedure? (and your configuration if not the default)
Thanks!

Nothing special:

  1. Open ART
  2. Open some photo
  3. Start zooming randomly back and forth in the range of approx. 16%-100% zoom.
  4. It will crash right away or during the next ~60 seconds.

Next things are just subjective feeling:

  1. if it hasn’t crashed in a minute, I’m closing the photo and open it again (without restarting ART).
  2. The more modules are enabled, the faster it will crash.
  3. Sometimes for whatever reason it’s getting hard to get a reproduce. Yesterday actually I had to do bisection three times because I incorrectly marked some versions as good after ~3 mins of testing without a crash. When I tested them again, they crashed after 2-5 mins of testing.
  4. Seems like I can’t reproduce it when it’s the only photo in its folder? (Only one file in file explorer)
  5. Some other stuff like that which apparently tries to drove me crazy.

My configuration is mostly default, what I changed is:

  1. set multi tab mode
  2. force linear scale
  3. both fonts are set to Tahoma Normal 8
  4. pan rate amp 1
  5. uncheck use bundled profiles
  6. remove all the default dynamic profiles
  7. uncheck sounds->enable

Thanks for looking into it. I have a feeling that you won’t be able to get a reproduce because of VM. I think at this point we might try something like asan or PVS studio.

I normally run with asan on in debug builds, but only on Linux. I’ll try also on win – let’s hope it catches something…

I’ve tried the 1.9 version, and ART no longer freezes when rapidly zooming in and out an image that uses a HaldCLUT file that has been deleted from disk:

I’ll be doing some more tests but apparently my issue has been solved.

Thanks!

I just tried it. I’m on 1.9 Linux, self compiled and I just tried for 5 minutes of zooming in/out/100%/full screen/shrinking…

No problem. My computer with an older AMD FX-8350 is not maxing out, but hovering around 70%.

Syv

Hi @agriggio,

I have another bug with zooming, it’s not a crashing one :smiley: but still - sometimes image shifts for a moment when I zoom. It happens when I zoom with mouse wheel and also when I zoom using f or z buttons.
Here is a video how it looks like:
2021-05-30_21-43-24.mkv (8.2 MB)

This bug was introduced when we were experimenting with the fixes for the crashing bug (around 18-21 May). I remember I noticed this bug when it was introduced, but I though it was from one of the experimenting builds, so I didn’t tell you about it. But now I’ve just installed 1.9.1 nightly build from gaaned92, and I see this bug in this version.

Hi @agriggio

Two things bother me:

  • the artefact was not apparent in the preview. Is there a way to identify this problem in order to correct some adjustment? Or could the values be clipped to zero at input of texture boot or a warning?

  • when looking at the raw histogram/tooltip, I see minimum value is 0 for the three channels, although minimum values are (-8,-9,-10). Beyond that, I have difficulties to interpret the different values displayed. Is there some explanation somewhere?

Thanks @agriggio

Hi,

That’s strange, as I saw it clearly on my screen… (Inside art I mean).
Anyway, I’ve been trying to solve this problem with the texture boost for a while now, but so far without success. I’ll try again…

I think that using a luminance mask can be a good idea because there is no use to boost texture in black zones.
The problem is that, next time, I can forget to use it.

I think I fixed it now – the problem was in the perceptual curve, it was only made more evident by texture boost

All my thanks @agriggio :grinning: :+1:

Hi,

how can i mark the currently opened image in Editor as “to be deleted” in “Multi Editor Tab Mode”?
In “Single Editor Tab Mode” i can press “Del”, but this doesn’t work in Multi Editor Tab Mode. I need to go back the file browser and search for the image i want to delete.

regards
René

I guess that’s the only way at the moment, sorry. Does this happen so often though? Just trying to understand the use case…

Hi Alberto,

thanks for the quick reply, making the “Del” keybinding work in “Multi Editor Tab Mode” would be helpfull for my workflow when editing a series of similar images:

  • preselect the images in “Inspect” mode and delete obviously “bad” images
  • batch open the remaining images in Editor mode
  • apply some basic adjustments
  • delete more images that aren’t good enough to keep

So i have a bunch of say 10 images and after the first editing steps i decide to keep only 3 and 7 should be deleted.

Hi Alberto @agriggio , would you be able to look at it?
Thank you.