Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Tobias Ellinghaus]

Am Mittwoch, 21. Juni 2017, 11:39:30 CEST schrieb Dan Torop:
> Hi Tobias,

Hi Dan,

> I've been working on downscaling mosaiced images without (or with fewer)
> artifacts (https://redmine.darktable.org/issues/11167). Right now there's
> workable code for Bayer and X-Trans in git master. The main flaw is that
> highlights have magenta edges.
> 
> It would be great if before 2.4.0 I could code a slightly improved box
> filter and write SSE variants. (The Bayer SSE code is currently disabled,
> and there never was X-Trans SSE code.) I don't know if this will entirely
> fix https://redmine.darktable.org/issues/11340 (negative values for
> demosaic), and alas don't think it will fix the magenta edges to
> highlights.
> 
> I will be able to get to this again in early July.

any news on this? Did you start working on this already?

> Is that soon enough to
> make its way into 2.4.0? Additional improvement would be slightly better
> quality zoomed-in rendering in darkroom view, and faster initial rendering
> of the preview when loading a new image.
> 
> I've also been working on Wayland support
> (https://redmine.darktable.org/issues/11535). This is mostly done, but
> isn't worth enabling until GTK+ >= 3.22.16 makes its way into
> distributions. Wayland support doesn't seem to me to be critical for 2.4.0.

How far are you with the Wayland stuff? Your last comment in redmine sounds 
like you consider this to be complete for the time being?

> Dan

Tobias

[...]

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Ulrich Pegelow]

Am 20.06.2017 um 11:43 schrieb Tobias Ellinghaus:

Hello there,

we are currently thinking about having the next feature release (2.4.0)
earlier than Christmas.
In order to plan for that we need to know if anyone is currently working on
something that should go into the release. We would also need some hands on
deck to help review and polish pull requests.


Short remark on the user manual. I will be able to start work on the 
2.4.0 update early August and should have finished the English version 
round-about early September.


Ulrich


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Ulrich Pegelow]

Am 22.06.2017 um 20:23 schrieb Ulrich Pegelow:
OK, that sounds good. There should not be any OpenCL code dealing with 
non-floating point values at that place. But let me double-check that.




Reply to myself. This is what I get for the preview of an xtrans image:

[pixelpipe_process] [preview] using device 0
[dev_pixelpipe] took 0.000 secs (0.000 CPU) initing base buffer [preview]
[dev_pixelpipe] took 0.002 secs (0.002 CPU) processed `raw black/white 
point' on GPU, blended on GPU [preview]
[dev_pixelpipe] took 0.001 secs (0.001 CPU) processed `white balance' on 
GPU, blended on GPU [preview]
[dev_pixelpipe] took 0.000 secs (0.000 CPU) processed `highlight 
reconstruction' on GPU, blended on GPU [preview]
[dev_pixelpipe] took 0.022 secs (0.018 CPU) processed `demosaic' on GPU, 
blended on GPU [preview]
[dev_pixelpipe] took 0.002 secs (0.002 CPU) processed `base curve' on 
GPU, blended on GPU [preview]
[dev_pixelpipe] took 0.002 secs (0.002 CPU) processed `input color 
profile' on GPU, blended on GPU [preview]
[dev_pixelpipe] took 0.002 secs (0.000 CPU) processed `sharpen' on GPU, 
blended on GPU [preview]
[dev_pixelpipe] took 0.005 secs (0.000 CPU) processed `highpass' on GPU, 
blended on GPU [preview]
[dev_pixelpipe] took 0.002 secs (0.000 CPU) processed `output color 
profile' on GPU, blended on GPU [preview]
[dev_pixelpipe] took 0.008 secs (0.015 CPU) processed `gamma' on CPU, 
blended on CPU [preview]

[opencl_profiling] profiling device 0 ('GeForce GTX 1060 6GB'):
[opencl_profiling] spent  0.0004 seconds in [Write Image (from host to 
device)]

[opencl_profiling] spent  0.0001 seconds in rawprepare_1f
[opencl_profiling] spent  0.0001 seconds in whitebalance_1f_xtrans
[opencl_profiling] spent  0.0001 seconds in highlights_1f_clip
[opencl_profiling] spent  0.0002 seconds in markesteijn_initial_copy
[opencl_profiling] spent  0.0008 seconds in [Copy Buffer to Buffer (on 
device)]

[opencl_profiling] spent  0.0005 seconds in markesteijn_green_minmax
[opencl_profiling] spent  0.0012 seconds in markesteijn_interpolate_green
[opencl_profiling] spent  0.0024 seconds in markesteijn_solitary_green
[opencl_profiling] spent  0.0012 seconds in markesteijn_red_and_blue
[opencl_profiling] spent  0.0006 seconds in markesteijn_interpolate_twoxtwo
[opencl_profiling] spent  0.0011 seconds in markesteijn_convert_yuv
[opencl_profiling] spent  0.0011 seconds in markesteijn_differentiate
[opencl_profiling] spent  0.0003 seconds in markesteijn_homo_threshold
[opencl_profiling] spent  0.0007 seconds in markesteijn_homo_set
[opencl_profiling] spent  0.0007 seconds in markesteijn_homo_sum
[opencl_profiling] spent  0.0002 seconds in markesteijn_homo_max
[opencl_profiling] spent  0. seconds in markesteijn_homo_max_corr
[opencl_profiling] spent  0.0001 seconds in markesteijn_zero
[opencl_profiling] spent  0.0015 seconds in markesteijn_accu
[opencl_profiling] spent  0.0006 seconds in [Copy Image (on device)]
[opencl_profiling] spent  0.0003 seconds in markesteijn_final
[opencl_profiling] spent  0.0002 seconds in vng_border_interpolate
[opencl_profiling] spent  0.0002 seconds in vng_lin_interpolate
[opencl_profiling] spent  0.0005 seconds in vng_interpolate
[opencl_profiling] spent  0.0003 seconds in basecurve_lut
[opencl_profiling] spent  0.0006 seconds in colorin_clipping
[opencl_profiling] spent  0.0003 seconds in sharpen_hblur
[opencl_profiling] spent  0.0003 seconds in sharpen_vblur
[opencl_profiling] spent  0.0004 seconds in sharpen_mix
[opencl_profiling] spent  0.0003 seconds in highpass_invert
[opencl_profiling] spent  0.0009 seconds in highpass_hblur
[opencl_profiling] spent  0.0009 seconds in highpass_vblur
[opencl_profiling] spent  0.0004 seconds in highpass_mix
[opencl_profiling] spent  0. seconds in blendop_set_mask
[opencl_profiling] spent  0.0004 seconds in blendop_Lab
[opencl_profiling] spent  0.0006 seconds in colorout
[opencl_profiling] spent  0.0046 seconds in [Read Image (from device to 
host)]
[opencl_profiling] spent  0.0252 seconds totally in command queue (with 
0 events missing)

[dev_process_preview] pixel pipeline processing took 0.078 secs (0.073 CPU)

Certainly indicates some room for improvement. Currently we go the full 
Markesteijn demosaic way even for the thumbnail. It's not dramatic on 
this fast device but we could optimize by falling back to VNG or even 
linear.


That's an issue to be discussed further (but not here in this thread).

Ulrich
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Ulrich Pegelow]

Am 22.06.2017 um 19:31 schrieb Dan Torop:


Ulrich Pegelow  writes:

Oh no! I was thinking of the dt_iop_clip_and_zoom_demosaic_{half,third}_*() 
functions in imageop_math.c. Those don't have OpenCL implementations, though? 
Certainly getting into revising OpenCL code would be a way more invasive effort.



Well there are:

demosaic_vng.cl:clip_and_zoom_demosaic_third_size_xtrans()
demosaic_ppg.cl:clip_and_zoom_demosaic_half_size()



Oh no indeed! I haven't touched the floating point variants, and utterly failed 
to note this.

I've only been working on the non-float versions. These at least have no OpenCL 
equivalents, yes? They are only called from _init_f() in mipmap_cache.c for 
previews (which then never pass through the float downscale), as these are now 
downscaled while still mosaiced (which, alas, results in artifacts, but allows 
for processing mosaiced data through the pre-demosaic stages of the pipeline).


OK, that sounds good. There should not be any OpenCL code dealing with 
non-floating point values at that place. But let me double-check that.


Ulrich
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Dan Torop]

Ulrich Pegelow  writes:

>>> Please consider that changes in that place also will require changes to
>>> the equivalent OpenCL code which might be anything but trivial.
>> 
>> Oh no! I was thinking of the dt_iop_clip_and_zoom_demosaic_{half,third}_*() 
>> functions in imageop_math.c. Those don't have OpenCL implementations, 
>> though? Certainly getting into revising OpenCL code would be a way more 
>> invasive effort.
>> 
>
> Well there are:
>
> demosaic_vng.cl:clip_and_zoom_demosaic_third_size_xtrans()
> demosaic_ppg.cl:clip_and_zoom_demosaic_half_size()
>

Oh no indeed! I haven't touched the floating point variants, and utterly failed 
to note this.

I've only been working on the non-float versions. These at least have no OpenCL 
equivalents, yes? They are only called from _init_f() in mipmap_cache.c for 
previews (which then never pass through the float downscale), as these are now 
downscaled while still mosaiced (which, alas, results in artifacts, but allows 
for processing mosaiced data through the pre-demosaic stages of the pipeline).

I believe that the float downscale code (CPU or OpenCL) is called in demosaic 
in the case of low quality thumbnails or in the full pipeline when the image is 
zoomed out and "demosaicing for zoomed out darkroom mode" is "always bilinear 
(fast)".

>> I also remember now that I wanted to look into whether taking advantage of 
>> box filters being separable would speed up the code. But that would involve 
>> allocating a bit of memory so might also be something about which to be 
>> conservative.
>
> I have not looked into your code, so I don't know how large the base of 
> the box filters is. But probably you implement them as gliding window 
> filters. That's exactly something you can't implement efficiently in OpenCL.
>

Right now the implementation is way too naive, not even a gliding window, just 
iterating over the source pixels. But a gliding window would be better.

> We have that situation in some modules like highpass coming from times 
> much before OpenCL. In the end I implemented a gaussian filter in OpenCL 
> that tries to mimic the box filter as close as possible. Still that is 
> not an ideal way ...

I actually tried a Gaussian filter and overall it produced very nice results, 
but was slow and gave artifacts around the edges of highlights (see 
https://redmine.darktable.org/issues/11167#note-28). If I recall, those 
highlight artifacts were actually worse, as the larger sigma of the Gaussian 
filter spread them around a bit more. But your OpenCL Gaussian implementation 
looks really nice, and makes me want try it for the float variants which are 
called later on in the pipeline, when highlights shouldn't be a problem.

The upshot of 11167 seemed to be to implement good-enough and fast-enough 
downscaling code for now (CPU and SSE path), and find a better algorithm 
eventually. If the uint16 variants have no OpenCL equivalents, I think there's 
latitude there to improve the CPU/SSE paths for 2.4.0.

For the float variants, in the case of thumbnails and zoomed out darkroom view 
I don't see any artifacts with the extant code on the CPU path. I'm thinking 
it's fine for now to leave the float code as is, hence requiring no changes to 
the corresponding OpenCL code. But eventually to consider converting the float 
variants to use a Gaussian filter.

Dan

> Ulrich
>

[...]

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Ulrich Pegelow]

Am 22.06.2017 um 15:58 schrieb Dan Torop:

Ulrich Pegelow  writes:


Am 21.06.2017 um 18:03 schrieb Dan Torop:


I'd say that is well withing the time frame – provided it's not too invasive.



That is great. Should be a tweak to the Bayer downscale code (making 
start/endpoints of sample right), bringing that work to X-Trans, and then SSE 
variants.



Please consider that changes in that place also will require changes to
the equivalent OpenCL code which might be anything but trivial.


Oh no! I was thinking of the dt_iop_clip_and_zoom_demosaic_{half,third}_*() 
functions in imageop_math.c. Those don't have OpenCL implementations, though? 
Certainly getting into revising OpenCL code would be a way more invasive effort.



Well there are:

demosaic_vng.cl:clip_and_zoom_demosaic_third_size_xtrans()
demosaic_ppg.cl:clip_and_zoom_demosaic_half_size()


I also remember now that I wanted to look into whether taking advantage of box 
filters being separable would speed up the code. But that would involve 
allocating a bit of memory so might also be something about which to be 
conservative.


I have not looked into your code, so I don't know how large the base of 
the box filters is. But probably you implement them as gliding window 
filters. That's exactly something you can't implement efficiently in OpenCL.


We have that situation in some modules like highpass coming from times 
much before OpenCL. In the end I implemented a gaussian filter in OpenCL 
that tries to mimic the box filter as close as possible. Still that is 
not an ideal way ...


Ulrich





Ulrich


[...]




___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Dan Torop]

Ulrich Pegelow  writes:

> Am 21.06.2017 um 18:03 schrieb Dan Torop:
>>>
>>> I'd say that is well withing the time frame – provided it's not too 
>>> invasive.
>>>
>> 
>> That is great. Should be a tweak to the Bayer downscale code (making 
>> start/endpoints of sample right), bringing that work to X-Trans, and then 
>> SSE variants.
>> 
>
> Please consider that changes in that place also will require changes to 
> the equivalent OpenCL code which might be anything but trivial.

Oh no! I was thinking of the dt_iop_clip_and_zoom_demosaic_{half,third}_*() 
functions in imageop_math.c. Those don't have OpenCL implementations, though? 
Certainly getting into revising OpenCL code would be a way more invasive effort.

I also remember now that I wanted to look into whether taking advantage of box 
filters being separable would speed up the code. But that would involve 
allocating a bit of memory so might also be something about which to be 
conservative.

>
> Ulrich

[...]

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Ulrich Pegelow]

Am 21.06.2017 um 18:03 schrieb Dan Torop:


I'd say that is well withing the time frame – provided it's not too invasive.



That is great. Should be a tweak to the Bayer downscale code (making 
start/endpoints of sample right), bringing that work to X-Trans, and then SSE 
variants.



Please consider that changes in that place also will require changes to 
the equivalent OpenCL code which might be anything but trivial.


Ulrich

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Dan Torop]

Germano Massullo  writes:

> Il 21/06/2017 17:43, Tobias Ellinghaus ha scritto
>>> I've also been working on Wayland support
>>> (https://redmine.darktable.org/issues/11535). This is mostly done, but
>>> isn't worth enabling until GTK+ >= 3.22.16 makes its way into
>>> distributions. Wayland support doesn't seem to me to be critical for 2.4.0.
>> Ack, IMO Wayland is still to be considered experimental and not a top 
>> priority 
>> to fix.
> No intention of being pushy, but for information completeness, on Fedora
> Workstation Wayland is the default graphic server

Interesting... The code in git master should work with Wayland due to PR 1453, 
which requests GDK to use the XWayland compatibility layer as a backend in 
preference to Wayland. The continued work on bug 11535 should allow GTK/GDK to 
use the straight Wayland backend.

Wayland has exposed some quirks in darktable's UI code which X11 is too 
tolerant to notice. One might argue this is circular reasoning, and as these 
are problems only in the eyes of the Wayland display server.

[...]

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Tobias Ellinghaus]

Am Mittwoch, 21. Juni 2017, 21:44:30 CEST schrieb Germano Massullo:
> Il 21/06/2017 17:43, Tobias Ellinghaus ha scritto
> 
> >> I've also been working on Wayland support
> >> (https://redmine.darktable.org/issues/11535). This is mostly done, but
> >> isn't worth enabling until GTK+ >= 3.22.16 makes its way into
> >> distributions. Wayland support doesn't seem to me to be critical for
> >> 2.4.0.
> > 
> > Ack, IMO Wayland is still to be considered experimental and not a top
> > priority to fix.
> 
> No intention of being pushy, but for information completeness, on Fedora
> Workstation Wayland is the default graphic server

Good for them. Fedora has always been special. :-)

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Tobias Ellinghaus]

Am Mittwoch, 21. Juni 2017, 13:06:48 CEST schrieb David Vincent-Jones:
> I am running gtk3 3.20.10-5.3.1 ... but there are a number of

That's the broken version. It seems a recent 3.22 is only in Tumbleweed. I am 
sorry but there is nothing we can do, besides encouraging to upgrade or to 
look for another distribution. :-(

> 'secondary' packages that are carrying entirely different version numbers.
> PackageKit-gtk3-module 1.1.3-3.2
> gtk3-branding-openSUSE 42.1-3.1 . (I am running openSUSE 42.2)
> 
> No modules show any available updates.
> 
> Is there any possibility that it could be 'theme' related?

No, OpenSUSE is just shipping buggy software.

> David

Tobias

[]

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[David Vincent-Jones]

I am running gtk3 3.20.10-5.3.1 ... but there are a number of
'secondary' packages that are carrying entirely different version numbers.
PackageKit-gtk3-module 1.1.3-3.2
gtk3-branding-openSUSE 42.1-3.1 . (I am running openSUSE 42.2)

No modules show any available updates.

Is there any possibility that it could be 'theme' related?

David

On 06/21/2017 12:23 PM, Tobias Ellinghaus wrote:
> Am Mittwoch, 21. Juni 2017, 19:01:10 CEST schrieb David Vincent-Jones:
>> The image import problem still exists on my system requiring this
>> strange work-around (multiple tabbing and then a Ctrl a). This is a
>> nuisance apart from anything else. Is there any light at the end of this
>> tunnel and a fix in sight?
>>
>> I am running the latest git on OpenSUSE with XFCE desktop.
> 
> What version of GTK3 are you having installed? IIRC it was a bug in that 
> library.
> 
>> David
> 
> Tobias
> 



signature.asc
Description: OpenPGP digital signature

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Germano Massullo]

Il 21/06/2017 17:43, Tobias Ellinghaus ha scritto
>> I've also been working on Wayland support
>> (https://redmine.darktable.org/issues/11535). This is mostly done, but
>> isn't worth enabling until GTK+ >= 3.22.16 makes its way into
>> distributions. Wayland support doesn't seem to me to be critical for 2.4.0.
> Ack, IMO Wayland is still to be considered experimental and not a top 
> priority 
> to fix.
No intention of being pushy, but for information completeness, on Fedora
Workstation Wayland is the default graphic server
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Tobias Ellinghaus]

Am Mittwoch, 21. Juni 2017, 19:01:10 CEST schrieb David Vincent-Jones:
> The image import problem still exists on my system requiring this
> strange work-around (multiple tabbing and then a Ctrl a). This is a
> nuisance apart from anything else. Is there any light at the end of this
> tunnel and a fix in sight?
> 
> I am running the latest git on OpenSUSE with XFCE desktop.

What version of GTK3 are you having installed? IIRC it was a bug in that 
library.

> David

Tobias

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[johannes hanika]

heya,

On Thu, Jun 22, 2017 at 4:35 AM, Moritz Mœller (The Ritz)
 wrote:
> On June 20, 2017 18:34:27 Roman Lebedev  wrote:
>>
>> On Tue, Jun 20, 2017 at 5:55 PM, Moritz Moeller 
>> wrote:
>>>
>>> On 20.6.17 11:43 , Tobias Ellinghaus wrote:
>>> I'm using a local build with [...] Wolfgang Mader's
>>> modern monochrome modules since about 4 months and wouldn't want to miss
>>> either.
>>> https://github.com/wmader/darktable/tree/color2gray
>>
>> That was merged initially, currently resides as a preset in "color
>> look up table" module
>
>
> This module has a parameter. How can this work with a single look up
> table???

but did that parameter really change anything? i was under the
impression that the changes were really cosmetic and ignorantly
removed it..

-jo

> .mm
>
>
>
>
>
> ___
> 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] Planning of the upcoming 2.4.0 release

[Roman Lebedev]

On Wed, Jun 21, 2017 at 7:35 PM, Moritz Mœller (The Ritz)
 wrote:
> On June 20, 2017 18:34:27 Roman Lebedev  wrote:
>>
>> On Tue, Jun 20, 2017 at 5:55 PM, Moritz Moeller 
>> wrote:
>>>
>>> On 20.6.17 11:43 , Tobias Ellinghaus wrote:
>>> I'm using a local build with [...] Wolfgang Mader's
>>> modern monochrome modules since about 4 months and wouldn't want to miss
>>> either.
>>> https://github.com/wmader/darktable/tree/color2gray
>>
>> That was merged initially, currently resides as a preset in "color
>> look up table" module
>
>
> This module has a parameter. How can this work with a single look up
> table???
Dunno, i'm simply stating the current status:

commit cf98370e253590e3a6e5844433a0cfae8e3df126
Author: johannes hanika 
Date:   Sun Nov 20 08:15:20 2016 +1300

   monochrome: remove module. use clut+local contrast

   clut has the hk-mono preset, local contrast (optionally) uses the
   local laplacian filter.

diff --git a/src/iop/mm.c b/src/iop/mm.c
deleted file mode 100644
index 19293c644..0
--- a/src/iop/mm.c
+++ /dev/null


> .mm
Roman.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[David Vincent-Jones]

The image import problem still exists on my system requiring this
strange work-around (multiple tabbing and then a Ctrl a). This is a
nuisance apart from anything else. Is there any light at the end of this
tunnel and a fix in sight?

I am running the latest git on OpenSUSE with XFCE desktop.

David
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[The Ritz]

On June 20, 2017 18:34:27 Roman Lebedev  wrote:

On Tue, Jun 20, 2017 at 5:55 PM, Moritz Moeller  wrote:

On 20.6.17 11:43 , Tobias Ellinghaus wrote:
I'm using a local build with [...] Wolfgang Mader's
modern monochrome modules since about 4 months and wouldn't want to miss
either.
https://github.com/wmader/darktable/tree/color2gray

That was merged initially, currently resides as a preset in "color
look up table" module


This module has a parameter. How can this work with a single look up table???

.mm




___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Colin Adams]

I don't use Wayland for that very reason.

On Wed, 21 Jun 2017 at 17:04 Dan Torop  wrote:

>
> Tobias Ellinghaus  writes:
>
> > Am Mittwoch, 21. Juni 2017, 11:39:30 CEST schrieb Dan Torop:
>
> [...]
>
> >> I will be able to get to this again in early July. Is that soon enough
> to
> >> make its way into 2.4.0? Additional improvement would be slightly better
> >> quality zoomed-in rendering in darkroom view, and faster initial
> rendering
> >> of the preview when loading a new image.
> >
> > I'd say that is well withing the time frame – provided it's not too
> invasive.
> >
>
> That is great. Should be a tweak to the Bayer downscale code (making
> start/endpoints of sample right), bringing that work to X-Trans, and then
> SSE variants.
>
> [...]
>
> > Ack, IMO Wayland is still to be considered experimental and not a top
> priority
> > to fix.
>
> Indeed. And it seems that Nvidia proprietary drivers and Wayland don't
> interact well (something about EGLStreams vs. GBM). In which case, Nvidia
> GPU users may not be deep into Wayland...
>
> [...]
>
> ___
> 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] Planning of the upcoming 2.4.0 release

[Dan Torop]

Tobias Ellinghaus  writes:

> Am Mittwoch, 21. Juni 2017, 11:39:30 CEST schrieb Dan Torop:

[...]

>> I will be able to get to this again in early July. Is that soon enough to
>> make its way into 2.4.0? Additional improvement would be slightly better
>> quality zoomed-in rendering in darkroom view, and faster initial rendering
>> of the preview when loading a new image.
>
> I'd say that is well withing the time frame – provided it's not too invasive.
>

That is great. Should be a tweak to the Bayer downscale code (making 
start/endpoints of sample right), bringing that work to X-Trans, and then SSE 
variants.

[...]

> Ack, IMO Wayland is still to be considered experimental and not a top 
> priority 
> to fix.

Indeed. And it seems that Nvidia proprietary drivers and Wayland don't interact 
well (something about EGLStreams vs. GBM). In which case, Nvidia GPU users may 
not be deep into Wayland...

[...]

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Tobias Ellinghaus]

Am Mittwoch, 21. Juni 2017, 11:39:30 CEST schrieb Dan Torop:
> Hi Tobias,
> 
> I've been working on downscaling mosaiced images without (or with fewer)
> artifacts (https://redmine.darktable.org/issues/11167). Right now there's
> workable code for Bayer and X-Trans in git master. The main flaw is that
> highlights have magenta edges.
> 
> It would be great if before 2.4.0 I could code a slightly improved box
> filter and write SSE variants. (The Bayer SSE code is currently disabled,
> and there never was X-Trans SSE code.) I don't know if this will entirely
> fix https://redmine.darktable.org/issues/11340 (negative values for
> demosaic), and alas don't think it will fix the magenta edges to
> highlights.
> 
> I will be able to get to this again in early July. Is that soon enough to
> make its way into 2.4.0? Additional improvement would be slightly better
> quality zoomed-in rendering in darkroom view, and faster initial rendering
> of the preview when loading a new image.

I'd say that is well withing the time frame – provided it's not too invasive.

> I've also been working on Wayland support
> (https://redmine.darktable.org/issues/11535). This is mostly done, but
> isn't worth enabling until GTK+ >= 3.22.16 makes its way into
> distributions. Wayland support doesn't seem to me to be critical for 2.4.0.

Ack, IMO Wayland is still to be considered experimental and not a top priority 
to fix.

> Dan

Tobias

[...]

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Roman Lebedev]

On Wed, Jun 21, 2017 at 12:17 PM, Tobias Ellinghaus  wrote:
> Am Mittwoch, 21. Juni 2017, 09:33:13 CEST schrieb Robert William Hutton:
>> On 21/06/17 04:47, Germano Massullo wrote:
>> > It would be also interesting to know if there will be changes in
>> > darktable dependencies, so that package maintainers can early start
>> > working on them
>>
>> I'll do some testing and create a new page on the wiki for 2.4 based on
>> the one for 2.2:
>>
>> https://redmine.darktable.org/projects/darktable/wiki/Building_darktable_22
>>
>> Does anyone know if there are any new deps?
>
> One thing that comes to mind is the switch from Lua 5.2 to 5.3. IIRC we also
> bumped the required CMake version, but I am not sure about that and would have
> to dig through the git log. I'll help assembling the changed deps eventually.
Lua 5.3
CMake 3.1
Required: GCC 4.8 / clang 3.3   Recommended: GCC 5.0 / clang 3.5
New dependency: zlib

>> Regards,
>>
>> Rob
>
> Tobias
Roman.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Tobias Ellinghaus]

Am Mittwoch, 21. Juni 2017, 09:33:13 CEST schrieb Robert William Hutton:
> On 21/06/17 04:47, Germano Massullo wrote:
> > It would be also interesting to know if there will be changes in
> > darktable dependencies, so that package maintainers can early start
> > working on them
> 
> I'll do some testing and create a new page on the wiki for 2.4 based on
> the one for 2.2:
> 
> https://redmine.darktable.org/projects/darktable/wiki/Building_darktable_22
> 
> Does anyone know if there are any new deps?

One thing that comes to mind is the switch from Lua 5.2 to 5.3. IIRC we also 
bumped the required CMake version, but I am not sure about that and would have 
to dig through the git log. I'll help assembling the changed deps eventually.

> Regards,
> 
> Rob

Tobias

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Robert William Hutton]

On 21/06/17 04:47, Germano Massullo wrote:

It would be also interesting to know if there will be changes in
darktable dependencies, so that package maintainers can early start
working on them


I'll do some testing and create a new page on the wiki for 2.4 based on 
the one for 2.2:


https://redmine.darktable.org/projects/darktable/wiki/Building_darktable_22

Does anyone know if there are any new deps?

Regards,

Rob
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Germano Massullo]

It would be also interesting to know if there will be changes in
darktable dependencies, so that package maintainers can early start
working on them
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Planning of the upcoming 2.4.0 release

[Roman Lebedev]

On Tue, Jun 20, 2017 at 5:55 PM, Moritz Moeller  wrote:
> On 20.6.17 11:43 , Tobias Ellinghaus wrote:
>>
>> In order to plan for that we need to know if anyone is currently working
>> on
>> something that should go into the release. We would also need some hands
>> on
>> deck to help review and polish pull requests.
>
>
> I'm using a local build with Heiko Bauke's haze removal and Wolfgang Mader's
> modern monochrome modules since about 4 months and wouldn't want to miss
> either.
>
> https://github.com/wmader/darktable/tree/color2gray
That was merged initially, currently resides as a preset in "color
look up table" module

> https://github.com/rabauke/darktable/tree/haze_removal
What Pascal said.

> Modern monochrome could use some more algorithms. Their parameters and
> naming should also be reviewed by some UX savvy developer.
> Someone should also check it doesn't clip.
> But it is already useful as-is.
>
> Cheers,
>
>
> .mm
Roman.

> ___
> 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] Planning of the upcoming 2.4.0 release

[Pascal Obry]

Le mardi 20 juin 2017 à 16:55 +0200, Moritz Moeller a écrit :
> https://github.com/rabauke/darktable/tree/haze_removal

This one is already committed on master.

-- 
  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] Planning of the upcoming 2.4.0 release

[Pascal Obry]

Hi Tobias,

we are currently thinking about having the next feature release (2.4.0)
> earlier than Christmas.
>

Good news!


> In order to plan for that we need to know if anyone is currently working on
> something that should go into the release.


I do have a merge-request for the mask undo support. I would like to have
this in 2.4 if possible. I'm using it locally since some time.


> We would also need some hands on
> deck to help review and polish pull requests.
> In the past development cycle we added a few things that surely need more
> testing, so I expect the RC phase to be longer than usual. That might even
> justify merging things that are not 100% prefect. But that will be decided
> on
> a case-by-case basis.
>

I think the mask undo may fall into this category. The undo support is not
trivial and it is better to have lot of tester before the final release.

Cheers,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://photos.obry.net
  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