Enhanced Unsharp Mask in PhotoFlow - please test!

Definitely: on a technical and fingers-crossed level we are trying to restore the image, not sharpen it per se.

Same here in dt image doctor:

1 Like

@heckflosse I have taken the .pp3 from your PlayRAW contribution, and used it as a starting point for a direct comparison.

This is the RT processing without capture sharpening:

Then RT + capture sharpening

Finally my enhanced USM with settings that give a more or less similar amount of sharpening:

22%20PM

@anon41087856 in your DT implementation, what is exactly the input of the guided filter?

The bug should be fixed now, could you test the latest package from today?

Thanks!

RGB coming straight from the demosaicing module.

Hello @Carmelo_DrRaw

Just tested again on:

  • Windows 10 (64 bit);
  • CPU Intel I7;
  • RAM 8gb

Now, the crash regarding the Enhanced Unsharp Mask with BIG tiff images (70-80 Mb) is gone.
Everything works as expected.
I have tried also the zooming in-out and panning tools and all works fine :slight_smile:
Congratulations for fixing it!

I had some spare time and I have worked with this version for around 2 hours straight.
With Raw file pertaining to my Nikon D700 camera (around 9-10 Mb each) everything works extremely well: no complain whatsoever…

On the contrary with big TIFF files (70-80 Mb each) there are some operations which behave oddly.
I suppose Photoflow is not optimized to work smoothly with such big files on Windows 10 (yes, I do know you only have Mac and Linux to test it…) and trust me, this is not a criticism at all!

For example:

  • sometimes the crop tool is not applied to the image;
  • once in a while, very rarely tiles appear on the image (this is a very minor disturbance…) when sharpening;
  • Most importantly, Photoflow usually freezes when you save your tiff change as jpeg (“Export current image to raster format”).
    There are no particular information on the Cmd prompt and in the end, I usually shut down the Photoflow.exe through the Windows Task manager (CTR+ALT+DELETE shortcut).

I have recorded a short video (1:47 minutes; 2,5 Mb) with this crash when you save the TIFF as jpeg. There is also the oddity concerning the crop tool not applied to the TIFF image [1].
As anticipated, these bugs only occur with big TIFF images. With my NEF RAW files everything works fine (crop tool working; export to jpeg executed etc).

BTW, my monitor is extremely small (Asus notebook; 13 inch) and it is NOT the best one to test your GUIs. Bear with me :slight_smile:

[1] Dropbox - File Deleted

Could you tell me what are the dimensions (in pixels) of the image in your video for which the crop tool does not work properly?
Also, the long export time might be due to the large radius used in the sharpening. Could you check if things get faster with a smaller radius? I suspect that the program is not freezing, but just taking long to process the output image. Meanwhile I will insert some caching to speed-up the computation at large radius values…

In fact, PhotoFlow should be capable of dealing with very large images just fine, even better than other image processors (because it never requires the full image to be stored in the RAM for the computations). So if there are size limitations they are likely due to bugs.

Concerning the UI layout for small screens, I strongly suggest you to try with floating tool dialogs. You can enable then in the settings:


You will need to re-start the program for this to take effect.

In my experience, applying the guided filter to linear RGB values results in shadows that are blurred much more than highlights. The guided filter essentially estimates edges based on differences, and thus considers edges in shadow areas less strong than in highlights (at least from a perceptual point of view).
By applying the guided filter to log-encoded values, one replaces differences with ratios, and the edge estimation is much more uniform in shadows and highlights…

Sure, but the effects we are trying to revert happen in a linear space, so I think it’s important to keep this relationship. Depends if you want to increase local contrast or deblur.

I understand both stances, though there is a distinction to be made here. There is edge preservation and deblur in image processing, and there are real life edges that are there notwithstanding the photography.

Now, one could go about doing a 3d map of the scene and do a light field analysis, among other things, but in the context of consumer photography, you might want to fudge things to assist the guided filter. Of course, there are better methods out there, which I have been exploring privately.

Hello @Carmelo_DrRaw

Just tested again on Windows 10 with the same Asus notebook setup as previously reported (Intel I7; 8 gb RAM).

  1. As regards the lack of cropping actually it was my fault.
    Since I didn’t use a floating window I always applied the crop without closing its window in the end (by presseing the underneath “close” botton). Therefore it was not really applied when I added a new correction later on (unsharpening mask)…

  2. As regards Photoflow performance on Windows 10 I am under the impression (but I may be wrong…) that Rawtherapee is faster than Photoflow while zooming in-out the same NEF d700 image. Photoflow looks more laggy.
    Just for an example: with the same image (NEF 14 mb) I notice this difference.
    To make sure, I was really “right” I have tried to zoom-out VERY fast to reduce at the very most its visualization on both softwares.
    Afterwards, I have clicked on the icon 1:1 (100% magnification) to check how fast it was for both softwares: Rawtherapee looks faster.

BTW, with Photoflow this test led to me reproduce very easily a crash.
When you zoom-out very FAST (like crazy…) you usually always crashes the application.
I have tried several Nef D700 files (10 - 12 Mb) and all of them work fine in reproducing this crash

Hello @Carmelo_DrRaw

Could you check if things get faster with a smaller radius? I suspect that the program is not freezing, but just taking long to process the output image.

Yes. It is NOT a crash but a very long freeze due to compute the change I have applied by increasing the radius. Since I am testing the software I apply these “crazy” changes on purpose :slight_smile:

EDIT: as regards the crash while zooming out a Nef Image I have even restarted my Windows 10 computer but the crash persists and it is easily reproduced no matter what Nef image I open with Photoflow (Enhanced Unsharp branch).
You only need to zoom out like crazy (which again does not make much sense in real life…) :slight_smile:

Here is the backtrace (gdb output) for this crash:
PF::Image::do_update(): preparing pipeline #0
[Thread 13192.0x32c8 exited with code 0]
PF::Image::do_update(): updating pipeline #0
PF::Image::do_update(): pipeline #0 updated.
PF::Image::do_update(): preparing pipeline #1
PF::Image::do_update(): updating pipeline #1
[rebuild_chain]: reusing existing node for layer “RAW loader”.
[rebuild_chain]: reusing existing node for layer “RAW developer”.
rebuild_chain(): scaling layer “RAW developer” by 2.98023e-08

(photoflow.exe:13192): GLib-GObject-WARNING **: 21:31:59.102: value “16777216” of type ‘gint’ is invalid or out of range for property ‘vshrink’ of type ‘gint’
rebuild_chain(): vips_resize() failed.

Thread 7 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 13192.0x309c]
0x0000000067f281a1 in ?? ()
(gdb) seg logging file crash_zoom.txt
Undefined command: “seg”. Try “help”.
(gdb) thread apply all bt

Thread 111 (Thread 13192.0x2ee0):
#0 0x00007fff79fdfa54 in ?? ()
#1 0x00007fff79f74060 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 110 (Thread 13192.0x3264):
#0 0x00007fff79fdfa54 in ?? ()
#1 0x00007fff79f74060 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 29 (Thread 13192.0x3048):
#0 0x00007fff79fdcc14 in ?? ()
#1 0x00007fff771c7ff7 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 9 (Thread 13192.0x176c):
#0 0x00007fff79fdcc14 in ?? ()
#1 0x00007fff771c7ff7 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 8 (Thread 13192.0x33a4):
#0 0x00007fff76ea9a84 in ?? ()
#1 0x00007fff78c4260d in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 7 (Thread 13192.0x309c):
#0 0x0000000067f281a1 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
—Type to continue, or q to quit—

Thread 6 (Thread 13192.0x2f08):
#0 0x00007fff79fdfa54 in ?? ()
#1 0x00007fff79f74060 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 5 (Thread 13192.0x2174):
#0 0x00007fff79fdfa54 in ?? ()
#1 0x00007fff79f74060 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 4 (Thread 13192.0x337c):
#0 0x00007fff79fdfa54 in ?? ()
#1 0x00007fff79f74060 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 3 (Thread 13192.0x2718):
#0 0x00007fff79fdfa54 in ?? ()
#1 0x00007fff79f74060 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 13192.0x21ec):
#0 0x00007fff79fdfa54 in ?? ()
#1 0x00007fff79f74060 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 13192.0x2a40):
#0 0x00007fff76ea9a84 in ?? ()
#1 0x00007fff78c4260d in ?? ()
—Type to continue, or q to quit—
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

This is an unqualified comment but sometimes PF just does a whole lot of nothing. What I mean by that is that it almost feels like it is looping over the same thing over and over again, either an actual infinite loop or trying to do the same thing, upon failing redoing it. It is hard to tell by the concole output and I don’t have the time to use gdb to find out. Often this behaviour leads to a crash, could be a memory leak or something unstable. Having an old low end machine, the crash comes sooner than the forum average.

Hello @afre

This is an unqualified comment

Same here… :slight_smile:

Since Photoflow is tested mostly on Linux and Mac and it is right now a one-man business (that is, Carmelo_DrRaw) I always test it on Windows 10 with great amazement and surprise.

It is a very promising software (for its “layer structure”) although on Windows is a bit too “crashsy”. However, in all truth, I would be extremely surprised of the contrary (for the previous 2 reasons) :slight_smile:

Having an old low end machine, the crash comes sooner than the forum average.

And you must be blessed for this since:

  • Having and old computer allows you to REALLY test any software in depth;
  • With a very powerfull computer (CPU, RAM etc) you often mask the weakness of the softwares (e.g. its memory leaks and the like…).

In short, you should be selected as the number ONE tester of every open source in this forum :slight_smile:

I am not surprised. When the zoom level is changed, PhotoFlow has to drop and re-compute all the caches. This is one of the drawbacks of allowing to process multiple images of (almost) arbitrary size…

I managed to fix this. Next version will have a limit for the maximum allowed zoom level, which is enough to avoid the crash.

The most useful thing to do in this case is to provide me the .pfi file and a short description of what to do to reproduce the freeze/crash. I am now focusing as much as possible on bug hunting, so do not hesitate to complain :wink:

True in lots of cases, but for example thread synchronization issues are easier to trigger with a fast CPU with many cores…

The bottom line: more testers, more fun!

1 Like

Hello @Carmelo_DrRaw

Next version will have a limit for the maximum allowed zoom level, which is enough to avoid the crash.

Ok. Count me in for testing on Windows 10 :slight_smile:

I am now focusing as much as possible on bug hunting, so do not hesitate to complain

Good idea!

IMHO, Photoflow is too packed with features right now where most of them look quite experimentals (e.g. Gmic tools; Misc tools etc).

As far as I am concerned, it should be much better to reduce the clutter of options in order to keep only the most rock-solid.
In short, in my view, It should avoid to end up like G’MIC where you have more than 500 officials filters, with for instance a plethora of filters for sharpening, but most of them are very badly documented for a casual user (no tutorials, no tooltips on the GUIs etc) and often slow to use with BIG images :frowning:
And please, do not get me wrong: I am a huge fan of G’MIC…

1 Like

I have just tried to apply the guided filter on linear RGB values instead of log10, and I must say I like the results. It basically allows to achieve a more aggressive sharpening (particularly in mid-tones and highlights) while preserving even more the noise (particularly in the shadows).

Here is a new comparison:

Original

Linear processing

Log10 processing

I have added a temporary checkbox to easily switch between linear and log10 processing. The threshold values are internally adjusted to achieve a rather similar result in the mid-tones:

33%20PM

@Silvio_Grosso @gadolf @afre I’d be very much interested in your impressions… you’ll need to grab the “enhanced-usm” branch packages from 25th of October or later.

I don’t need to try it to give feedback. :stuck_out_tongue_closed_eyes:

1 Doing it in linear is what I would have done because we are interested in sharpening everything other than noise.

2 There is a disturbing negative lobe along already contrast-y edges; e.g., between the bug and background.

This is what the high threshold tries to suppress, and it is the part that seems to be more effettive in log encoding

Hello @Carmelo_DrRaw

This time I have tested the AppImage on Kubuntu 19.10 (KDE desktop).
The zooming out crash does not occur on Linux (it is an exclusively Windows related bug).
By and large, PhotoFlow is much more stable on Linux as it was expected. I only got a single crash while cropping an image but was unable to reproduce it later on

Back to the topic, I do like your implementation.
Based on my first quick impressions, for instance, the noise does not increase in the part of the image where there are no object to sharpen. Besides I get no halos around the edges.
Maybe this was expected but this is what is important for my editing :slight_smile:
In addition, the Enhanced Unsharp Mask tool is reasonably fast in my Virtual Box Machine, with 4 Gb of Ram dedicated (the host is Windows 10).

BTW, are there any shortcuts to zoom-in and zoom-out?
So far, I only use ctr+left mouse, to pan into the image. Unfortunately, I am unable to find any information on your Github web-page about the other shortcuts (in their respective tooltips they are not listed).

BTW, while testing the Sharpening tool and zooming-in out, once in while, some “tiles” (black squares) appear on the image. Maybe I am running out of CPU cores for the threading stuff (I have got an Intel I7 CPU)?

EDIT:
I have continued my testing on Kubuntu 19.10 and indeed PhotoFlow performs much better compared to Windows 10.
However, I have got another crash with 2 images opened:
NEF + JPEG.
As soon as I close the jpeg, the software always crashes.
Here is the video (VirtualBox machine…):

.