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 reason
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 ful
@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.
U
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 mailin
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.
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
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
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 sta
Well, that's a bit complicated.
First: for drawn¶metric 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 contribution
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
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
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_priorit
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
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
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
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:
[mep
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 openh
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
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
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
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
Am 22.06.2017 um 19:31 schrieb Dan Torop:
Ulrich Pegelow writes:
Oh no! I was thinking of the dt_iop_clip_and_zoom_demosaic_{half,third}_*()
functions in imageop_math.c. Those don't have OpenCL implementations, though?
Certainly getting into revising OpenCL code would be a way more inv
Am 22.06.2017 um 15:58 schrieb Dan Torop:
Ulrich Pegelow writes:
Am 21.06.2017 um 18:03 schrieb Dan Torop:
I'd say that is well withing the time frame – provided it's not too invasive.
That is great. Should be a tweak to the Bayer downscale code (making
start/endpoints of sa
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 cons
aZe 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 opeara
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 comm
Hi David,
please open an ticket in redmine and attach the source + xmp file. The
issue looks like darktable has a wrong assumption on the image dimensions.
Best wishes
Ulrich
Am 06.05.2017 um 12:15 schrieb David Vincent-Jones:
This is the results of applying an exposure parametric mask to a
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. Unfortunat
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 t
Thanks. Works here. Let's see if his also fixes the SegFault reported by
the TO.
Ulrich
Am 09.04.2017 um 16:49 schrieb Roman Lebedev:
And, pushed.
___
darktable developer mailing list
to unsubscribe send a mail to darkta
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
Am 09.04.2017 um 09:31 schrieb Roman Lebedev:
On Sun, Apr 9, 2017 at 9:59 AM, Ulrich Pegelow
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
Am 09.04.2017 um 09:31 schrieb Roman Lebedev:
On Sun, Apr 9, 2017 at 9:59 AM, Ulrich Pegelow
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
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:
7f087325d09e2b6d4ecc392f7aee44dd29fafe62 is the first bad commit
commit 7f087325d09e2b6d4e
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
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 d
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
A
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 d
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_pr
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
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 1
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 unsubscrib
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.
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
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. Ass
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
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 t
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(MA
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
rieb Roman Lebedev:
On Sun, Jan 29, 2017 at 1:09 AM, Ulrich Pegelow
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.
moved from OpenSUSE 13.2 to Leap 42.1 this might well be
related to gtk/x as many libraries are now updated.
Ulrich
Am 29.01.2017 um 08:03 schrieb Roman Lebedev:
On Sun, Jan 29, 2017 at 1:09 AM, Ulrich Pegelow
wrote:
Same here with current master on specific images with and without OpenCL. I
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
ault
~/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
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 wha
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 modif
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.
Hmm..
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 w
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
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://r
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
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 fea
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 anywh
Am 16.11.2016 um 20:56 schrieb Alexander Rabtchevich:
Sorry, it was double middle-click.
Mmmh, does it work well with a wheel mouse? For me it's difficult to
double-click without turning the wheel.
Anyhow, please see my other comment from later this evening. I
implemented a shift-scroll op
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
Am 16.11.2016 um 08:22 schrieb Alexander Rabtchevich:
Magnification by twice double clicking makes the area enough to be
managed, even it is one or two pixels wide.
Doesn't seem to work for me as double-click brings me back to lighttable
mode.
By the way, is it possible to treat masks in t
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
betwe
but with the same aim of getting a Windows
version ready.
Ulrich
Phil
On 6 November 2016 at 08:01, Ulrich Pegelow 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.2
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 w
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 mailto:jho...@gmail.com>>:
Darktable-git 2.1.0+2119 g50ebe5a
jmhorta@Ubunt
Are you using OpenCL? I can confirm that it's no longer working if
OpenCL is running. I could bisect the problem:
45326d7725c67505f6500815a87d56650ea7af65 is the first bad commit
commit 45326d7725c67505f6500815a87d56650ea7af65
Author: Roman Lebedev
Date: Sun Oct 9 15:45:11 2016 +0300
Raw
Reply to myself: upgrading appstream-util from version 0.2.6 to 0.4.1
fixed the issue.
Ulrich
Am 09.10.2016 um 18:21 schrieb Ulrich Pegelow:
Hi,
after updating some system tools I'm getting issues building darktable.
Reason seems to be that darktable.appdata.xml does not validate
Hi,
after updating some system tools I'm getting issues building darktable.
Reason seems to be that darktable.appdata.xml does not validate with
appstream-util:
FAILED:
• tag-missing : is not present
Validation of files failed
data/CMakeFiles/darktable.appdata_file.dir/build.make:8
Am 01.10.2016 um 20:39 schrieb João Horta:
😋 many thks.
but continue to have problems with Spot WB (it's another bug(me)!!
Confirmed.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubs
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/i
Wrong group. Discussion is in darktable-users.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
.
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
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
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/AADUJsTBlQiR
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
Hi,
Am 09.09.2016 um 17:25 schrieb Aurélien PIERRE:
since Ubuntu 16.04, the processing and exporting with OpenCL felt much
slower than before.
[...]
Any clues ?
Not really. However, one thing is obvious:
[opencl_profiling] spent 124,9889 seconds in [Write Image (from host to
device)]
[ope
Thanks for reporting. I missed to add liquify.xml. It should be in
master now.
Ulrich
Am 30.07.2016 um 17:35 schrieb Richard Hobday:
Just complied the user manual from the current (30/7/16 16:30) git and
the following error pops up.
warning: failed to load external entity
"darkroom/modules/co
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.
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
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
___
Dear all,
I'd like to start an update of the usermanual to make it ready for 2.2.
Let's begin by compiling a list of required changes. From my side
following comes to mind and I added a proposal of whom might take care.
Please and your proposals.
* new module color check lut [Jo?]
* new bina
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
__
Am 17.05.2016 um 20:21 schrieb Roman Lebedev:
On Tue, May 17, 2016 at 9:13 PM, Ulrich Pegelow
wrote:
Hi,
I can confirm your issue. You are running with OpenCL enabled? It looks like
I have introduced an issue when porting xtrans demosaicing to OpenCL.
Are you really sure?
No, not sure
Hi,
I can confirm your issue. You are running with OpenCL enabled? It looks
like I have introduced an issue when porting xtrans demosaicing to
OpenCL. What I see are spurious color distortions (typically towards
magenta) when quickly changing some slider value like the exposure
compensation.
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-
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
_
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
mailto:ulrich.pege...@tongareva.de>
<m
h
Am 20.03.2016 um 22:02 schrieb Ger Siemerink:
Thanks
regards Ger
2016-03-20 22:01 GMT+01:00 Ulrich Pegelow 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 schrie
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
poed
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
27;/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 pro
Am 13.02.2016 um 18:35 schrieb johannes hanika:
sounds good to me.
would we need any visible indication that this scale is logarithmic?
or would the number changing logarithmically be indication enough?
I'd be sparingly with any additional gui element. I guess the feedback
by number is clear
Am 13.02.2016 um 12:03 schrieb johannes hanika:
short question: is there already an established way to get a bauhaus slider
with a logarithmic scale?
short answer: no. (other than just mapping some mislabeled value to
exp(v) in the gui callback or commit_params..
My idea: we implement a callb
Hi,
short question: is there already an established way to get a bauhaus
slider with a logarithmic scale?
Background: I would need a slider for focal length (1mm to 1000mm) and
this would better scale logarithmically.
Ulrich
__
Hi Christian,
thanks for the feedback. Your observation is inline with most others. In
general users see a slight go noticeable speed improvement by OpenCL in
Marketsteijn demosaic. So it seems reasonable to leave Markesteijn
OpenCL on by default.
Best wishes
Ulrich
Am 08.02.2016 um 20:00
Hi Pascal,
OK, I will then take care of any merge conflicts in PR 1129 so that
ashift would come before liquify.
Ulrich
Am 29.01.2016 um 19:29 schrieb Pascal Obry:
Ulrich, Roman,
Ok, so I'll do that. I'll put liquify *just* after lens.
Thanks to both of you for raising this up!
Hi,
Pascal and I had a short chat about the position of liquify (new module
in master) and ashift (PR stage) in the pixelpipe.
For ashift, which I am working on, the best position is after lens
correction and before the flip module. Reason: the module will extract
straight lines for perspect
1 - 100 of 125 matches
Mail list logo
