Liquify module in dt 3.2.1

I use dt 3.2.1 on Ubuntu 20.04 and on Windows 10. In both versions the the behaviour of the liquify module makes it more or less unusable. After placing two or three warps - for example with the point tool it is not possible to move points anymore. Sometimes one can remove warps by right-click, most of the times it doesn’t work. I was not able to find out a certain way of behaviour, sometimes the first few warps seem to work but after trying to modify them the behaviour changes and at a certain point darktable becomes very slow and unsresponsive or even crashes.
What happened with the module? It worked perfectly on dt 2.x

Can someone else confirm the same problems?

I don’t use this tool much, but seems to be working for me. 4 point tools and 1 curve added to image, was able to edit them and remove. Curve tool is a little slow, but not any more so than it’s ever been in my limited experience. I’m on Tumbleweed, dt 3.2.1 stable.

Maybe you’re just pushing the module harder than I did? What other modules do you have active? For my quick test I only had the normal defaults active (exposure, filmic, etc.).

Disable filmic, tone equalizer, denoise (profiled) before using. These modules are quite performance consuming and are recalculated after each move of an control point.

2 Likes

liquify is very time consuming it gets better with OpenCL and a fast computer.

Thanks for your reply! I don’t think I push it very hard - just applying two or three corrections and I could even live with the module being slower.
Up to now when using liquify on dt 3.x I usually activated liquify or retouch at the end of my workflow as both of them require a lot of performance and if I do it at the beginning every other module I activate feels laggy as well.

But anyway, I tried to switch off all other modules now and you’re right the liquify module works a bit better. But there still seems to be a bug when I try to grab the center point of a warp and move it around. Many times grabbing the central point ends up in moving the arrowhead instead of the central dot. Moving the mouse pointer over the different handles doesn’t activate them as before.

To sum it up - my experience is that the module now is a lot (!) slower than it was in dt 2.x and it even seems to have become buggy in the handling of edits. Maybe the problem is connected to the code that handles the selections (warp points, curves)

I had the same problem with warp handling and also on rotating gradient mask(not sure if it’s related). Knowing that it doesn’t happen only to me I’ll get more details and open an issue on GitHub.

Cheers!

Thank you!

Did you ever enter a bug report…I find the module unusable in its current state??

No, sorry. :persevere:
I’ll open an issue tomorrow morning.

Writing the issue, I’ve discovered that if you try to handle nodes zoomed in, it doesn’t work at all in my computer but if I try the same without zoom in, it works.

I guess it’s a responsiveness problem.

Issue: Node responsiveness problem with liquify nodes · Issue #6614 · darktable-org/darktable · GitHub

I had a somewhat similar issue of the crop module’s keystone adjustment points being hard to move, caused by the ‘reduce resolution of preview image’ option under darkroom options (I’m on git master). It was fixed, see Crop - keystone correction: correction guide hard to adjust · Issue #6219 · darktable-org/darktable · GitHub.

I thing the problem here is not exactly the same. It isn’t about precision because the target is bigger, in this case when you are inside of the node it should be highlighted and it doesn’t happen.

Of course, I may be wrong :slight_smile:

.@Pascal_Obry has implemented a fix for the issue[1]. If anyone can test it, it would be great.
Just in case, I’ll do it tomorrow.

Good night!

[1] po/fix liquify handles by TurboGit · Pull Request #6616 · darktable-org/darktable · GitHub

2 Likes

Thanks for the update I’ll have time maybe tomorrow…

Fix tested and working. It’s only a matter of being merged.

Good night

It’s been merged.

1 Like

Super, thanks to all of you! Now I‘m even more looking forward to the 3.4 release in December, to have this fix in the stable release.

I’m not taking credit, I’m just a user who spotted it in the change list :smiley:

You‘re right - thanks to @Pascal_Obry for locating and fixing the issue :grinning::+1:t2: