[darktable-dev] sharpen module
Hi, I just started to implement a simple (non-blind) deconvolution filter as an addition sharpening method. I plan to add this as an additional mode for the sharpening module. Looking at the code of the current unsharp mask method I realized that the module uses its own implementation of a gaussian blur filter. Is there any reason not to employ the one in src/common/gaussian.[ch]? Are there any concerns against simplifying the sharpening module's implementation and just calling the functions from src/common/gaussian.[ch]? The deconvolution method also needs to apply gaussian blur kernels and I would prefer to use the ones in src/common/gaussian.[ch] only. Heiko -- -- Number Crunch Blog @ https://www.numbercrunch.de -- Cluster Computing @ https://www.clustercomputing.de -- Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] sharpen module
Hello Heiko, > Looking at the code of the current unsharp mask method I realized that > the module uses its own implementation of a gaussian blur filter. Is > there any reason not to employ the one in src/common/gaussian.[ch]? Are > there any concerns against simplifying the sharpening module's > implementation and just calling the functions from > src/common/gaussian.[ch]? I think this is the right way; Aurélien did notice lot of code duplication while working on the GUI redesign. We just need to be sure that the algorithm in src/common/gaussian.[ch] is equivalent to the one in gaussian.[ch]. > The deconvolution method also needs to apply gaussian blur kernels and I > would prefer to use the ones in src/common/gaussian.[ch] only. Let's go with that if we are sure the algo are equivalent. Code duplication is not good in the long run. Thanks, -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] sharpen module
Hi, suggestion: add more options for the blur. In the following video "Matter machen/surface blur" is used for "perfect sharpening". https://www.youtube.com/watch?v=70eCvD4_aaE Chris Am 17.04.2019 um 20:16 schrieb Heiko Bauke: I just started to implement a simple (non-blind) deconvolution filter as an addition sharpening method. I plan to add this as an additional mode for the sharpening module. Looking at the code of the current unsharp mask method I realized that the module uses its own implementation of a gaussian blur filter. Is there any reason not to employ the one in src/common/gaussian.[ch]? Are there any concerns against simplifying the sharpening module's implementation and just calling the functions from src/common/gaussian.[ch]? The deconvolution method also needs to apply gaussian blur kernels and I would prefer to use the ones in src/common/gaussian.[ch] only. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] sharpen module
Hi, please don't do a deconvolution in the Lab color model. Natural blur is a phenomenon happening to photons and described by a convolution product. If you want to revert it, you need to use a physically meaningful color space, e.g. a linear one as close as possible to the spectral space. That would be camera RGB, linearly encoded (be sure the gamma is reverted if the input file is a JPEG/TIFF/PNG file), before it is messed up with non-linear transfer functions in the pipe (from Parseval's theorem of energy conservation in convolutions). The sharpening module happens too late in the pipe (after tone curves) and works in Lab, which is nonsensical (Lab == perceptual model built upon human vision : that means nothing in optics). I would squeeze it right after the denoising modules, but I'm not sure yet if it's better to have it before or after the lens correction. I have worked for 2 years on regularized blind deconvolutions, you can use my code and remove the kernel update if you want : * https://github.com/aurelienpierre/Image-Cases-Studies/blob/master/deconvolve.py * https://github.com/aurelienpierre/Image-Cases-Studies/blob/master/lib/deconvolution.pyx Also, Edgardo began to translate my Python code into a dt module 1.5 years ago (although the algo has changed). The major limitation was the performance : https://github.com/edgardoh/darktable/blob/rlucy/src/iop/rlucy_deblur.c Anyway, I have delayed this work because I wasn't ready to code it in C, but I would be glad to help. Good luck, Aurélien. Le 17/04/2019 à 20:16, Heiko Bauke a écrit : > Hi, > > I just started to implement a simple (non-blind) deconvolution filter > as an addition sharpening method. I plan to add this as an additional > mode for the sharpening module. > > Looking at the code of the current unsharp mask method I realized that > the module uses its own implementation of a gaussian blur filter. Is > there any reason not to employ the one in src/common/gaussian.[ch]? > Are there any concerns against simplifying the sharpening module's > implementation and just calling the functions from > src/common/gaussian.[ch]? > > The deconvolution method also needs to apply gaussian blur kernels and > I would prefer to use the ones in src/common/gaussian.[ch] only. > > > Heiko > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] sharpen module
Dear Pascal, Am 17.04.19 um 23:46 schrieb Pascal Obry: Let's go with that if we are sure the algo are equivalent. Code duplication is not good in the long run. the two implementations of the Gaussian filter work rather differently. Both are certainly not equivalent to each other in a mathematical sense. The question is just how much pixel peeping is required to observe a difference. In best case the difference is of no practical relevance. But this has to be tested. Thus, I would write (just for debugging) a new/additional sharpening module which just a copy of the existing one where the implementation of the Gaussian filter has been replaced. This would allow to make a direct comparison between the two filters. Heiko -- -- Number Crunch Blog @ https://www.numbercrunch.de -- Cluster Computing @ https://www.clustercomputing.de -- Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] sharpen module
Dear Aurélien Am 18.04.19 um 21:59 schrieb Aurélien Pierre: please don't do a deconvolution in the Lab color model. Natural blur is a phenomenon happening to photons and described by a convolution product. If you want to revert it, you need to use a physically meaningful color space, e.g. a linear one as close as possible to the spectral space. That would be camera RGB, linearly encoded (be sure the gamma is reverted if the input file is a JPEG/TIFF/PNG file), before it is messed up with non-linear transfer functions in the pipe (from Parseval's theorem of energy conservation in convolutions). The sharpening module happens too late in the pipe (after tone curves) and works in Lab, which is nonsensical (Lab == perceptual model built upon human vision : that means nothing in optics). I would squeeze it right after the denoising modules, but I'm not sure yet if it's better to have it before or after the lens correction. my main motivation to include the deconvolution into the existing sharpening module was to keep the number of modules small. Your concerns regarding the Lab space, however, are absolutely valid. Currently I am not sure if deconvolution should happen at a very early stage of the pipeline or at the end. Just considering the physics, I would certainly agree with your arguments to put the module at the beginning, possibly even just after demosaic. This is the right place when you want to reverse the effect of the point spread function of your optical system. I think, however, deconvolution might also be used as a---let's say---artistic tool to counteract all the interpolation and averaging effects that happen along the pixel pipe (demosaic, lens correction, etc.). Since quite some time I use a custom module, which allows me to use all sorts of GMIC filters in darktable. It works in RGB space at the end of the pixel pipe just before gamma. I use it mainly for the RL deconvolution. Employing a Gaussian kernel with a width of about one pixel (or slightly less) it allows me to turn reasonably sharp images into very sharp images and I am rather satisfied with the results. Imho, the results are better than the ones one gets by a traditional unsharp mask filter. Heiko -- -- Number Crunch Blog @ https://www.numbercrunch.de -- Cluster Computing @ https://www.clustercomputing.de -- Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] sharpen module
On Thu, Apr 18, 2019, at 13:00, Aurélien Pierre wrote: > The sharpening module happens too late in the pipe (after tone curves) > and works in Lab, which is nonsensical (Lab == perceptual model built > upon human vision : that means nothing in optics). I would squeeze it > right after the denoising modules, but I'm not sure yet if it's better > to have it before or after the lens correction. Interesting question... I suppose the case to consider would be something like a fisheye image being reprojected, where the transformation can be fairly extreme? Anyway, from a pragmatic perspective, it might make sense to implement this as a new module rather than within the sharpen module, given the need to place it in a different, specific part of the pipeline. Having it in the right place by default would be much easier for most users compared to being warned that they need to sort this out themselves. :) -- jys ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] sharpen module
On Thu, Apr 18, 2019, at 14:16, Heiko Bauke wrote: > I think, however, deconvolution might also be used as a---let's > say---artistic tool to counteract all the interpolation and averaging > effects that happen along the pixel pipe (demosaic, lens correction, etc.). In that case, maybe immediately after "liquify" would be the best default location? One thing to keep in mind is that AFAIK it's likely to be an "expensive" process, and having it earlier in the pipeline allows for the possibility of keeping its output cached for better performance while adjusting modules later in the pipeline. -- jys ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
