Re: [darktable-dev] local contrast -> laplacian filter seems to be broken
On Saturday, 17 November 2018 16:28:02 CET johannes hanika wrote: > hi, > > this sounds weird, since the last changes to the core of that > algorithm seem to be from 2017. > > the bug report rawfiner linked may be related to this commit: > 911133c87b45be22251cf7252ed729d1632a27b2 and that > 51bfe2f29411c0146d0aea70bdf073647d606a40 (i.e. this is just how it > works if you don't want to spend the full compute every time). > > was your image the result of an export? high quality option checked? > or a screen grab from darkroom mode? if it only happens spuriously > with opencl there may be a memory allocation issue on the GPU? if > there are any new processes claiming some of that for themselves > running in the background after a system upgrade maybe? This happende in darkroom and in the export and if I turned off OpenCL it works in darkroom. It could also be a bug in the ROCm OpenCL implementation. Cheers, Andreas -- Andreas Schneider a...@cryptomilk.org GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] local contrast -> laplacian filter seems to be broken
hi, this sounds weird, since the last changes to the core of that algorithm seem to be from 2017. the bug report rawfiner linked may be related to this commit: 911133c87b45be22251cf7252ed729d1632a27b2 and that 51bfe2f29411c0146d0aea70bdf073647d606a40 (i.e. this is just how it works if you don't want to spend the full compute every time). was your image the result of an export? high quality option checked? or a screen grab from darkroom mode? if it only happens spuriously with opencl there may be a memory allocation issue on the GPU? if there are any new processes claiming some of that for themselves running in the background after a system upgrade maybe? cheers, jo On Sat, Nov 17, 2018 at 6:01 AM Andreas Schneider wrote: > > Hi, > > the local contrast laplacian filter doesn't work anymore, it produces halos > and strange artifacts. Here is just one example image showing the issue: > > https://xor.cryptomilk.org/darktable/dt_local_contrast_laplacian.jpg > > Was perfectly fine some days ago. > > > Andreas > > > -- > Andreas Schneider a...@cryptomilk.org > GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D > > > ___ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] UI issues / masks
Well, that's a bit complicated. First: for drawn mask the invert option is part of the "combine mask" feature. I could have taken mask inversion into a separate combobox but that would have added a further gui element. The polarity is closely related to how we combine mask contributions, exclusive or incluse, respectively. Let's say that m1, m2, ... are the individual mask contributions like L-channel, a-channel, b-channel plust the drawn mask. The final mask M is then generated like the following. For exclusive combination: M = m1 * m2 * m3 * ... For inclusive combination: (1 - M) = (1 - m1) * (1 - m2) * (1 - m3) * ... In exclusive mode if one of the contributing mask is zero for a given pixel then M is zero as well regardless of the other contributions. You can easily exclude image parts by excluding them step by step with the contributing masks. In inclusive mode you can likewise easily include parts of the image like selecting all image parts with a given range of L values and another part of the image with a certain range of a values. Inclusive mode is a bit less easy to handle practically because by default all pixels are already selected in the respective gradient sliders. This is a different thing than inverting the final mask because you can apply polarity to the individual mask elements (parametric mask channels and drawn mask) at your liking. If you toggle all polarities, then that's the same as inverting the final mask. The ying-yang toggle does exactly this. Ulrich Am 16.11.18 um 08:25 schrieb Heiko Bauke: Hi, I am thinking about how to simplify the UI elements and will probably implement something in the direction of https://github.com/darktable-org/darktable/pull/1831#issuecomment-439291491 although I also agree with https://github.com/darktable-org/darktable/pull/1831#issuecomment-439299588 I am wondering why we have a "polarity button" for drawn masks _and_ an "invert mask" option? The latter is only available "drawn mask" is selected but not if "drawn & parametric mask" is selected. Is this just for historical reasons or is there a deep reason. To me the "invert mask" option seems to be redundant (even after reading the corresponding sections in the manual again). Heiko ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Feature request (Cropping module GUI)
* Pascal Obry (pas...@obry.net) [181117 00:40]: * Subject: Re: [darktable-dev] Feature request (Cropping module GUI): > Le vendredi 16 novembre 2018 ?? 15:25 -0700, Alan Lundin a ??crit : > > Is there some reason the aspect ratio can't be specified with two > > input boxes: x : y ? > > That's already possible : x / y > > See the manual. How cool is that? I can't believe I missed it. Thanks. --alan ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Feature request (Cropping module GUI)
Hi, idea: "snap" to common values during drawing of the rectangle: - original ratio - 16:9 - 3:2 - 1:1 etc. Chris Am 16.11.2018 um 21:50 schrieb Jan Ingwer Baer: Of course DT should not round, but it should show the Ratio with an integer for the small-side. For me showing 8.2/5 or 3.28/2 (with the pixel-ratio of the OP) is much more meaningful then 1.62/1. I think it should be possible to select a usable integer numerator/denominator based on the fractional ratio. If the user wants to create a crop with one of the common aspect ratios showing it as simple float makes it very challenging to find the right values. For example : The user wants to create a crop with 16/9. Displaying the aspect ratio as 1.77/1 is not a big help. The challenge is to find the right integer. My idea is to define ratio ranges for selection : 1.2 - 1.4 : set denominator to 3 gives 3.6/3 - 4.2/3 ( ~4/3) 1.4 - 1.6 : set denominator to 2 gives 2.8/2 - 3.2/2 ( ~3/2) 1.6 - 1.9 : set denominator to 9 gives 14.4/9 - 17.1/9 (~16/9) ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
