Re: [darktable-dev] unused feature "blend only lightness"

[Ulrich Pegelow]

Am 01.02.20 um 13:27 schrieb Heiko Bauke:

Hi,

all blend modes that operate in Lab space have some special treatment 
for the case that a module sets the flag IOP_FLAGS_BLEND_ONLY_LIGHTNESS. 
  However, I cannot find any module that actually sets this flag. 
Furthermore, it seams to me not reasonable why the behavior of a blend 
mode should depend on a module flag.


Can we get rid of this?  Is there any good reason why we have this in 
darktable?


I think yes. I remember faintly that in the very early days of blending 
(+8 year ago) there have been a use case but that has been overcome 
shortly after. So this in fact a stale left-over.


Ulrich

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

Re: [darktable-dev] Feature freeze for 3.0

[Ulrich Pegelow]

Hi,

frankly speaking I am still using the 2.6 branch and have no experience 
of any of the 2.7 features at all. I would be happy if someone closer to 
the recent development (Bruce?) could take over the manual.


Best wishes

Ulrich

Am 13.08.19 um 17:42 schrieb Pascal Obry:


Hi Matthieu,

I fully agree here. I'm not the maintainer of the documentation so I
cannot speak for Ulrich.

That being said, I can certainly ping developers to start a draft of
the code they have introduced in dt 3.0.

I have noted that Bruce will be happy to help doing the preparation of
the documentation from draft to final version. That's really nice,
thanks Bruce for stepping in!

So let's try to achieve that, we'll see how it works.

Cheers,



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

Re: [darktable-dev] Update usermanual on website

[Ulrich Pegelow]

@Aurelien: any update on that?

Am 09.01.19 um 18:48 schrieb Ulrich Pegelow:

Am 09.01.19 um 09:49 schrieb Andreas Schneider:

Did the documentation for the color balance module get updated?



No, it itsn't. So we have a least two updates which are still missing.

Ulrich

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

Re: [darktable-dev] Update usermanual on website

[Ulrich Pegelow]

Am 09.01.19 um 09:49 schrieb Andreas Schneider:

Did the documentation for the color balance module get updated?



No, it itsn't. So we have a least two updates which are still missing.

Ulrich

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

Re: [darktable-dev] Update usermanual on website

[Ulrich Pegelow]

Hi,

there are a few correction pending and as a main point we still lack 
documentation on the new logarithmic mode of the unbreak input profile 
module. I have no clue on the how this is supposed to work and need 
input from the author(s). Once this is complete I will release the 2.6 
manual.


Best wishes

Ulrich


Am 08.01.19 um 19:28 schrieb rawfiner:

Hi,
Is there any plan to update the usermanual to 2.6 soon on darktable.org 
? (both the online version and pdfs)
It would be nice to have new modules and other change documentation 
available :-)

Cheers,
rawfiner

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

Re: [darktable-dev] DT 2.6.0 / Open CL doesn't work with Nividia 340 driver

[Ulrich Pegelow]

This is fixed now in master and should be fine in 2.6.1.

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

Re: [darktable-dev] DT 2.6.0 / Open CL doesn't work with Nividia 340 driver

[Ulrich Pegelow]

This really looks fishy. The sampler argument in read_imagef() is 
missing. Should be "sampleri" as in the other places.


Ulrich


Am 27.12.18 um 15:26 schrieb Holger Klemm:

Hallo,
open cl does not work with the nvidia diver.
Have a look at retouch.cl


> [...]


10.935219 [opencl_init] compiling program `retouch.cl' ..
10.935491 [opencl_fopen_stat] could not open file `/home/klemmh/.cache/
darktable/cached_kernels_for_Quadro2000/retouch.cl.bin'!
10.935515 [opencl_load_program] could not load cached binary program, trying
to compile source
10.935525 [opencl_load_program] successfully loaded program from `/usr/share/
darktable/kernels/retouch.cl'
11.312707 [opencl_build_program] could not build program: -11
11.312732 [opencl_build_program] BUILD STATUS: -2
11.312737 BUILD LOG:
11.312745 :162:16: error: no matching function for call to 'read_imagef'
   float4 pix = read_imagef(buffer_src, (int2)(x, y));
^~~
:17246:25: note: candidate function not viable: requires 3
arguments, but 2 were provided
float4 __OVERLOADABLE__ read_imagef(image3d_t image, sampler_t sampler, float4
coord);
 ^
:17245:25: note: candidate function not viable: requires 3
arguments, but 2 were provided
float4 __OVERLOADABLE__ read_imagef(image3d_t image, sampler_t sampler, int4
coord);
 ^
:17244:25: note: candidate function not viable: requires 3
arguments, but 2 were provided
float4 __OVERLOADABLE__ read_imagef(image2d_t image, sampler_t sampler, float2
coord);
 ^
:17243:25: note: candidate function not viable: requires 3
arguments, but 2 were provided
float4 __OVERLOADABLE__ read_imagef(image2d_t image, sampler_t sampler, int2
coord);
 ^

11.312759 [opencl_init] failed to compile program `retouch.cl'!
11.312771 [opencl_init] FINALLY: opencl is NOT AVAILABLE on this system.
11.312774 [opencl_init] initial status of opencl enabled flag is OFF.

(darktable:1948): GLib-GObject-CRITICAL **: 15:17:39.350: g_object_set_data:
assertion 'G_IS_OBJECT (object)' failed

(darktable:1948): Gtk-CRITICAL **: 15:17:39.350: gtk_widget_get_has_tooltip:
assertion 'GTK_IS_WIDGET (widget)' failed

(darktable:1948): GLib-GObject-CRITICAL **: 15:17:41.143: g_object_set_data:
assertion 'G_IS_OBJECT (object)' failed

(darktable:1948): Gtk-CRITICAL **: 15:17:41.143: gtk_widget_get_has_tooltip:
assertion 'GTK_IS_WIDGET (widget)' failed



___
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] darktable 2.6 string freeze

[Ulrich Pegelow]

I have also stumbled over the remark of houz. This issue needs to be 
fixed and confirmed before merging.


Ulrich

Am 01.12.18 um 10:01 schrieb Pascal Obry:


Hi,



Probably this call only applies to the translations within darktable and
not to the manual!


Right.


With the PR # 1667 I have standardized the spelling of the keyboard
shortcuts within the English manual. All comments houz had were fixed
(IMHO), if possible the PR can still be included in 2.6.


The last message from houz says:
"The build target darktable-usermanual-dtorg no longer works with
this."

And there is not change after this. It seems quite dangerous to include
this in 2.6 now. But I'll let Ulrich have the last call on this as he
is the documentation maintainer.

Best,



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

Re: [darktable-dev] UI issues / masks

[Ulrich Pegelow]

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] Updating the manual

[Ulrich Pegelow]

Hi Bruce,

you can consider the strength of the module's effect to be controlled by 
two gradients or ramps. One for the highlights and one for the shadows. 
The shadows gradient has its maximum value at L=0 and linearly goes down 
in the direction of the highlights. For the highlights gradient it's 
vice versa.


The compression slider controls the steepness of the two gradients.

With the default setting 50% both gradients reach a value of zero (= no 
effect) at L=50 - which means that only an ideal midtone is not affected 
by neither shadows nor highlights.


At a compression value of 100% the gradients are practically vertical - 
only pure black and pure white are affected - a corner case which has 
virtually no effect on the image.


At a compression value of 0% both gradients extend to the respective 
opposite side. The shadows adjustment strongly affect shadows, 
moderately affects midtones and minimally affects highlights. Vice versa 
for the highlights adjustment.


Best wishes

Ulrich

Am 14.11.18 um 13:15 schrieb Bruce Williams:

Hi all,
Andreas suggested I should seek clarification on the compression slider, 
specifically in the "shadows and highlights" module.
The manual doesn't explicitly state what ranges of shadow and highlight 
values are affected for given compression levels.
In my latest video, I suggested that at 0, the shadows control would 
control all dark tones up to the mid point, and the highlights slider 
would control all tones from the mid-point up to the brightest/whitest 
pixel.
Does a compression setting of 50 mean the shadows slider covers the left 
25% of the histogram, and the highlights slider controls the right 25% 
of the histogram?

Cheers,
Bruce Williams

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

Re: [darktable-dev] scaling produces corrupted image

[Ulrich Pegelow]

Same here. With and without OpenCL.

Am 04.11.18 um 19:58 schrieb Alexander Rabtchevich:
Current git produces corrupted image if export settings require 
downsampling. Mint 19 x64 Mate. Memory is enough.


With respect,
Alexander Rabtchevich
___
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] OpenCL issues

[Ulrich Pegelow]

Am 29.10.18 um 23:35 schrieb Heiko Bauke:


This did not help.  Finally, I set explicitly

opencl_device_priority=*/!0,*/*/*

which is according to the documentation is the default.  Now the GPU is 
enabled except for the preview pixelpipe, as also indicated by the log:



0.208921 [opencl_priorities] these are your device priorities:
0.208925 [opencl_priorities] image    preview    export
thumbnail

0.208934 [opencl_priorities]    0    -1    0    0
0.208941 [opencl_priorities] show if opencl use is mandatory for a 
given pixelpipe:
0.208945 [opencl_priorities] image    preview    export
thumbnail

0.208953 [opencl_priorities]    0    0    0    0


The default

opencl_device_priority=

[...]



The empty string is not the default for opencl_device_priority, default 
is "*/!0,*/*/*". Please note that manual device selection by this 
parameter is only effective if opencl_scheduling_profile=default.


Ulrich


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

Re: Fwd: Re: [darktable-dev] Help needed for creating the HTML darktable manual.

[Ulrich Pegelow]

Here on my system (OpenSUSE) xsltproc comes as part of package 
libxslt-tools.




Am 18.04.2018 um 18:40 schrieb openhab.doc:

Hello Ulrich,

I saw you replay at the other thread, but until now I didn't have the 
time to check.


I'm using Manjaro Linux. In the README.md in folder ./doc I can find the 
following list of packages which I have to install to build the user manual.


- Java JDK, `gnome-doc-utils`, Saxon 6.5.x, FOP and ImageMagick

- `xsltproc` and the DocBook XML DTD and XSL stylesheets

On my system I have installed:

* jdk8-openjdk

* gnome-doc-utils (Version 0.20.10+16+gc03cc09-1)

* saxon-he (Version 9.8.0.1-1)

* fop (Version 2.2-1)

* ImageMagick (Version 7.0.7.28-1)

* DocBook-xml (Version 4.5-6)

* DocBook-xsl (Version 1.79.2-4)

and

additionally docbook-xsl-saxon (Version 1.00-3)

I did not found and I have not installed the package xcltproc!

Where can I find the package xcltproc?

Or is it a vault of the saxon-he package?

Thanks

Pierre


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

Re: [darktable-dev] Re: XML parser → Huge sidecar files

[Ulrich Pegelow]

Hi David,

only for the image currently opened in the darkroom.

Ulrich

Am 17.04.2018 um 18:33 schrieb David Vincent-Jones:

Hi Ulrich  does the 'cleanup' work globally or is this just for the
current image?
David

On 04/17/2018 09:27 AM, Ulrich Pegelow wrote:

You don't need to do this manually. Just go into the mask manager (left
hand panel in the darkroom view), press the right mouse button. On the
menu that appears you select "cleanup unused shapes".

In your case the huge number of invisible shapes comes from the spot
removal tool. The root cause lies in a combination of two facts.
darktable does not delete shapes automatically and spot removal shapes
do not appear in the mask manager. So even if you reset the spot removal
tool all shapes created will still exist in the data set and you do not
even know because the mask manager does not tell you. We should consider
how to change this behavior.

In the time being you can manually clean up unused shapes with the
method described above.

ulrich


Am 16.04.2018 um 10:55 schrieb Timur Irikovich Davletshin:

Well, I was able to edit them with sed script to remove all masks, but
parsing XML to find used/unused masks is beyond my skills (I'm not
familiar with XMP standards). I believe future DT releases should sort
this out in some way. At least for this issue is very critical, it
slows down opening/closing files in my library multiple times.

On Mon, 2018-04-16 at 10:19 +0200, sturmflut wrote:

Hello,

I can confirm this for the latest version in the darktable-2.4.x
branch
(commit edf1168371be288f071986d93a47fb3e082573de). The sidecar files
seem to contain an awful lot of masks, but I can't seem to see which
module even uses them?

cheers,
Simon


On 15.04.2018 20:28, Timur Irikovich Davletshin wrote:

It looks like I was able to find what action causes this problem.

Steps to reproduce:

1. Download, unpack and import as folder — https://drive.google.com
/ope
n?id=14sZLgnpZSV5W3pw1K_8owHW29Heq9EWz (don't pay attention to
content
and settings)
2. Choose second picture and click (in lighttable mode) copy
history
stack and choose, let's say, 'shadows and highlights' settings.
3. Apply it (paste) to first picture, open it, compress history
stack
and close DT.
4. Now compare XMP files, first one is twice bigger than second one
(in
my case ~700kB vs ~1400kB). Meanwhile in darkroom mode history
stack
looks the same.

Can anyone comment, what is going on here?



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

Re: [darktable-dev] Re: XML parser → Huge sidecar files

[Ulrich Pegelow]

You don't need to do this manually. Just go into the mask manager (left 
hand panel in the darkroom view), press the right mouse button. On the 
menu that appears you select "cleanup unused shapes".


In your case the huge number of invisible shapes comes from the spot 
removal tool. The root cause lies in a combination of two facts. 
darktable does not delete shapes automatically and spot removal shapes 
do not appear in the mask manager. So even if you reset the spot removal 
tool all shapes created will still exist in the data set and you do not 
even know because the mask manager does not tell you. We should consider 
how to change this behavior.


In the time being you can manually clean up unused shapes with the 
method described above.


ulrich


Am 16.04.2018 um 10:55 schrieb Timur Irikovich Davletshin:

Well, I was able to edit them with sed script to remove all masks, but
parsing XML to find used/unused masks is beyond my skills (I'm not
familiar with XMP standards). I believe future DT releases should sort
this out in some way. At least for this issue is very critical, it
slows down opening/closing files in my library multiple times.

On Mon, 2018-04-16 at 10:19 +0200, sturmflut wrote:

Hello,

I can confirm this for the latest version in the darktable-2.4.x
branch
(commit edf1168371be288f071986d93a47fb3e082573de). The sidecar files
seem to contain an awful lot of masks, but I can't seem to see which
module even uses them?

cheers,
Simon


On 15.04.2018 20:28, Timur Irikovich Davletshin wrote:

It looks like I was able to find what action causes this problem.

Steps to reproduce:

1. Download, unpack and import as folder — https://drive.google.com
/ope
n?id=14sZLgnpZSV5W3pw1K_8owHW29Heq9EWz (don't pay attention to
content
and settings)
2. Choose second picture and click (in lighttable mode) copy
history
stack and choose, let's say, 'shadows and highlights' settings.
3. Apply it (paste) to first picture, open it, compress history
stack
and close DT.
4. Now compare XMP files, first one is twice bigger than second one
(in
my case ~700kB vs ~1400kB). Meanwhile in darkroom mode history
stack
looks the same.

Can anyone comment, what is going on here?


_

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

Re: [darktable-dev] Help needed for creating the HTML darktable manual.

[Ulrich Pegelow]

Did you read my reply on the other thread you have opened here? And did 
you take appropriate action, like properly installing saxon?


Ulrich

Am 16.04.2018 um 20:08 schrieb openhab.doc:

Hello Simon (sturmflut),

in my e-mail below was an copy and paste error. The complete error message is:

[mepi@mepi-pc build (master)]$ make darktable-usermanual-dtorg
[ 93%] Built target target_media_images
[ 93%] Built target darktable-usermanual-dtorg-images
[ 93%] Building the en usermanual for darktable.orgFehler:
Hauptklasse com.icl.saxon.StyleSheet konnte nicht gefunden oder geladen werden
make[3]: *** [doc/usermanual/CMakeFiles/darktable-usermanual-dtorg-en.dir/
build.make:62: doc/usermanual/dtorg/en/index.html] Fehler 1
make[2]: *** [CMakeFiles/Makefile2:8425: doc/usermanual/CMakeFiles/darktable-
usermanual-dtorg-en.dir/all] Fehler 2
make[1]: *** [CMakeFiles/Makefile2:8158: doc/usermanual/CMakeFiles/darktable-
usermanual-dtorg.dir/rule] Fehler 2
make: *** [Makefile:2656: darktable-usermanual-dtorg] Fehler 2

I'm using Manjaro Linux. My next steps are to check if I have installed all
needed packages. I'm not sure if saxon-he is able to build the HTML darktable
manual.

I have no problems to build the PDF user manual.

cheers,
Pierre

Am Montag, 16. April 2018, 08:38:05 CEST schrieb sturmflut:

Hello,

I'm a bit confused. That's not an error message, but one of the normal
build messages?

cheers,
Simon

On 14.04.2018 08:30, openhab@web.de wrote:

Hello,
I need help creating the HTML darktable manual.
When I try to create the HTML documentation with command
make darktable-usermanual-dtorg
I get the following error message:
[mepi@mepi-pc build (master)]$ make darktable-usermanual-dtorg
*Building the en usermanual for darktable.org*

Do I still have to install anything under Linux? Ideas what I'm doing
wrong? Thanks for help in advance!
Pierre Metzner
(mepi0011)

__


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

Re: [darktable-dev] Error when creating HTML darktable manual

[Ulrich Pegelow]

This indicates an issue with saxon. For building the HTML version of the 
manual we use saxon. This requires the docbook saxon extensions 
(typically part of the docbook package) and saxon version 6.5 which is 
typically supplied in a separate package.


Ulrich

Am 14.04.2018 um 09:16 schrieb openhab@web.de:

Hello,
In my first e-mail i didn't copy all information from error output, 
sorry. New try!

I need help creating the HTML darktable manual.
When I try to create the HTML documentation with command
make darktable-usermanual-dtorg
I get the following error message:
[mepi@mepi-pc build (master)]$ make darktable-usermanual-dtorg
[ 93%] Built target target_media_images
[ 93%] Built target darktable-usermanual-dtorg-images
[ 93%] Building the en usermanual for darktable.org
Fehler: Hauptklasse com.icl.saxon.StyleSheet konnte nicht gefunden oder 
geladen werden
make[3]: *** 
[doc/usermanual/CMakeFiles/darktable-usermanual-dtorg-en.dir/build.make:62: 
doc/usermanual/dtorg/en/index.html] Fehler 1
make[2]: *** [CMakeFiles/Makefile2:8425: 
doc/usermanual/CMakeFiles/darktable-usermanual-dtorg-en.dir/all] Fehler 2
make[1]: *** [CMakeFiles/Makefile2:8158: 
doc/usermanual/CMakeFiles/darktable-usermanual-dtorg.dir/rule] Fehler 2

make: *** [Makefile:2656: darktable-usermanual-dtorg] Fehler 2
Do I still have to install anything under Linux?
Ideas what I'm doing wrong?
Thanks for help in advance!
Pierre Metzner
(mepi0011)

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

Re: [darktable-dev] OpenCL does not work after Nvidia driver upgrade to 384.90

[Ulrich Pegelow]

Unfortunately the OpenCL compiler fails to give a reasonable build log. 
What you could do is try to isolate the offending part of atrous.cl that 
leads to the issues. Start by commenting out the whole code section of 
atrous.cl with "#if 0 ... #endif" and narrow it down from there.


Ulrich

Am 18.12.2017 um 07:43 schrieb KOVÁCS István:

[opencl_init] compiling program `atrous.cl' ..
[opencl_fopen_stat] could not open file
`/home/kofa/.cache/darktable/cached_kernels_for_GeForceGTX650/atrous.cl.bin'!
[opencl_load_program] could not load cached binary program, trying to
compile source
[opencl_load_program] successfully loaded program from
`/usr/share/darktable/kernels/atrous.cl'
[opencl_build_program] could not build program: -5
[opencl_build_program] BUILD STATUS: -2
BUILD LOG:


[opencl_init] failed to compile program `atrous.cl'!
[opencl_init] FINALLY: opencl is NOT AVAILABLE on this system.
[opencl_init] initial status of opencl enabled flag is OFF.
===

Thanks,
Kofa

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

[darktable-dev] duplicate noise profile for Fuji X-E1 as Fuji X-Pro1

[Ulrich Pegelow]

Hi,

according to several sources (e.g.: 
http://www.techradar.com/reviews/cameras-and-camcorders/cameras/digital-slrs-hybrids/fuji-x-e1-1094565/review/4) 
the X-Pro1 and the X-E1 share the same make of sensor. I'd like to make 
a copy of the existing noise profile of the X-E1 for the X-Pro1. Any 
reasonable objections?


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 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 <ulrich.pege...@tongareva.de> 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

[Ulrich Pegelow]

Am 22.06.2017 um 15:58 schrieb Dan Torop:

Ulrich Pegelow <ulrich.pege...@tongareva.de> 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

[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] darktable performance

[Ulrich Pegelow]

Ah, no. The slow module is indeed the demosaic module. You have chosen 
Amaze which also lacks an OpenCL implementation. Maybe even more than 
the raw denoise module.


Best wishes

Ulrich

Am 12.05.2017 um 17:44 schrieb Alexander Rabtchevich:

Could you correct me one more time - does "demosaic" mean raw denoise?

[dev_pixelpipe] took 0.000 secs (0.000 CPU) initing base buffer [export]
[dev_pixelpipe] took 0.040 secs (0.020 CPU) processed `raw black/white 
point' on GPU, blended on GPU [export]
[dev_pixelpipe] took 0.006 secs (0.012 CPU) processed `white balance' on 
GPU, blended on GPU [export]
[dev_pixelpipe] took 0.004 secs (0.008 CPU) processed `highlight 
reconstruction' on GPU, blended on GPU [export]
[dev_pixelpipe] took 1.007 secs (3.816 CPU) processed `demosaic  ' on 
CPU, blended on CPU [export]
[dev_pixelpipe] took 0.208 secs (0.000 CPU) processed `orientation' on 
GPU, blended on GPU [export]
[dev_pixelpipe] took 0.014 secs (0.000 CPU) processed `base curve' on 
GPU, blended on GPU [export]
[dev_pixelpipe] took 0.009 secs (0.000 CPU) processed `input color 
profile' on GPU, blended on GPU [export]
[dev_pixelpipe] took 0.020 secs (0.000 CPU) processed `sharpen' on GPU, 
blended on GPU [export]
[dev_pixelpipe] took 0.019 secs (0.004 CPU) processed `output color 
profile' on GPU, blended on GPU [export]
[dev_pixelpipe] took 0.644 secs (0.356 CPU) processed `gamma' on CPU, 
blended on CPU [export]


AMaZe settings are: color smoothing off, match greens disabled.

With respect,
Alexander Rabtchevich



Ulrich Pegelow wrote:

Am 12.05.2017 um 08:21 schrieb Alexander Rabtchevich:

Hello
I've installed a new graphics card with Radeon 580 chip (8Gb) and so 
examined darktable performance. Two opearations during regular jpg 
export do not use OpenCl - raw demosaic (or decompression) and 
applying of final gamma. Their common time equals or even prewails a 
whole bunch of all other operations. The OpenCl setting in GUI is - 
powerful graphics card. Is there a way to increase the performance? 
Darktable is from current git.


Absolutely! You could just write the needed OpenCL processing code for 
raw denoise.


Concerning gamma: this is the last module in the pixelpipe. Latest in 
that module we need all data been transferred back to CPU memory. The 
time that darktable reports to spend in this module is an artifact. 
The reason is that the GPU and the CPU run idepenently. The CPU code 
just registers the needed GPU calls and then waits until the GPU 
terminates. This waiting happens (among other places) in module gamma. 
If you need to see the real timings you could set 
opencl_async_pixelpipe=FALSE. This way darktable will wait for OpenCL 
processing to finish after each module.


Ulrich

___ 


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] darktable performance

[Ulrich Pegelow]

Am 12.05.2017 um 08:21 schrieb Alexander Rabtchevich:

Hello
I've installed a new graphics card with Radeon 580 chip (8Gb) and so 
examined darktable performance. Two opearations during regular jpg 
export do not use OpenCl - raw demosaic (or decompression) and applying 
of final gamma. Their common time equals or even prewails a whole bunch 
of all other operations. The OpenCl setting in GUI is - powerful 
graphics card. Is there a way to increase the performance? Darktable is 
from current git.


Absolutely! You could just write the needed OpenCL processing code for 
raw denoise.


Concerning gamma: this is the last module in the pixelpipe. Latest in 
that module we need all data been transferred back to CPU memory. The 
time that darktable reports to spend in this module is an artifact. The 
reason is that the GPU and the CPU run idepenently. The CPU code just 
registers the needed GPU calls and then waits until the GPU terminates. 
This waiting happens (among other places) in module gamma. If you need 
to see the real timings you could set opencl_async_pixelpipe=FALSE. This 
way darktable will wait for OpenCL processing to finish after each module.


Ulrich

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

Re: [darktable-dev] OpenCL scheduling profiles

[Ulrich Pegelow]

Am 30.04.2017 um 19:43 schrieb Christian Kanzian:

A bit late, but today I had some time for deeper testing this. In general
detection seems to work well and the profile very fast GPU with a single GPU
works nice as well.


On startup profile was set to multiple GPU, so detection works. Unfortunately
the GT 640 is relatively slow and often the full pipline gets processed on
this device:
[pixelpipe_process] [thumbnail] using device 0
[pixelpipe_process] [full] using device 1
[pixelpipe_process] [preview] using device 0

If the full pipe is running on a slow GPU switching between images is way
slower than before on larger history stakes especially with denoising active.

So I set opencl_device_priority as written in the manual to:
opencl_device_priority=!GeForce GT 640,*/!GeForce GTX 1060 6GB,*/GeForce GTX
1060 6GB,*/GeForce GTX 1060 6GB,*

Now the full pipe should not run on device 1 anymore, but it still does run on
device 1 if I switch between images:
[pixelpipe_process] [thumbnail] using device 0
[pixelpipe_process] [full] using device 1
[pixelpipe_process] [preview] using device 0

Zooming after switching works correctly on device 0.

darktable -d opencl reports this:
[opencl_update_scheduling_profile] scheduling profile set to multiple GPUs
[opencl_priorities] these are your device priorities:
[opencl_priorities] image   preview export  thumbnail
[opencl_priorities] 0   0   0   0
[opencl_priorities] 1   1   1   1
[opencl_priorities] show if opencl use is mandatory for a given pixelpipe:
[opencl_priorities] image   preview export  thumbnail
[opencl_priorities] 0   0   0   0

What does its output mean? Are my opencl_device_priority settings refused?
Maybe this is a corner case, because leaving a second slow GPU in a system
does not make sense.


Yepp, opencl_device_priority is only used if the "default" scheduling 
profile has been selected. That mode offers maximal configuration 
options. I shortly considered to make the "multiple GPUs" profile 
auto-adapt to the speed of detected devices. But in the end this would 
really be a corner case and probably the effort is not really justified.


Ulrich



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

Re: [darktable-dev] OpenCL scheduling profiles

[Ulrich Pegelow]

Am 09.04.2017 um 17:29 schrieb Matthias Andree:

What's your number of background threads (fourth entry in core options)?


It's currently set to 2, and if removed from the configuration file with
darktable stopped,
will revert to 2 when darktable gets restarted and closed next time.

Note I see this quite often, but I don't see where that time comes from:

[dev] took 4,787 secs (5,388 CPU) to load the image.
[dev] took 4,787 secs (5,388 CPU) to load the image.



You might try higher values like six or eight. Main advantage of many 
background threads is hiding I/O latency and that might be a main issue 
here.



Looking at iotop it appears that the prime concern however is that it
maxes out the external USB3 HDD reading from NTFS...
reducing to 1 thread stalled the UI at first but came back with some 30
thumbnails all at once.



Might easily be that the main issue on your system is stalling I/O (for 
whatever reason). Please make some experiments from a very fast storage 
medium (SSD, ram disk) to find out if this is the main cause.



I sometimes see modules like highlite reconstruction, CA correction, or
demosaic ("Entrastern") still being dispatched to the CPU, which is very
slow, when it's normally dispatched to the GPU. Statistics below. It
seems the only module that is supposed to be on the CPU is Gamma, and
it's so blazingly fast that we don't need to care. Sorry for the German,
but you get the idea. This is only from launching darktable in
lighttable view:



There are some modules where no OpenCL code is available (Amaze 
demosaic, raw denoise, color input/output profile with LittleCMS2) but I 
cannot say if this is the main cause here. At least several of the 
modules from the output below have OpenCL support. Please try further to 
isolate if slow CPU processing correlates with specific images and their 
history stacks.



$ grep 'on CPU' /tmp/dt-perf-opencl.log  | sort -k7 | uniq -f6 -c | sort -nr
124 [dev_pixelpipe] took 0,000 secs (0,000 CPU) processed `Gamma' on
CPU, blended on CPU [thumbnail]
  6 [dev_pixelpipe] took 0,026 secs (0,076 CPU) processed
`Entrastern' on CPU, blended on CPU [thumbnail]
  5 [dev_pixelpipe] took 0,276 secs (0,832 CPU) processed
`Chromatische Aberration' on CPU, blended on CPU [thumbnail]
  5 [dev_pixelpipe] took 0,019 secs (0,060 CPU) processed
`Spitzlicht-Rekonstruktion' on CPU, blended on CPU [thumbnail]
  2 [dev_pixelpipe] took 0,118 secs (0,348 CPU) processed
`Raw-Schwarz-/Weißpunkt' on CPU, blended on CPU [thumbnail]
  2 [dev_pixelpipe] took 0,052 secs (0,140 CPU) processed
`Weißabgleich' on CPU, blended on CPU [thumbnail]
  2 [dev_pixelpipe] took 0,023 secs (0,036 CPU) processed
`Tonemapping' on CPU, blended on CPU [thumbnail]
  2 [dev_pixelpipe] took 0,008 secs (0,016 CPU) processed
`Objektivkorrektur' on CPU, blended on CPU [thumbnail]
  2 [dev_pixelpipe] took 0,001 secs (0,004 CPU) processed
`Ausgabefarbprofil' on CPU, blended on CPU [thumbnail]
  2 [dev_pixelpipe] took 0,001 secs (0,000 CPU) processed
`Eingabefarbprofil' on CPU, blended on CPU [thumbnail]
  2 [dev_pixelpipe] took 0,000 secs (0,000 CPU) processed `Schärfen'
on CPU, blended on CPU [thumbnail]
  2 [dev_pixelpipe] took 0,000 secs (0,000 CPU) processed
`Basiskurve' on CPU, blended on CPU [thumbnail]
  1 [dev_pixelpipe] took 3,126 secs (9,444 CPU) processed
`Raw-Entrauschen' on CPU, blended on CPU [thumbnail]
  1 [dev_pixelpipe] took 0,000 secs (0,000 CPU) processed `Drehung'
on CPU, blended on CPU [thumbnail]



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

Re: [darktable-dev] OpenCL scheduling profiles

[Ulrich Pegelow]

Am 09.04.2017 um 11:00 schrieb Matthias Andree:

Am 08.04.2017 um 14:29 schrieb Ulrich Pegelow:
2. What bothers me though are the timeouts and their defaults. In
practice, the darktable works ok-ish, but the lighttable does not. When
a truckload full of small thumbnails (say, lighttable zoomed out to show
10 columns of images) needs to be regenerated for the lighttable, it
*appears* (not yet corroborated with measurements) that bumping up
timeouts considerably helps to avoid latencies, as though things were
deadlocking and waiting for the timer to break the lock. Might be an
internal issue with the synchronization though - how fine granular is
the re-attempt? Is it sleep-and-retry, or does it use some form of
semaphores and signalling at the system level between threads?



What's your number of background threads (fourth entry in core options)?


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

Re: [darktable-dev] All of a sudden, darktable Thread Seg faults

[Ulrich Pegelow]

Am 09.04.2017 um 09:31 schrieb Roman Lebedev:

On Sun, Apr 9, 2017 at 9:59 AM, Ulrich Pegelow
<ulrich.pege...@tongareva.de> wrote:

Am 08.04.2017 um 20:04 schrieb Roman Lebedev:


Well, that is *very* strange indeed.
If it *reliably* happens for you, then maybe you could also bisect this
within the submodule itself?



Very clear result:

Aha, now that makes rather no sense.
It is likely caused by just one raw image, if you can find it, i'll
take it from here.


7f087325d09e2b6d4ecc392f7aee44dd29fafe62 is the first bad commit
commit 7f087325d09e2b6d4ecc392f7aee44dd29fafe62
Author: Roman Lebedev <lebedev...@gmail.com>
Date:   Sat Apr 1 13:11:57 2017 +0300

ThrowException(): and how about this?

:04 04 84dd635a545bf913c916bc075f152a6718f05b1b
ba3c956bb4ffb0b8f54b55ac4aaaf879334f7327 M  src

This commit was reverted in the very next commit, so what is the next
bad commit?



Looks like none of the following commits solves the issue.

However, looking at the changes in question I found that the following 
patch in master brings darktable back to normal:


diff --git a/src/librawspeed/common/RawspeedException.h 
b/src/librawspeed/common/RawspeedException.h

index 692d3f9..b0ebee6 100644
--- a/src/librawspeed/common/RawspeedException.h
+++ b/src/librawspeed/common/RawspeedException.h
@@ -32,7 +32,7 @@
 namespace RawSpeed {

 template 
-[[noreturn]] static inline void __attribute__((noreturn, format(printf, 
1, 2)))

+[[noreturn]] void __attribute__((noreturn, format(printf, 1, 2)))
 ThrowException(const char* fmt, ...) {
   static constexpr size_t bufSize = 8192;
 #if defined(HAVE_THREAD_LOCAL)

That means reverting the change from commit 
7f087325d09e2b6d4ecc392f7aee44dd29fafe62 which has not yet been reverted 
in commit 0967e3c8a528cca0800cc5289cba5c212a385a6b.


Don't ask me 

Ulrich


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

Re: [darktable-dev] All of a sudden, darktable Thread Seg faults

[Ulrich Pegelow]

I'll try to have a closer look tomorrow.

Ulrich

Am 08.04.2017 um 20:04 schrieb Roman Lebedev:

On Sat, Apr 8, 2017 at 6:23 PM, Ulrich Pegelow
<ulrich.pege...@tongareva.de> wrote:

Strange things also happen here. All of a sudden darktable would hang during
startup in the OpenCL init phase of my AMD card (catalyst driver).

I bisected the issue and found this:



97085123a6c29bed86fc7795d527c95bd50a is the first bad commit
commit 97085123a6c29bed86fc7795d527c95bd50a
Author: Roman Lebedev <lebedev...@gmail.com>
Date:   Tue Apr 4 20:51:11 2017 +0300

Rawspeed submodule update: some static analysis fixes.

Well, that is *very* strange indeed.
If it *reliably* happens for you, then maybe you could also bisect this
within the submodule itself?

And perhaps build with ASAN.


:04 04 c3da68a8bc9ec1664348e969bae26540f76234c0
6a112acf0d814aa0eb4bd68f17d14f012ef94e4c M  src


Quite surprising. Doesn't look like the commit is related to OpenCL but I
can reproduce that before this commit all is good and after that darktable
with AMD OpenCL doesn't start. Reverting that commit in master makes
darktable start again.

Ulrich

Roman.



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

Re: [darktable-dev] All of a sudden, darktable Thread Seg faults

[Ulrich Pegelow]

Strange things also happen here. All of a sudden darktable would hang 
during startup in the OpenCL init phase of my AMD card (catalyst driver).


I bisected the issue and found this:

97085123a6c29bed86fc7795d527c95bd50a is the first bad commit
commit 97085123a6c29bed86fc7795d527c95bd50a
Author: Roman Lebedev 
Date:   Tue Apr 4 20:51:11 2017 +0300

Rawspeed submodule update: some static analysis fixes.

:04 04 c3da68a8bc9ec1664348e969bae26540f76234c0 
6a112acf0d814aa0eb4bd68f17d14f012ef94e4c M  src



Quite surprising. Doesn't look like the commit is related to OpenCL but 
I can reproduce that before this commit all is good and after that 
darktable with AMD OpenCL doesn't start. Reverting that commit in master 
makes darktable start again.


Ulrich


Am 05.04.2017 um 21:42 schrieb Roman Lebedev:

On Wed, Apr 5, 2017 at 10:29 PM, Mark Heieis  wrote:

Hi There,

Today, for some reason, darktable seg faults with the following. I used it
yesterday and it worked fine. I may have updated the OS after my last use
and could roll-back the update to check. Any thoughts?

Linux copernicus 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux

$ darktable
[New LWP 2506]
[New LWP 2507]
[New LWP 2508]
[New LWP 2509]
[New LWP 2510]
[New LWP 2511]
[New LWP 2512]
[New LWP 2513]
[New LWP 2514]
[New LWP 2515]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x7f1b3b095fdb in waitpid () from /lib64/libpthread.so.0
backtrace written to /tmp/darktable_bt_XVOKYY.txt
Segmentation fault (core dumped)

~

Core dump:

this is darktable darktable-2.2.3-1.fc25 reporting a segfault:

#0  0x7f1b3b095fdb in waitpid () at /lib64/libpthread.so.0
#1  0x7f1b3f9ccc40 in _dt_sigsegv_handler () at
/usr/bin/../lib64/darktable/libdarktable.so
#2  0x7f1b3790b990 in  () at /lib64/libc.so.6
#3  0x in  ()
#4  0x7f1ae45dfb89 in  () at /lib64/libamdocl64.so

So the issue *appears* to be in amd opencl blob.
You can disable opencl, that would get rid of the crash.


#5  0x7f1ae45e1afe in  () at /lib64/libamdocl64.so
#6  0x7f1ae45d1b98 in  () at /lib64/libamdocl64.so
#7  0x7f1ae42edf69 in  () at /lib64/libamdocl64.so
#8  0x7f1ae42bc4d9 in  () at /lib64/libamdocl64.so
#9  0x7f1ae42bc54f in  () at /lib64/libamdocl64.so
#10 0x7f1ae42bd2c9 in  () at /lib64/libamdocl64.so
#11 0x7f1ae42843d8 in  () at /lib64/libamdocl64.so
#12 0x7f1ae42858c7 in  () at /lib64/libamdocl64.so
#13 0x7f1ae4285a56 in  () at /lib64/libamdocl64.so
#14 0x7f1ae424140e in  () at /lib64/libamdocl64.so
#15 0x7f1ae425cc27 in  () at /lib64/libamdocl64.so
#16 0x7f1ae422adbe in clIcdGetPlatformIDsKHR () at /lib64/libamdocl64.so
#17 0x7f1b1c65676e in  () at /lib64/libOpenCL.so
#18 0x7f1b1c658647 in  () at /lib64/libOpenCL.so
#19 0x7f1b3b093ba9 in __pthread_once_slow () at /lib64/libpthread.so.0
#20 0x7f1b1c656d31 in clGetPlatformIDs () at /lib64/libOpenCL.so
#21 0x7f1b3f9da58b in dt_opencl_init () at
/usr/bin/../lib64/darktable/libdarktable.so
#22 0x7f1b3f9802be in dt_init () at
/usr/bin/../lib64/darktable/libdarktable.so
#23 0x560f0cb71b86 in main ()

Thread 11 (Thread 0x7f1b1d05b700 (LWP 2515)):
#0  0x7f1b3b092460 in pthread_cond_wait@@GLIBC_2.3.2 () at
/lib64/libpthread.so.0
#1  0x7f1b3f9e265f in dt_control_work_res () at
/usr/bin/../lib64/darktable/libdarktable.so
#2  0x7f1b3b08c6ca in start_thread () at /lib64/libpthread.so.0
#3  0x7f1b379ddf7f in clone () at /lib64/libc.so.6

Thread 10 (Thread 0x7f1b1d85c700 (LWP 2514)):
#0  0x7f1b3b092460 in pthread_cond_wait@@GLIBC_2.3.2 () at
/lib64/libpthread.so.0
#1  0x7f1b3f9e265f in dt_control_work_res () at
/usr/bin/../lib64/darktable/libdarktable.so
#2  0x7f1b3b08c6ca in start_thread () at /lib64/libpthread.so.0
#3  0x7f1b379ddf7f in clone () at /lib64/libc.so.6

Thread 9 (Thread 0x7f1b1e05d700 (LWP 2513)):
#0  0x7f1b379a281d in nanosleep () at /lib64/libc.so.6
#1  0x7f1b379a276a in sleep () at /lib64/libc.so.6
#2  0x7f1b3f9e228a in dt_control_worker_kicker () at
/usr/bin/../lib64/darktable/libdarktable.so
#3  0x7f1b3b08c6ca in start_thread () at /lib64/libpthread.so.0
#4  0x7f1b379ddf7f in clone () at /lib64/libc.so.6

Thread 8 (Thread 0x7f1b1e85e700 (LWP 2512)):
#0  0x7f1b3b092460 in pthread_cond_wait@@GLIBC_2.3.2 () at
/lib64/libpthread.so.0
#1  0x7f1b3f9e38be in dt_control_work () at
/usr/bin/../lib64/darktable/libdarktable.so
#2  0x7f1b3b08c6ca in start_thread () at /lib64/libpthread.so.0
#3  0x7f1b379ddf7f in clone () at /lib64/libc.so.6

Thread 7 (Thread 0x7f1b1f05f700 (LWP 2511)):
#0  0x7f1b3b092460 in pthread_cond_wait@@GLIBC_2.3.2 () at
/lib64/libpthread.so.0
#1  0x7f1b3f9e38be in dt_control_work () at
/usr/bin/../lib64/darktable/libdarktable.so
#2  0x7f1b3b08c6ca in start_thread () at 

[darktable-dev] OpenCL scheduling profiles

[Ulrich Pegelow]

Hi,

I added a bit more flexibility concerning OpenCL device scheduling into 
master. There is a new selection box in preferences (core options) that 
allows to choose among a few typical presets.


The main target are modern systems with very fast GPUs. By default and 
"traditionally" darktable distributes work between CPU and GPU in the 
darkroom: the GPU processes the center (full) view and the CPU is 
responsible for the preview (navigation) panel. Now that GPUs get faster 
and faster there are systems where the GPU so strongly outperforms the 
CPU that it makes more sense to process preview and full pixelpipe on 
the GPU sequentially.


For that reason the "OpenCL scheduling profile" parameter has three options:

* "default" describes the old behavior: work is split between GPU and 
CPU and works best for systems where CPU and GPU performance are on a 
similar level.


* "very fast GPU" tackles the case described above: in darkroom view 
both pixelpipes are sequentially processed by the GPU. This is meant for 
GPUs which strongly outperform the CPU on that system.


* "multiple GPUs" is meant for systems with more than one OpenCL device 
so that the full and the preview pixelpipe get processed by separate GPUs.


At first startup darktable tries to find the best suited profile based 
on some benchmarking. You may at any time change the profile, this takes 
effect immediately.


I am interested in your experience, both in terms of automatic detection 
of the best suited profile and in terms of overall performance. Please 
note that this is all about system latency and perceived system 
responsiveness in the darkroom view. Calling darktable with '-d perf' 
will only give you limited insights so you need to mostly rely on your 
own judgement.


Best wishes

Ulrich


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

Re: [darktable-dev] Darktable 2.2.X Plugin Enfuse Professional

[Ulrich Pegelow]

Am 09.03.2017 um 19:39 schrieb Holger Klemm:

Here is the beta2 version with new features:
- on conflict create unique filename or overwrite existing file
- option to add result image to database (global preferences -> lua-option)

http://www.multimedia4linux.de/images/darktable/plugins/
enfuse_pro-2.1beta2.tar



Here it doesn't work (with darktable 2.2.x):

LUA ERROR : Invalid index for combo box : 0

Ulrich


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

Re: [darktable-dev] Darktable 2.2.X Plugin Enfuse Professional

[Ulrich Pegelow]

Am 08.03.2017 um 21:44 schrieb Holger Klemm:

The script works only together with enfuse 4.2 and darktable 2.2.X ...


That's my mistake. I tried it with the development version which implies 
I'm using Lua-5.3. Obviously this could not work.


Ulrich


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

Re: [darktable-dev] Darktable 2.2.X Plugin Enfuse Professional

[Ulrich Pegelow]

FYI, here the script only runs up to the enfuse step and then stops with 
the following terminal output:


enfuse: unrecognized compression "98,0"

I guess enfuse would like to see "98.0" but it receives the number with 
a komma instead of a period as decimal separator.


Ulrich

Am 05.03.2017 um 19:43 schrieb Holger Klemm:

Hallo,
i have written a darktable 2.2.x Plugin for HDR and DFF images.
Here the first beta version

http://www.multimedia4linux.de/images/darktable/plugins/enfuse_pro_beta1.jpg

http://www.multimedia4linux.de/images/darktable/plugins/
enfuse_pro-2.1beta1.tar



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

Re: [darktable-dev] Darktable 2.2.X Plugin Enfuse Professional

[Ulrich Pegelow]

Thanks! This looks really impressive.

Ulrich

Am 05.03.2017 um 19:43 schrieb Holger Klemm:

http://www.multimedia4linux.de/images/darktable/plugins/
enfuse_pro-2.1beta1.tar


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

Re: [darktable-dev] Notebook with dual AMDGPU + Intel, OpenCL setup?

[Ulrich Pegelow]

Am 03.03.2017 um 16:51 schrieb Gonçalo Marrafa:


I've been patiently waiting for some solution to get opencl working
again but i don't get my hopes up... My next laptop will _NOT_ have an
amd card...



I can only underline that. It's absolutely embarrassing how AMD deals 
with the driver issues. I own a HD7950 which worked great with the 
catalyst driver (fglrx). That driver has been deprecated by AMD without 
them offering a working solution for this generation of cards (GCN 1.0). 
I am absolutely angry about them and for sure I will never buy one of 
their cards again.


Ulrich


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

Re: [darktable-dev] determining global image features in the pixelpipe

[Ulrich Pegelow]

Pull Request 1441:

https://github.com/darktable-org/darktable/pull/1441


Am 18.02.2017 um 12:29 schrieb Matthias Andree:

Am 17.02.2017 um 14:56 schrieb Ulrich Pegelow:

I also suggest to use the globaltonemap module as a guiding example.
Please beware that the current implementation has an issue if the
preview pixelpipe runs slower than the full (center) one - a case that
frequently happens when darktable runs with OpenCL support.

To address this issue there is currently some code in PR1441 which is
currently in review. As soon as it gets merged I suggest that you
apply the same principle in your code.


PR1441? Is that a typo?

I generally also propose to review the OpenCL pipeline defaults - with a
mid-range card I frequently observe that the preview pipe is not
permitted to render using OpenCL and that that's far slower (factor of
5) than a quadcore CPU at 2.5 GHz:
<https://redmine.darktable.org/issues/11514>


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

Re: [darktable-dev] darktable 2.2.3 crashes on selection of add path

[Ulrich Pegelow]

Am 17.02.2017 um 16:07 schrieb Michael Figiel:

Hi,
now I've got two binaries: one crashes and one doesn't. Both are without the
fix, build with pristine 2.2.3 sources:
the not-crashing is build as  RelWithDebInfo, the crashing as Release


I would have expected it the other way round, but OK. Asserts are 
normally only active in debug versions of the program.




To reproduce the crash:
1) start darktable (cli: darktable)
   darktable opens with last visited directory in lighttable (where it
   was last properly shut down)
2) double click a picture in 'lighttable' to open in 'darktable'
   the picture is opened in darktable
3) click on 'correction group'
   the correction group is expanded
4) click on 'spot removal'
   spot removal is expanded
5) click on 'add path' in the 'spot removal' module
   crash, core dump
That's the shortest way to reproduce it, but it ends with a crash if I try
to 'add path' in any other tool/mask.


On my setup the asserts are typically not active, so there is no SIGABRT 
to the program. However, I was nonetheless able to reproduce. The 
incumbent functions are called early when generating a path at a time 
where there is no node defined yet. According safeguards are now 
implemented in master and in the darktable-2.2.x branch.


Thanks for reporting!

Ulrich


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

Re: [darktable-dev] determining global image features in the pixelpipe

[Ulrich Pegelow]

I also suggest to use the globaltonemap module as a guiding example. 
Please beware that the current implementation has an issue if the 
preview pixelpipe runs slower than the full (center) one - a case that 
frequently happens when darktable runs with OpenCL support.


To address this issue there is currently some code in PR1441 which is 
currently in review. As soon as it gets merged I suggest that you apply 
the same principle in your code.


Ulrich

Am 17.02.2017 um 14:46 schrieb Heiko Bauke:


thanks for your hint.  I also had a look at other modules and found that
the globaltonemap module does in the case of the Drago algorithm a very
similar kind of calculation as I have to implement.  This will serve as
a useful guideline.


Cheers,

Heiko



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

Re: [darktable-dev] darktable 2.2.3 crashes on selection of add path

[Ulrich Pegelow]

Am 16.02.2017 um 10:17 schrieb Michael Figiel:

If this works it implies that this code is called with nb == 0, meaning
a path with no nodes. Which is strange.

I've rebuilt darktable with the line patched and the problem went away,
the paths are usable. Thank you!
To be sure, I built dt without the modification, and it crashed so it
wasn't just the binary package.

As you can't reproduce the behaviour, maybe I can help with diagnostics?
Please don't ask for the core file - I'm on a very slow line, it would take 
ages...


I'm hesitating to just implement this quick fix as the case of a path 
with zero nodes looks fishy. I'd like to understand better how this 
happens. Maybe you can help me in two aspects. First thing I would like 
to learn is what you exactly do in order to produce the crash (you will 
need to revert the changes).


Then it would be great if you could go into path.c, early in function 
_path_find_self_intersection(). Just add print statements that show with 
what values for nb_corners and border_count this function gets called. Like:


printf("nb_corners %d, border_count %d\n", nb_corners, border_count);

For this to work you will need to put in my fix again.

Best wishes

Ulrich


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

Re: [darktable-dev] darktable 2.2.3 crashes on selection of add path

[Ulrich Pegelow]

Hi,

I can't reproduce here but judging from your description I assume that 
the issue gets triggered in path.c line 529.


If you can compile from source you might try to replace

  intersections = dt_masks_dynbuf_init(10 * nb, "path intersections");

by

  intersections = dt_masks_dynbuf_init(MAX(10 * nb, 100), "path 
intersections");


If this works it implies that this code is called with nb == 0, meaning 
a path with no nodes. Which is strange.


Ulrich

Am 16.02.2017 um 00:11 schrieb Michael Figiel:

Hello,
darktable reproducible crashes if I try to select 'add path' in any tool
(e.g. in 'spot removal' or in monochrome->blending->'drawn mask'):

Assertion failed: (size > 0), function dt_masks_dynbuf_init, file 
/wrkdirs/usr/ports/graphics/darktable/work/darktable-2.2.3/src/develop/masks.h, 
line 324.
Abort trap (core dumped)

'add circle' and 'add ellipse' in the same tool work without any problems.

darktable version: 2.2.3 (binary package from FreeBSD repo)
OS: FreeBSD 11-STABLE amd64

kind regards
Michael Figiel


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

Re: [darktable-dev] Re: Unusual stability problem

[Ulrich Pegelow]

Great, this seems to have fixed the issue for me!

Ulrich

Am 30.01.2017 um 09:45 schrieb johannes hanika:

thanks for providing the fix! seems correct to me, since the loop is y
<= max and y+1 is accessed inside. i pushed this PR to master. let's
see if it fixes it for everyone.

cheers,
 jo




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

Re: [darktable-dev] Re: Unusual stability problem

[Ulrich Pegelow]

I checked further and it's obviously not (only) related to my system 
upgrade, 'cause if I go back a few commits darktable runs stable.


git bisect helped me to find the offending part:

07dc9664df548c7f775ade36cbdb7875a4aa4c9f is the first bad commit
commit 07dc9664df548c7f775ade36cbdb7875a4aa4c9f
Author: Dan Torop <d...@pnym.net>
Date:   Mon Jan 23 21:27:48 2017 -0500

imageop_math: take advantage of CFA pattern on downscale

This increase speed to be faster than prior code w/out blurring.

:04 04 88e97f48a9f6671c9e328008c1ad63b0ec0a4ab0 
153545841ee127841b78ee5b01f8334098ac4fcf M  src


My backtraces indicate that the crash always is linked to

dt_iop_clip_and_zoom_mosaic_half_size_plain._omp_fn.1 () at 
/home/pegelow/darktable/src/develop/imageop_math.c:230


which somehow makes it plausible that the a.m. commit might be involved.

Ulrich

Am 29.01.2017 um 08:03 schrieb Roman Lebedev:

On Sun, Jan 29, 2017 at 1:09 AM, Ulrich Pegelow
<ulrich.pege...@tongareva.de> wrote:

Same here with current master on specific images with and without OpenCL. I
have several images from one session, all have the same raw size. One image
with an uncommon crop crashes whenever I open it in the darkroom.

Looks like the crash is in gtk / x?


Ulrich

Roman.



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

Re: [darktable-dev] Re: Unusual stability problem

[Ulrich Pegelow]

Same here with current master on specific images with and without 
OpenCL. I have several images from one session, all have the same raw 
size. One image with an uncommon crop crashes whenever I open it in the 
darkroom.


Ulrich

Am 28.01.2017 um 05:14 schrieb David Vincent-Jones:

Apparently the problem still exists:

Thread 74 "darktable" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff1cff9700 (LWP 28841)]
dt_iop_clip_and_zoom_mosaic_half_size_plain._omp_fn.1 ()
at
/usr/src/debug/darktable-2.3.0+git309.0f2cfb2/src/develop/imageop_math.c:230

Interesting that this is only occurring on my 16mp. Canon raw files and
I cannot reproduce on my more recent 16mp. raw Fuji files.

This is the first time that I have worked on the Canon files since
installing OpenCL

David





___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.orgthis is darktable 2.3.0+309~g0f2cfb2-dirty reporting a segfault:

#0  0x7f420a601bfd in poll () at /lib64/libc.so.6
#1  0x7f4206c43422 in  () at /usr/lib64/libxcb.so.1
#2  0x7f4206c44d5f in  () at /usr/lib64/libxcb.so.1
#3  0x7f4206c44ed2 in xcb_wait_for_reply64 () at /usr/lib64/libxcb.so.1
#4  0x7f4209a1c0f0 in _XReply () at /usr/lib64/libX11.so.6
#5  0x7f42097cc234 in XIGetClientPointer () at /usr/lib64/libXi.so.6
#6  0x7f4210d4aaa0 in  () at /usr/lib64/libgdk-3.so.0
#7  0x7f421219ecbc in dt_control_expose (voidptr=voidptr@entry=0x0) at 
/home/pegelow/darktable/src/control/control.c:200
#8  0x7f421222c320 in draw (da=, cr=0x35cc9c0, 
user_data=) at /home/pegelow/darktable/src/gui/gtk.c:447
#9  0x7f42111b79bc in  () at /usr/lib64/libgtk-3.so.0
#10 0x7f42112e277f in  () at /usr/lib64/libgtk-3.so.0
#11 0x7f420f976018 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#12 0x7f420f98722d in  () at /usr/lib64/libgobject-2.0.so.0
#13 0x7f420f98ea78 in g_signal_emit_valist () at 
/usr/lib64/libgobject-2.0.so.0
#14 0x7f420f98f062 in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
#15 0x7f42112f0b95 in  () at /usr/lib64/libgtk-3.so.0
#16 0x7f42112f21df in  () at /usr/lib64/libgtk-3.so.0
#17 0x7f42112f2461 in  () at /usr/lib64/libgtk-3.so.0
#18 0x7f421110a5dd in gtk_container_propagate_draw () at 
/usr/lib64/libgtk-3.so.0
#19 0x7f421110a6a2 in  () at /usr/lib64/libgtk-3.so.0
#20 0x7f42110c68b2 in  () at /usr/lib64/libgtk-3.so.0
#21 0x7f42111b79bc in  () at /usr/lib64/libgtk-3.so.0
#22 0x7f42112e277f in  () at /usr/lib64/libgtk-3.so.0
#23 0x7f420f975f92 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#24 0x7f420f986feb in  () at /usr/lib64/libgobject-2.0.so.0
#25 0x7f420f98ea78 in g_signal_emit_valist () at 
/usr/lib64/libgobject-2.0.so.0
#26 0x7f420f98f062 in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
#27 0x7f42112f0b95 in  () at /usr/lib64/libgtk-3.so.0
#28 0x7f42112f2583 in  () at /usr/lib64/libgtk-3.so.0
#29 0x7f421110a5dd in gtk_container_propagate_draw () at 
/usr/lib64/libgtk-3.so.0
#30 0x7f421110a6a2 in  () at /usr/lib64/libgtk-3.so.0
#31 0x7f42111781a2 in  () at /usr/lib64/libgtk-3.so.0
#32 0x7f42111b79bc in  () at /usr/lib64/libgtk-3.so.0
#33 0x7f42112e277f in  () at /usr/lib64/libgtk-3.so.0
#34 0x7f420f975f92 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#35 0x7f420f986feb in  () at /usr/lib64/libgobject-2.0.so.0
#36 0x7f420f98ea78 in g_signal_emit_valist () at 
/usr/lib64/libgobject-2.0.so.0
#37 0x7f420f98f062 in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
#38 0x7f42112f0b95 in  () at /usr/lib64/libgtk-3.so.0
#39 0x7f42112f2583 in  () at /usr/lib64/libgtk-3.so.0
#40 0x7f421110a5dd in gtk_container_propagate_draw () at 
/usr/lib64/libgtk-3.so.0
#41 0x7f421110a6a2 in  () at /usr/lib64/libgtk-3.so.0
#42 0x7f42110c68b2 in  () at /usr/lib64/libgtk-3.so.0
#43 0x7f42111b79bc in  () at /usr/lib64/libgtk-3.so.0
#44 0x7f42112e277f in  () at /usr/lib64/libgtk-3.so.0
#45 0x7f420f975f92 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#46 0x7f420f986feb in  () at /usr/lib64/libgobject-2.0.so.0
#47 0x7f420f98ea78 in g_signal_emit_valist () at 
/usr/lib64/libgobject-2.0.so.0
#48 0x7f420f98f062 in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
#49 0x7f42112f0b95 in  () at /usr/lib64/libgtk-3.so.0
#50 0x7f42112f2583 in  () at /usr/lib64/libgtk-3.so.0
#51 0x7f421110a5dd in gtk_container_propagate_draw () at 
/usr/lib64/libgtk-3.so.0
#52 0x7f421110a6a2 in  () at /usr/lib64/libgtk-3.so.0
#53 0x7f42112fcbbd in  () at /usr/lib64/libgtk-3.so.0
#54 0x7f42111b79bc in  () at /usr/lib64/libgtk-3.so.0
#55 0x7f42112e277f in  () at /usr/lib64/libgtk-3.so.0
#56 0x7f420f976018 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#57 0x7f420f986feb in  () at 

Re: [darktable-dev] Warning: git master now uses rawspeed as submodule !

[Ulrich Pegelow]

Well, that's an option. But I almost already hear the screams when 
people screw things up by using force at the wrong place.


Ulrich


Am 04.01.2017 um 19:15 schrieb Roman Lebedev:

So:

~/darktable$ git describe
release-2.3.0-150-gec88795ce
$ git submodule status
8c0a57825a6e209b109ac18f8ba6966b36c596eb src/external/rawspeed (heads/develop)
~/darktable$ ls -lah src/external/rawspeed/CMakeLists.txt
-rw-r--r-- 1 lebedevri lebedevri 1.9K Jan  4 20:57
src/external/rawspeed/CMakeLists.txt

We are with working git master, with working submodule.

~/darktable$ git checkout darktable-2.2.x
error: The following untracked working tree files would be overwritten
by checkout:
bla bla bla
Please move or remove them before you switch branches.
Aborting

git does want us to accidentally loose data, so it warns us.
Since we know that it is expected, we have two ways:
WAY ONE:

~/darktable$ git checkout darktable-2.2.x -f
warning: unable to rmdir src/external/rawspeed: Directory not empty
Switched to branch 'darktable-2.2.x'
Your branch is up-to-date with 'upstream/darktable-2.2.x'.
~/darktable$ git describe
release-2.2.1-3-g4596f0b5d
~/darktable$ ls -lah src/external/rawspeed/CMakeLists.txt
-rw-r--r-- 1 lebedevri lebedevri 4.7K Jan  4 20:58
src/external/rawspeed/CMakeLists.txt

We are with working git stable branch.

Let's get back to master:

~/darktable$ git checkout master
M   src/external/rawspeed
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
~/darktable$ git describe
release-2.3.0-150-gec88795ce
~/darktable$ git submodule status
 8c0a57825a6e209b109ac18f8ba6966b36c596eb src/external/rawspeed (heads/develop)
~/darktable$ ls -lah src/external/rawspeed/CMakeLists.txt
ls: cannot access 'src/external/rawspeed/CMakeLists.txt': No such file
or directory

Oops, git did not auto-handle the submodule, let's do that manually

~/darktable$ git submodule update
~/darktable$ git submodule status
 8c0a57825a6e209b109ac18f8ba6966b36c596eb src/external/rawspeed (heads/develop)
~/darktable$ ls -lah src/external/rawspeed/CMakeLists.txt
ls: cannot access 'src/external/rawspeed/CMakeLists.txt': No such file
or directory

Let's re-try with -f

~/darktable$ git submodule update -f
Submodule path 'src/external/rawspeed': checked out
'8c0a57825a6e209b109ac18f8ba6966b36c596eb'
~/darktable$ git submodule status
 8c0a57825a6e209b109ac18f8ba6966b36c596eb src/external/rawspeed (heads/develop)
~/darktable$ ls -lah src/external/rawspeed/CMakeLists.txt
-rw-r--r-- 1 lebedevri lebedevri 1.9K Jan  4 20:59
src/external/rawspeed/CMakeLists.txt
~/darktable$

And we're back to git master!

Summary: so even with normal operations, -f is needed...

WAY TWO:
~/darktable$ rm -rf src/external/rawspeed
~/darktable$ git checkout darktable-2.2.x
Switched to branch 'darktable-2.2.x'
Your branch is up-to-date with 'upstream/darktable-2.2.x'.
~/darktable$ git describe
release-2.2.1-3-g4596f0b5d
~/darktable$ git submodule status
~/darktable$ ls -lah src/external/rawspeed/CMakeLists.txt
-rw-r--r-- 1 lebedevri lebedevri 4.7K Jan  4 21:02
src/external/rawspeed/CMakeLists.txt

We are with working git stable branch.

Let's get back to master:

~/darktable$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
~/darktable$ git describe
release-2.3.0-150-gec88795ce
~/darktable$ git submodule status
-8c0a57825a6e209b109ac18f8ba6966b36c596eb src/external/rawspeed
~/darktable$ ls -lah src/external/rawspeed/CMakeLists.txt
ls: cannot access 'src/external/rawspeed/CMakeLists.txt': No such file
or directory

~/darktable$ git submodule update
Cloning into '/home/lebedevri/darktable/src/external/rawspeed'...
Submodule path 'src/external/rawspeed': checked out
'8c0a57825a6e209b109ac18f8ba6966b36c596eb'

So it will need to re-clone rawspeed.
Note: git submodule update  takes --reference= parameter,
you may want to pass --reference ~/darktable/.git/modules/src/external/rawspeed/
which is where git put the submodule repo by default

~/darktable$ git submodule status
 8c0a57825a6e209b109ac18f8ba6966b36c596eb src/external/rawspeed (heads/develop)
~/darktable$ ls -lah src/external/rawspeed/CMakeLists.txt
-rw-r--r-- 1 lebedevri lebedevri 1.9K Jan  4 21:03
src/external/rawspeed/CMakeLists.txt
~/darktable$

And we're back to git master!

Summary: no -f, but it re-clones the submodule.

TLDR: just use  git checkout -f  and  git submodule update -f

Roman.

On Wed, Jan 4, 2017 at 8:37 PM, Ulrich Pegelow
<ulrich.pege...@tongareva.de> wrote:

Hi,

that recent move has now screwed everything here :(

If I want to build:

CMake Error at src/external/CMakeLists.txt:4 (add_subdirectory):
  The source directory

/home/pegelow/darktable/src/external/rawspeed

  does not contain a CMakeLists.txt file.

and ./build.sh aborts (and I did what has been suggested by Wolfgang
before).


If I want to checkout an earlier commit to get away from this rawspeed
thing:

git checkout 693ae87b4dfd0c291969e2043c606935bf

Re: [darktable-dev] Warning: git master now uses rawspeed as submodule !

[Ulrich Pegelow]

Hi,

that recent move has now screwed everything here :(

If I want to build:

CMake Error at src/external/CMakeLists.txt:4 (add_subdirectory):
  The source directory

/home/pegelow/darktable/src/external/rawspeed

  does not contain a CMakeLists.txt file.

and ./build.sh aborts (and I did what has been suggested by Wolfgang 
before).



If I want to checkout an earlier commit to get away from this rawspeed 
thing:


git checkout 693ae87b4dfd0c291969e2043c606935bf55fca5
error: The following untracked working tree files would be overwritten 
by checkout:

src/external/rawspeed/data/cameras.xml
Please move or remove them before you can switch branches.
Aborting

All I did was going to darktable-2.2.x branch in-between.

WTF?

Steps like this really need a preparation with clear usage instructions! 
Right now I'm out with no further clues.


Ulrich


Am 02.01.2017 um 22:27 schrieb Roman Lebedev:

Hi everyone.

Starting with today, darktable git master tracks rawspeed
library as a submodule.

Which means, after updating darktable repo (git pull/git fetch),
and before building, you now need to make sure that the
submodule is updated to.

After fresh clone, you need to run this once:
$ git submodule update --init

And day-to-day, after git pull for darktable
(i'm not 100% sure about the exact command,
someone with more knowledge please do chime in)
$ cd src/external/rawspeed && git pull && \
   git checkout -f && git submodule update -f

Roman.



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

Re: [darktable-dev] Warning: git master now uses rawspeed as submodule !

[Ulrich Pegelow]

Am 03.01.2017 um 17:29 schrieb Roman Lebedev:

On Tue, Jan 3, 2017 at 7:22 PM, Ulrich Pegelow

What now?

$ git checkout -f darktable-2.2.x



Yep, works. But then:

$ git checkout master
M   src/external/rawspeed
Switched to branch 'master'

Which means we generate a pseudo modification in src/external/rawspeed:

diff --git a/src/external/rawspeed b/src/external/rawspeed
--- a/src/external/rawspeed
+++ b/src/external/rawspeed
@@ -1 +1 @@
-Subproject commit 2452e1afd18e06710decce6961a122f43120bfb6
+Subproject commit 2452e1afd18e06710decce6961a122f43120bfb6-dirty


If we always need to force a checkout there is quite some risk of 
accidentally loosing changes. Forcing a checkout will just delete any 
uncommited modification.


Ulrich


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

Re: [darktable-dev] A smallest size of a mask for fading adjust by shift + scroll

[Ulrich Pegelow]

OK, I see what you mean. Certainly something to look for after 2.2 has 
been released.


Ulrich

Am 06.12.2016 um 09:29 schrieb Alexander Rabtchevich:

Hello
I've messed things a little bit :).

If a mask has little size, is internal countur cannot be selected with a
mouse. Moving across the mask with mouse cursor changes selection from
one internal section to the opposte one without selecting the whole
contour. So the mask cannot be neither changed in size nor its fading
area can be adjusted.

If it is a spot removing tool, the whole mask can be selected by its
source part.




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

Re: [darktable-dev] A smallest size of a mask for fading adjust by shift + scroll

[Ulrich Pegelow]

I don't understand, so please elaborate.

Ulrich

Am 05.12.2016 um 15:34 schrieb Alexander Rabtchevich:

Hello
It seems there is some lower size limit for a mask fading area to be
affected with shift + scroll. The workaround is to grow a mask, change
its fading area with shift, and shrinking it to its original size.

With respect,
Alexander Rabtchevich



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

Re: [darktable-dev] Crashes with drawn masks

[Ulrich Pegelow]

Hi!

Looks like you are running a stripped binary. Unfortunately the 
backtrace countains no symbols, so it's not possible to figure out where 
exactly the crash happens.


Maybe you can get/generate a binary with symbols and reproduce the 
crash. If so, please open a ticket in redmine: 
https://redmine.darktable.org/


Best wishes

Ulrich




Am 01.12.2016 um 13:07 schrieb Jean-Pierre Verrue:

Darktable crash frequently when I use the drawn masks and I do many
manipulations "up", "down", "change operator", and so on.
Here is the console trace of a crash and the corresponding file
/tmp/darktable_xxx.txt

my configuration : darktable 2.0.7 on opensuse leap 42.1

Thank you for your great work !



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

Re: [darktable-dev] String freeze for the upcoming 2.2 series

[Ulrich Pegelow]

Hi,

just to add. This time we also have the user manual string freeze at the 
same time, so now. I will not make further changes to the English manual 
of the upcoming 2.2 series before release. Translators are kindly 
invited to update their translations.


Thanks for all your efforts!

Ulrich

Am 24.11.2016 um 12:36 schrieb Tobias Ellinghaus:

Hello translators out there,

we are now in string freeze for the upcoming 2.2.0 release. This is the time
for you to update your translations so we can include them in the release. As
always we will not include anything under a to be determined threshold. We are
aiming for a Christmas release again, so you have a little less than one month
left.

See this blog post about some hints how to update the .po file and for a .pot
file:
https://www.darktable.org/2016/11/string-freeze-for-the-upcoming-2-2-series/

Thanks in advance for your work
Tobias



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

Re: [darktable-dev] Mask problem

[Ulrich Pegelow]

Do you have taken the corresponding pull request (#1354)? Only in that 
PR the shift+scroll option is implemented. We are currently still 
discussing if this will go into 2.2.0.


Ulrich

Am 19.11.2016 um 17:06 schrieb David Vincent-Jones:

With path: Shift does absolutely nothing to change the feather option on
my system. I can only change the feather after I pull one feather node
out of place and then I can use either the shift option or change
through the wheel without shift.

David



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

Re: [darktable-dev] Mask problem

[Ulrich Pegelow]

Am 17.11.2016 um 01:54 schrieb Edgardo Hoszowski:


I've done some quick testing:

-circle

shift adjusts the feather anywhere
control adjusts the opacity anywhere
no key adjusts the size on the shape and the feather on the feather, I
think it will be better to adjust the size with the mouse anywhere on
the shape


Currently I don't want to change that. Many people got used to adjusting 
the feather size this way and I don't see a need to puzzle them.




-ellipse

same as circle, even when on a node

-path

same as circle, but when on a node or segment the zoom is updated
instead of the size, opacity or feather (I mean, instead of adjusting
the shape the image is zoomed)


I'll have a closer look. At least a zoom change is not prone to damage 
anything in the image :)




-brush

I don't use it much, so maybe I just don't understand how it works, but
if it can follow the same logic as the others shapes it would be great.
Right now it sems that with no keys it adjusts the size+feather if the
mouse is on the feather, if on a segment it adjusts the size but the
feather is reduced. It also seems that the step to adjust the size is
different that the one for the circle and ellipse.
When adding a new brush no keys adjusts the size and keeps the feather
the same. Shift adjusts the size but the feather changes, to be more
exact, the outside circle remains the same, and that has the effect of
change the size of the feather.


Instead of size and feather we have size and hardness in brush strokes. 
So they are a bit different from the other shapes.


Ulrich



sorry about my english, if this isn't clear feel free to ask and I'll
try to explain it better.


Ulrich


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

Re: [darktable-dev] Mask problem

[Ulrich Pegelow]

Am 16.11.2016 um 14:27 schrieb Edgardo Hoszowski:

Hi,

Another option is to adjust the feather with the shift pressed, this way
control adjusts the opacity, shift the feather and no key the size, the
3 with the mouse over the shape+feather. This can be useful when the
feather is very small or the shape is very small, in both cases is
difficult to select the area to adjust, or at least it is for me.


I like that idea! A quick implementation can be found in PR #1354. 
Please test and report back.


Ulrich


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

Re: [darktable-dev] Mask problem

[Ulrich Pegelow]

Am 16.11.2016 um 05:02 schrieb Alexander Rabtchevich:

Hello

I have a problem with masks - the fading area cannot be decreased with a
mouse more than some limit. There was no such a limit previously. It is
not convenient.


Right. I added a lower limit so that there remains some separation 
between feathering border and outline of a path shape. If it's 
inconvenient I can alter this behaviour again.


The goal was to prevent the border getting so close that one cannot grab 
and increase it again. How do you manage to grow the feathering area if 
it is very small?



Ulrich



And one more problem - when equalizer is duplicated, the active tab is
switched to the list of used plugins. What for?

With respect,
Alexander Rabtchevich


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

Re: [darktable-dev] Cygwin

[Ulrich Pegelow]

Am 06.11.2016 um 10:00 schrieb Phil Rosenberg:

Thanks Ulrich
I just checked and the latest version of appstream available on Cygwin
appears to be 0.2.8-1 and I have this version installed.

I did a bit of grepping in the source directory and found the
update_contact tag in data/darktable.appdata.xml.in. I changed this to
 reran ./build.sh and the executable built fine. I have
attached a patch. I'm currently installing the prerequisites on my
headless Ubuntu system to see if I get the same build error on there
and/or if the patch work or breaks the build.


To me this sounds like a hack. The tag  is certainly 
undefined/invalid in that context but for some reason remains 
unrecognized by appstream-util. I would not go that way.




One other issue I had, was that when building rawspeed the flags -fPIC
and -Werror are used. On Cygwin -fPIC is not needed as all code is
position independent (I think - maybe it is just for dlls or
something, but I'm not sure). This gives a warning saying that the
-fPIC flag is ignored and not needed and because we are treating
warnings as errors via -Werror the compilation fails. I have seen
exactly this problem before with other libraries. It is relatively
easy to fix with a handful of sed commands, but I wondered if there is
a way to detect that we are using Cygwin and not include the -fPIC
option? Perhaps in reality this is a CMake bug?


I am not an expert in this either. You should try to find out what type 
of warning is behind (what -Wsomething gets triggered?). Then you could 
put a corresponding pragma clause in a place which gets included in 
every source file (darktable.h ?):


#pragma GCC diagnostic warning "-Wsomething"

or

#pragma GCC diagnostic ignored "-Wsomething"

The first one leaves the warning but does not treat it as an error. The 
second simply ignores the warning.


Protect this with the needed #ifdef's so that it is only active when 
darktable is built on your system.


BTW: I recommend that you team with the guys in PR #1327. They seem so 
use another build system but with the same aim of getting a Windows 
version ready.


Ulrich



Phil

On 6 November 2016 at 08:01, Ulrich Pegelow <ulrich.pege...@tongareva.de> wrote:

I also once experienced this error on my Linux box while compiling. To fix
it I needed to upgrade appstream-util. From version 0.2.6 to 0.4.1 in my
case.

Ulrich


Am 06.11.2016 um 08:55 schrieb Phil Rosenberg:


Hi
Up front I will say I have read your policy on Windows and totally
agree. I also work on an open source project and supporting many OSs
is tough and usually requires at least a couple of developers willing
to use and test the code as it develops.

So with that in mind you are free to tell me that you cannot help me
with building on Cygwin, however I'm very close to completing the
build and I have made notes on how to get the build running which I am
happy to share If that is useful to you.

In case you can help, my issue is that during the make all step of the
build I am getting this error

Scanning dependencies of target darktable.appdata_file
[ 99%] Generating darktable.appdata.xml
Merging translations into
/home/phil/usr/src/darktable/build/data/darktable.appdata.xml.
CREATED /home/phil/usr/src/darktable/build/data/darktable.appdata.xml
/home/phil/usr/src/darktable/build/data/darktable.appdata.xml: FAILED:
• tag-missing   :  is not present
Validation of files failed
make[2]: *** [data/CMakeFiles/darktable.appdata_file.dir/build.make:89:
data/darktable.appdata.xml] Error 1
make[2]: *** Deleting file 'data/darktable.appdata.xml'
make[1]: *** [CMakeFiles/Makefile2:6870:
data/CMakeFiles/darktable.appdata_file.dir/all] Error 2
make: *** [Makefile:139: all] Error 2

I presume this is an xml tag that is missing from somewhere, but I
can't work out which file it is missing from to look at fixing it. I'm
not so good with makefiles.

I'm building from the git repo if that helps. Currently at commit
d62c69e36ab428e37df0ae6b57e704bc9178d0b0


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

Re: [darktable-dev] Re: crash on exporting a file

[Ulrich Pegelow]

OK, confirmed that there is an issue with lens correction and OpenCL. 
See redmine ticket #11279.


Am 30.10.2016 um 22:50 schrieb João Horta:

/tmp/darktable_bt_D4NDQY.txt



2016-10-30 21:46 GMT+00:00 João Horta >:

Darktable-git 2.1.0+2119 g50ebe5a


jmhorta@Ubuntu1604:~$ darktable

(darktable:11094): Gtk-WARNING **: gtk_disable_setlocale() must be
called before gtk_init()
[New LWP 11095]
[New LWP 11096]
[New LWP 11097]
[New LWP 11098]
[New LWP 11099]
[New LWP 11100]
[New LWP 11101]
[New LWP 11102]
[New LWP 11107]
[New LWP 11108]
[New LWP 0]
[New LWP 1]
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f9ca984db5d in poll () at ../sysdeps/unix/syscall-template.S:84
84../sysdeps/unix/syscall-template.S: No such file or directory.
backtrace written to /tmp/darktable_bt_D4NDQY.txt
Falha de segmentação
jmhorta@Ubuntu1604:~$



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

Re: [darktable-dev] Compiling error on Manjaro XFCE git 884ef2d7

[Ulrich Pegelow]

Should be fixed with commit e5914e2be3d51380ebf2ca09ec1455a95e3a1b3c.

Ulrich

Am 01.10.2016 um 11:45 schrieb João Horta:

[ 76%] Generating introspection_rawoverexposed.c
no introspection requested for rawoverexposed.c.
Scanning dependencies of target rawoverexposed
[ 76%] Building C object
src/iop/CMakeFiles/rawoverexposed.dir/introspection_rawoverexposed.c.o
In file included from
/tmp/yaourt-tmp-jmhorta/aur-darktable-git/src/darktable/build/src/iop/introspection_rawoverexposed.c:2:0:
/tmp/yaourt-tmp-jmhorta/aur-darktable-git/src/darktable/src/iop/rawoverexposed.c:
In function ‘process_cl’:
/tmp/yaourt-tmp-jmhorta/aur-darktable-git/src/darktable/src/iop/rawoverexposed.c:342:88:
error: passing argument 3 of ‘dt_opencl_copy_host_to_device_constant’
discards ‘const’ qualifier from pointer target type
[-Werror=discarded-array-qualifiers]
 _copy_host_to_device_constant(devid, sizeof(image->buf_dsc.xtrans),
image->buf_dsc.xtrans);
 ^
In file included from
/tmp/yaourt-tmp-jmhorta/aur-darktable-git/src/darktable/src/iop/rawoverexposed.c:26:0,
 from
/tmp/yaourt-tmp-jmhorta/aur-darktable-git/src/darktable/build/src/iop/introspection_rawoverexposed.c:2:
/tmp/yaourt-tmp-jmhorta/aur-darktable-git/src/darktable/src/common/opencl.h:248:7:
note: expected ‘void *’ but argument is of type ‘const uint8_t (*)[6]
{aka const unsigned char (*)[6]}’
 void *dt_opencl_copy_host_to_device_constant(const int devid, const
size_t size, void *host);
   ^~
cc1: all warnings being treated as errors
make[2]: *** [src/iop/CMakeFiles/rawoverexposed.dir/build.make:68:
src/iop/CMakeFiles/rawoverexposed.dir/introspection_rawoverexposed.c.o]
Error 1
make[1]: *** [CMakeFiles/Makefile2:5091:
src/iop/CMakeFiles/rawoverexposed.dir/all] Error 2
make: *** [Makefile:150: all] Error 2
==> ERRO: Uma falha ocorreu em build().
A cancelar...
==> ERRO: Makepkg não conseguiu compilar darktable-git.
==> Reiniciar a compilação de darktable-git ? [s/N]
==> ---
==>
[jmhorta@manjaro-xfce ~]$



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

[darktable-dev] Re: [darktable-user] open CL 2.0.6

[Ulrich Pegelow]

Well, in your case I see the differences as only marginal - the time 
spent in the OpenCL pixelpipe differs only by 2% between the two setting 
(in favor of TRUE). Not sure if differences persist if you would repeat 
profiling several times to get out any fluctuations.


So it seems that your combination of GPU and driver does not profit from 
the opencl_use_pinned_memory flag. But in your case it would not harm 
either to change the default to TRUE.


To others: I am interested to see if there are systems where 
opencl_use_pinned_memory=TRUE gives a heavy negative impact on performance.


Ulrich

Am 15.09.2016 um 06:00 schrieb Jack Bowling:

On 09/14/2016 09:56 AM, Ulrich Pegelow wrote:

Well, there obviously is an issue with OpenCL and NVIDIA. However, a
quick check reveals that this is not related to 2.0.6 versus 2.0.5.

In fact it seems that NVIDIA did some changes to their drivers in the
way they handle memory transfers over the IDE interface.

There is a quick fix for that in darktable. You can switch config
variable opencl_use_pinned_memory to TRUE (can be found in darktablerc).
At least here on my this makes a difference of up to a factor of 30
(oldish GeForce GTS 450 and 367.35 driver).



Setting pinned_memory=true leads to slower render times on my box. Here
is system info on my fully updated Ubuntu 16.04 box:

$ darktable --version
this is darktable 2.0.6
copyright (c) 2009-2016 johannes hanika
darktable-dev@lists.darktable.org

compile options:
  bit depth is 64 bit
  normal build
  OpenMP support enabled
  OpenCL support enabled
  Lua support enabled, API version 3.0.0
  Colord support enabled
  gPhoto2 support enabled
  GraphicsMagick support enabled

$ inxi
CPU~Octa core AMD FX-8300 Eight-Core (-MCP-) speed/max~1400/3300 MHz
Kernel~4.4.0-36-generic x86_64 Up~8 days Mem~2495.3/32090.4MB
HDD~23734.6GB(33.4% used) Procs~340 Client~Shell inxi~2.2.35

$ inxi -G
Graphics:  Card: NVIDIA GK107 [GeForce GT 740]
   Display Server: X.Org 1.18.3 drivers: nvidia (unloaded:
fbdev,vesa,nouveau)
   Resolution: 2560x1440@59.95hz
   GLX Renderer: GeForce GT 740/PCIe/SSE2
   GLX Version: 4.5.0 NVIDIA 361.42

Here is the relevant paste from my darktable config:

opencl=TRUE
opencl_async_pixelpipe=false
opencl_avoid_atomics=false
opencl_checksum=4188966525
opencl_device_priority=*/!0,*/*/*
opencl_library=
opencl_memory_headroom=1000
opencl_memory_requirement=768
opencl_micro_nap=1000
opencl_number_event_handles=25
opencl_omit_whitebalance=
opencl_size_roundup=16
opencl_synch_cache=false
opencl_use_cpu_devices=false
opencl_use_pinned_memory=false

Note the high headroom necessary to prevent atrous dumping to CPU.

Attached are two text files of "darktable -d opencl -d perf" output, one
with pinned_memory=true and one with pinned_memory=false.

Jack



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

Re: [darktable-dev] Photo export slower with OpenCL

[Ulrich Pegelow]

Am 11.09.2016 um 00:33 schrieb Aurélien PIERRE:

Moreover, I have now an error with atrous :

[opencl_atrous] couldn't enqueue kernel! -4
[default_process_tiling_opencl_ptp] couldn't run process_cl() for module
'atrous' in tiling mode: 0
[opencl_pixelpipe] failed to run module 'atrous'. fall back to cpu path

This indicates an out-of-memory problem on your OpenCL system. Try 
increasing config parameter opencl_memory_headroom to something like 350 
or 400.


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

Re: [darktable-dev] Photo export slower with OpenCL

[Ulrich Pegelow]

Am 10.09.2016 um 18:28 schrieb Aurélien PIERRE:

Will do.

For now I deleted nvidia-361 driver and switched to nvidia-340 (340.96).
So my export time with OpenCL dropped from 124s to 27-30s (5-8s better
than CPU). The output is updated here :
https://www.dropbox.com/sh/pk8dwdu3pwmc9w6/AADUJsTBlQiR4pE7advNFqEMa?dl=0.

Those timings look much more reasonable. About 9 seconds are spent in 
OpenCL kernels. The rest is spent in several non-OpenCL modules (e.g. 
colorin/colorout with LittleCMS2, defringe which lacks OpenCL atm).


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

Re: [darktable-dev] Photo export slower with OpenCL

[Ulrich Pegelow]

One idea: please try what happens if you set opencl_use_pinned_memory to 
TRUE. You can find this config variable in 
$HOME/.config/darktable/darktablerc. In addition please also test with 
opencl_async_pixelpipe set to TRUE.


Ulrich

Am 09.09.2016 um 17:25 schrieb Aurélien PIERRE:


OpenCL config :

[opencl_init] opencl related configuration options:
[opencl_init]
[opencl_init] opencl: 1
[opencl_init] opencl_library: ''
[opencl_init] opencl_memory_requirement: 768
[opencl_init] opencl_memory_headroom: 300
[opencl_init] opencl_device_priority: '*/!0,*/*/*'
[opencl_init] opencl_size_roundup: 16
[opencl_init] opencl_async_pixelpipe: 0
[opencl_init] opencl_synch_cache: 0
[opencl_init] opencl_number_event_handles: 25
[opencl_init] opencl_micro_nap: 1000
[opencl_init] opencl_use_pinned_memory: 0
[opencl_init] opencl_use_cpu_devices: 0
[opencl_init] opencl_avoid_atomics: 0
[opencl_init] opencl_omit_whitebalance: 0

Any clues ?



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

Re: [darktable-dev] Usermanual update for 2.2

[Ulrich Pegelow]

Hi Dan,

thanks! It's merged.

Ulrich

Am 25.07.2016 um 16:36 schrieb Dan Torop:

PR #1230 is a pass at usermanual updates regarding X-Trans. There
actually isn't too much that is usermanual-visible. Most of the changes
have been bugfixes, optimizations, and general fixing up of existing
code.




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

Re: [darktable-dev] Usermanual update for 2.2

[Ulrich Pegelow]

Am 23.07.2016 um 12:54 schrieb Roman Lebedev:

On Sat, Jul 23, 2016 at 11:52 AM, Ulrich Pegelow

* correction of outdated issues and factual errors [Roman?]

I guess this is mostly about proofreading?
What would be needed is check if things are still valid in the way we 
describe them. Eg. the manual still refers to the old F7/F8/F9/F10 way 
of changing lightness and contrast of the GUI, which is no longer 
supported AFAIK. Things like that.



* general style and proofreading [Ulrich]
* .


What about marking the code samples that is in manuals (e.g. lua api)
as non-translatable?

Yes, should be done. BTW the lua api manual is a separated document now.

Ulrich


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

Re: [darktable-dev] Usermanual update for 2.2

[Ulrich Pegelow]

Am 23.07.2016 um 11:41 schrieb Pascal Obry:

Sure, but I have already sent you an initial version of the
documentation some time ago. I'm ready for any update if needed of
course.

Yepp, got it and I'll start from there.

Ulrich


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

Re: [darktable-dev] weird colours when using several color modules

[Ulrich Pegelow]

Yepp, seems like this has fixed the issue.

Thanks!

Ulrich

Am 20.05.2016 um 18:58 schrieb Roman Lebedev:

Hello all.

I expect this to be fixed by:

commit 8e859e9b890203eba7dae77bc9f61ab134c4d81e
Author: Roman Lebedev 
Date:   Fri May 20 19:54:20 2016 +0300



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

Re: [darktable-dev] compile error

[Ulrich Pegelow]

Yepp, it's already fixed. Thanks!

Ulrich

Am 16.05.2016 um 21:20 schrieb johannes hanika:

yeah, just noticed that too. should be fixed now.

-jo


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

[darktable-dev] compile error

[Ulrich Pegelow]

Hi,

current master does not compile here (gcc (SUSE Linux) 4.8.3 20140627 
[gcc-4_8-branch revision 212064]):


imageio_dng.h:212:20: note: expected ‘const uint8_t (*)[6]’ but argument 
is of type ‘uint8_t (*)[6]’


Best wishes

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

Re: [darktable-dev] saving translated po file gives an error

[Ulrich Pegelow]

Just tried it but it doesn't seem to work in terms of the output as a 
tooltip. Could you please check if the double %% would solve the 
translation issue? Maybe there is something different.


In case of doubt I will remove the whole stuff related to that unused 
parameter.


Ulrich

Am 20.03.2016 um 22:02 schrieb Ger Siemerink:

Thanks

regards Ger

2016-03-20 22:01 GMT+01:00 Ulrich Pegelow <ulrich.pege...@tongareva.de
<mailto:ulrich.pege...@tongareva.de>>:

Think I already got it. I need to replace "%" with "%%". Will do so
asap.

Ulrich

Am 20.03.2016 um 21:26 schrieb Ger Siemerink:

Hello,

Saving my translated nl.po file gives me an error.
​
String​ 831:the level of lens dependent correction, 100% for full
dependency, 0% for the generic case

poedit reports:
msgstr isn't lequal for C, different than msgid.
in directive number 1 character "b" not a valid conversion
specification

Any idea what is wrong???
​ Thanks for helping!

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

Re: [darktable-dev] saving translated po file gives an error

[Ulrich Pegelow]

Think I already got it. I need to replace "%" with "%%". Will do so asap.

Ulrich

Am 20.03.2016 um 21:26 schrieb Ger Siemerink:

Hello,

Saving my translated nl.po file gives me an error.
​
String​ 831:the level of lens dependent correction, 100% for full
dependency, 0% for the generic case

poedit reports:
msgstr isn't lequal for C, different than msgid.
in directive number 1 character "b" not a valid conversion specification

Any idea what is wrong???
​ Thanks for helping!


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

Re: [darktable-dev] saving translated po file gives an error

[Ulrich Pegelow]

Hi Ger,

that's a string from ashift.c. I don't know what's wrong. However, if 
it's just that one string I could remove it. It belongs to a parameter 
that I finally decided to skip. The code is still there but the 
parameter is not shown. I could remove all related items.


Ulrich

Am 20.03.2016 um 21:26 schrieb Ger Siemerink:

Hello,

Saving my translated nl.po file gives me an error.
​
String​ 831:the level of lens dependent correction, 100% for full
dependency, 0% for the generic case

poedit reports:
msgstr isn't lequal for C, different than msgid.
in directive number 1 character "b" not a valid conversion specification

Any idea what is wrong???
​ Thanks for helping!


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

Re: [darktable-dev] Latest git master fails to build

[Ulrich Pegelow]

Same here with libosmgpsmap-devel-1.0.2-2.1.4.x86_64.

Ulrich

Am 17.02.2016 um 04:36 schrieb Terry Duell:

Hello All,
I regularly build a Fedora 23 rpm from the git master, and this rarely
causes any trouble.
This morning it failed. The last update to the master was 5660cf092a...

The relevant part of the message emitted from rpmbuild is as follows...

/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c: At top level:
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c:903:8: error:
unknown type name 'OsmGpsMapPolygon'
  static OsmGpsMapPolygon *_view_map_add_polygon(const dt_view_t *view,
GList *points)
 ^
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c: In function
'_view_map_add_polygon':
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c:907:3: error:
unknown type name 'OsmGpsMapPolygon'
OsmGpsMapPolygon *poly = osm_gps_map_polygon_new();
^
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c:907:28:
error: implicit declaration of function 'osm_gps_map_polygon_new'
[-Werror=implicit-function-declaration]
OsmGpsMapPolygon *poly = osm_gps_map_polygon_new();
 ^
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c:907:28:
warning: initialization makes pointer from integer without a cast
[-Wint-conversion]
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c:920:3: error:
implicit declaration of function 'osm_gps_map_polygon_add'
[-Werror=implicit-function-declaration]
osm_gps_map_polygon_add(lib->map, poly);
^
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c: At top level:
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c:925:65:
error: unknown type name 'OsmGpsMapPolygon'
  static gboolean _view_map_remove_polygon(const dt_view_t *view,
OsmGpsMapPolygon *polygon)
  ^
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c: In function
'_view_map_remove_marker':
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c:976:38:
error: implicit declaration of function '_view_map_remove_polygon'
[-Werror=implicit-function-declaration]
  case MAP_DISPLAY_POLYGON: return _view_map_remove_polygon(view,
OSM_GPS_MAP_POLYGON(marker));
   ^
/home/terry/rpmbuild/BUILD/darktable-2.1.0/src/views/map.c:976:69:
error: implicit declaration of function 'OSM_GPS_MAP_POLYGON'
[-Werror=implicit-function-declaration]
  case MAP_DISPLAY_POLYGON: return _view_map_remove_polygon(view,
OSM_GPS_MAP_POLYGON(marker));
  ^
cc1: some warnings being treated as errors
src/views/CMakeFiles/map.dir/build.make:65: recipe for target
'src/views/CMakeFiles/map.dir/map.c.o' failed
make[2]: *** [src/views/CMakeFiles/map.dir/map.c.o] Error 1
make[2]: Leaving directory
'/home/terry/rpmbuild/BUILD/darktable-2.1.0/build'
CMakeFiles/Makefile2:1441: recipe for target
'src/views/CMakeFiles/map.dir/all' failed
make[1]: *** [src/views/CMakeFiles/map.dir/all] Error 2

Of course it could be a problem here, but it may also be obvious from
the above.

Cheers,



--
*Ulrich Pegelow* · Benrodestraße 76 · 40597 Düsseldorf
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] OpenCL implementation of Markesteijn demosaic: testers wanted

[Ulrich Pegelow]

Hi,

thanks. So despite the quite modern NVIDIA GPU the OpenCL code is only 
marginally faster than the CPU.


Ulrich

Am 20.01.2016 um 14:35 schrieb Marc Cousin:

Hi,

Here are my numbers… first thing to say is that it «feels» faster.


System is CPU: i7-4790K, GPU : GeForce GTX 960 (2GB Ram)


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

Re: [darktable-dev] OpenCL implementation of Markesteijn demosaic: testers wanted

[Ulrich Pegelow]

Hi,

that looks about the same as my system.

Thanks

Ulrich

Am 20.01.2016 um 15:22 schrieb Christian Kanzian:

Hi,

Sorry, I managed to cut off the details. :-(

Rerun again and details are attached now.

Christian


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

[darktable-dev] OpenCL implementation of Markesteijn demosaic: testers wanted

[Ulrich Pegelow]

Hi,

I just merged my OpenCL implementation of the Markesteijn demosaicing 
algorithm into master. Markesteijn with one or three passes ("-1" and 
"-3", respectively) is darktable's preferred method for demosaicing 
images of cameras with Fuji's X-Trans sensor.


The algorithm is rather complex and has a significant memory overhead. 
Therefore the performance advantage over the already well established 
CPU codepath will depend a lot on the GPU hardware. In my case (AMD 
Radeon HD7950) I get roughly a 2 times faster processing compared to my 
i7-2600@3.4GHz.


But that's just one system. Slower GPUs might even underperform versus 
the CPU. I would like to gather more benchmarking data in order to 
decide if the OpenCL codepath for Markesteijn should be enabled by 
default or not.


So if you are running master and if you have a working OpenCL system I 
am highly interested in your comparison of OpenCL versus CPU speed. 
Please start darktable with '-d opencl -d perf' and do a few test:


1) with OpenCL enabled in preferences
2) with OpenCL disabled in preferences

Please perform:

a) exporting an X-Trans image with default history stack
b) as above but now with demosaic set to Markesteijn-3

Don't forget to tell me your hardware setup (Graphics Card, GPU memory, 
CPU type, system memory).


I am also interested how reactive darktable acts in darkroom mode if you 
pan the image or change some module parameters (take exposure correction 
as an example). Please zoom into the image with a zoom level of 67% or a 
bit more. This test is more about "look and feel" rather than an exact 
measurement. Does darktable react more "snappy" with OpenCL or just the 
opposite?


If you don't have an X-Trans sensor raw at hand you can download one 
from here:


https://www.dropbox.com/s/gef9qkapkktrjn5/DSCF6768.RAF?dl=0

Thanks for your support!

Ulrich

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

Re: [darktable-dev] OpenCL implementation of Markesteijn demosaic: testers wanted

[Ulrich Pegelow]

Thanks!

Looking at your attachment it seems that OpenCL has not been used for 
the demosaic step in any of the test cases. E.g.:


[dev_pixelpipe] took 0,736 secs (2,524 CPU) processed `Entrastern' on 
CPU, blended on CPU [export]


That's the behavior I would expect for darktable prior to my recent 
additions.


Could you please double check?

Ulrich


Am 20.01.2016 um 02:21 schrieb thokster:

Hi,
did some tests:

Intel® Core™ i5-2500 CPU @ 3.30GHz × 4
GeForce GTX 750 Ti, 2GB,128-bit
Ubuntu 15.10 64-Bit, 16GB

opencl - m1
[dev_process_export] pixel pipeline processing took 1,075 secs (2,872 CPU)

opencl - m3
[dev_process_export] pixel pipeline processing took 2,001 secs (6,548 CPU)

no-opencl - m1
[dev_process_export] pixel pipeline processing took 1,289 secs (3,892 CPU)

no-opencl - m3
[dev_process_export] pixel pipeline processing took 2,289 secs (7,528 CPU)

Details attached


With opencl activated darkroom mode is much more snappy.
If you need more information, let me know.


thorsten


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

Re: [darktable-dev] OpenCL implementation of Markesteijn demosaic: testers wanted

[Ulrich Pegelow]

Am 19.01.2016 um 17:18 schrieb David Vincent-Jones:

Will the merge now permit X-Trans raw images to be used in the HDR module?


Nope. This is unrelated.

Ulrich



David


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

Re: [darktable-dev] this is darktable 2.1.0+107~g4b54676-dirty reporting a segfault

[Ulrich Pegelow]

Seems to be only indirectly linked to opencl. darktable crashes in glib 
function g_module_open() which we call to dynamically load libOpenCL.so. 
It crashes before any OpenCL specific functions are called. First time I 
see this being reported.


Ulrich



Am 11.01.2016 um 15:55 schrieb Tobias Ellinghaus:

Am Montag, 11. Januar 2016, 23:40:44 schrieb Nazarii Vitak:

Hi everyone,

After updating system and git (building) the darktable stop working.
Starting from terminal showed:
nazarii@GruenKater:/opt/darktable/bin$ ./darktable


[error messages]


backtrace written to /tmp/darktable_bt_4U63AY.txt
Segmentation fault (core dumped)

I also attached the backtrace file.


Good.

It seems to be a crash in OpenCL, try running with --disable-opencl for the
time being, maybe Ulrich can help find out what is actually happening.


Nazarii.


Tobias



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

Re: [darktable-dev] darktable-viewer crashes on my system without the --disable-opencl parameter

[Ulrich Pegelow]

Known issue. Looks like a negative interaction between OpenCL and 
OpenGL. No idea how to fix :(


Am 08.01.2016 um 17:15 schrieb Colin Adams:

I'm just working through the user manual, and discovered this command.

It crashed, and so I tried the suggestion of disabling opencl. Then it
works.

My video card is an NVIDIA GeForce GTX 750 Ti

(I don't know if reporting this is of any value, but just in case)


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

Re: [darktable-dev] Trouble with drawn masking...

[Ulrich Pegelow]

A redmine ticket has been opened: http://redmine.darktable.org/issues/10808


Am 24.12.2015 um 06:26 schrieb Alexander Rabtchevich:

Hello
It often happens to me too. A mask cannot be selected and the only way
to delete is is to reset the module.
With respect,
Alexander Rabtchevich
*Gesendet:* Mittwoch, 23. Dezember 2015 um 21:45 Uhr
*Von:* "Ulrich Pegelow" <ulrich.pege...@tongareva.de>
*An:* darktable-dev@lists.darktable.org
*Betreff:* Re: [darktable-dev] Trouble with drawn masking...
One of the sample images in redmine ticket #10805 has a similar issue.
I'm currently trying to find out what's happening.


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

Re: [darktable-dev] darktable 2.0 rc4 released

[Ulrich Pegelow]

Looks like a Lua related issue.

Am 17.12.2015 um 00:56 schrieb Patrick Shanahan:

* Tobias Ellinghaus  [12-16-15 18:46]:

Hi there,

we got a fourth release candidate for you to test:

https://github.com/darktable-org/darktable/releases/tag/release-2.0rc4

Please try to break it and report bugs!


Just had crash importing, reported on irc

Tried to import 2nd directory before 1st had completed.  Did this
frequently before.

dt 193b58b
bt @ http://wahoo.no-ip.org/~pat/darktable_bt_OEIX9X.txt


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

Re: [darktable-dev] Re: OpenCL bug

[Ulrich Pegelow]

Hi,

good that you reported the topic. I have seen a similar issue some time 
ago. It seems that some GPU/driver combinations can come into problems 
if we force the driver to generate benchmarking data. That's what 
happens when you call darktable with '-d opencl -d perf'. I guess this 
is an issue of the driver and out of the reach of darktable.


Best wishes

Ulrich

Am 10.12.2015 um 03:14 schrieb André Felipe Carvalho:

It may have been caused by darktable being started with "-d opencl -d
perf" .
Starting normally did not cause the problem.

So, sorry for the disturbance. Really.

Best regards,
André

2015-12-10 0:06 GMT-02:00 André Felipe Carvalho
>:

  I think there's a bug with AMD Catalyst over Ubuntu 15.10.


When I turn OpenCL on, even the exported image shows errors.

Here's the exported image:

https://www.flickr.com/photos/andrefelipecarvalho/23015821693/in/dateposted-public/

--
André Felipe

https://www.flickr.com/photos/andrefelipecarvalho/



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

Re: [darktable-dev] usermanual update

[Ulrich Pegelow]

Am 05.10.2015 um 19:23 schrieb Roman Lebedev:

On Sat, Oct 3, 2015 at 6:40 PM, Ulrich Pegelow
<ulrich.pege...@tongareva.de> wrote:

Hi guys,

it's almost a year ago when the 1.6 user manual has been published.
Meanwhile darktable has progressed significantly and a bunch of new features
had been added. So, now it's a good time to update the manual.

Let's first collect the features which need to be added or updated. From my
perspective I see the following:

* added print mode
* mipmap cache rework
* reworked screen color management (softproof, gamut check etc.)
* text watermarks
* color reconstruction module
* raw black/white point module
* delete/trash feature
* addition to shadows


+ * more proper Kelvin temperature, fine-tuning preset interpolation in WB iop


Not sure if I miss something here but I observe some issues.

If I select one of the presets, let's say tungsten then I can adjust the 
finetuning parameter to let's say 8 Mired. Now if if I go to another 
preset like cloudy the image will stay as it was before. I first need to 
manually go back to 0 Mired until the change of the preset gets 
reflected. I would regard a change of the preset to take precedence over 
any finetuning and reset that value to zero automatically.


BTW: I do not see any visible effect of finetuning. I checked with 
images from my Canon 5DII and IIRC in the past the effect was more 
pronounced.


Ulrich



+ * noiseprofiles are in external JSON file now
+ * monochrome raw demosaicing (not sure whether it will stay for
release, like Deflicker, but hopefully it will stay)



There are certainly things which I forgot. So please add to the list.

My goal is to have an updated English version ready by early November.

Best wishes

Ulrich

Roman.


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