Project

General

Profile

Bug #12429

guided blend mask blur not guiding anything in some modules (works only between input and output color profile)

Added by Matthieu Moy 8 months ago. Updated 8 months ago.

Status:
Fixed
Priority:
Medium
Assignee:
Category:
Darkroom
Target version:
Start date:
12/01/2018
Due date:
% Done:

100%

Affected Version:
git master branch
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

The guided mask blur is awesome when it works, but seems to work only for modules in the Lab space, i.e. after the input color profile application and before the output color profile.

Try the exposure or profiled denoise (before input profile), or channel mixer (output profile), and there the "feathering radius" is almost equivalent to the "bluring radius" slider.

History

#1 Updated by Pascal Obry 8 months ago

  • Target version set to 2.6.0

This probably explain why I had trouble to use it, all my tries were with the exposure module! Would be really good to have a fix for 2.6!

#2 Updated by Heiko Bauke 8 months ago

Thanks for the bug report. Can reproduce the behavior. Will fix it as soon as possible. When do we have code freeze for 2.6?

#3 Updated by Heiko Bauke 8 months ago

As far as I can tell, there is no bug in the implementation of the feathering algorithm. For some (many?) images, however, the LAB representation (where brightness and color information are separated into different channels) is much more suitable to guide the mask.

#4 Updated by Matthieu Moy 8 months ago

I didn't test with many images, but I tested specifically with a high-contrast image (black rock on white snow) and the effect of guiding is not even visible. It starts being visible if I overexpose the image (like +2EV or more).

My guess is that it should be possible to make the algorithm work for these images by applying some coefficients to the channels before doing the blur (e.g. if applying +2EV works, multiplying the guide by 2 could work). Not sure whether there's an easy way to do that without ruining the performance. At worse, obviously, a conversion to Lab would do the trick but that's probably overkill.

In the current situation, the problem is that a user trying the feathering slider on the wrong module will most likely give up and decide that the slider is useless. Pascal had trouble understanding how it worked, it took me stg like 1 hour to understand why I was not getting anything interesting out of it. If there's no way to get it to work on non-Lab modules, I'd be in favor of hiding the slider in these modules to avoid misunderstanding.

#5 Updated by Pascal Obry 8 months ago

I'm just trying to know if this has a chance to be fixed today and then I can delay a bit the rc0 otherwise it will be in the rc1. As it is a new feature, I would really like to see this fixed for the rc0. Let me know what you think and what is the status. Thanks.

#6 Updated by Pascal Obry 8 months ago

I think that if we cannot fix this now we need to hide the slider otherwise we will have to keep backward compatibility with previous edit and this will be overkill!

#7 Updated by Pascal Obry 8 months ago

For RC0 if we do not have a fix I'll do that : https://github.com/darktable-org/darktable/pull/1868

Does that sounds ok to you?

#8 Updated by Pascal Obry 8 months ago

I have just announced the RC0. For now I had deactivate the guided-filter on RGB modules until we have a plan for them.

#9 Updated by Matthieu Moy 8 months ago

AFAIU, the Lab values are meant to be in [0.0, 100.0], while pre-input-color profile see values in [0.0, 1.0]. If so, would a multiplication by 100.0 do the trick?

Good that RC0 is there, and good that you (Pascal) have deactivated the slider temporarily. I just hope we'll get it back before the final release :-).

#10 Updated by Pascal Obry 8 months ago

  • Priority changed from Low to Medium
  • % Done changed from 0 to 50
  • Status changed from New to In Progress
  • Category set to Darkroom

And indeed I just tried it on Lab based module and it works great and is very impressive. As I said before all my testing during integration check was done with the exposure module and I was never able to get it working properly! Now I understand why all others said that it was impressive and quite a nice addition :)

Anyway, let's hope a fix can be found for RGB based modules.

#11 Updated by Heiko Bauke 8 months ago

This issue has been addressed in pull request #1869 . Tests & feedback are highly welcome.

#12 Updated by Pascal Obry 8 months ago

Working fine for me now. I'd like to have Matthieu feedback too.

#13 Updated by Pascal Obry 8 months ago

And of course commit: 4068ae92bfb86bf8a43fcad99d0aadcf4a047af5 must be reverted.

#14 Updated by Matthieu Moy 8 months ago

Works fine for me too. Both for pre-input-profile and post-output-profile modules I tested.

#15 Updated by Pascal Obry 8 months ago

Thanks Matthieu for testing.

I'll merge that then and will deactivate this feature for RAW based module (like RAW denoise) where the sliders are there but should not.

#16 Updated by Pascal Obry 8 months ago

  • % Done changed from 50 to 100
  • Status changed from In Progress to Fixed
  • Assignee set to Pascal Obry

#17 Updated by Matthieu Moy 8 months ago

I don't have the "deactivation for RAW" (yet?). And indeed, it triggers an "assert(0)" when you try to use it there ;-).

#18 Updated by Pascal Obry 8 months ago

Will be done in a moment.

#19 Updated by Pascal Obry 8 months ago

Patch committed now.

Also available in: Atom PDF