thanks moritz.
and btw i was really very happy to hear about openexr being ported to c :)
i share the maintainability concerns, so at some point i took some time for
an experiment and rewrote parts of dt in vulkan/glsl (
https://github.com/hanatos/vkdt). sorry but if anything it's even more c
tha
heya,
the xmp you're providing has 0028 in the name, the raf is 0027 (i.e.
does not match the file name and is thus not used). if i rename it, i
also don't get a colour checker lut module when loading it in current
git. as far as i can tell the xmp also doesn't contain any. maybe it's
the wrong xm
heya,
your profile looks good. it has a few deviations in the blacks,
especially at high iso. the high iso ones may be a bit larger than
usual, though such inaccuracies for very dark values are an inherent
limitation of the noise model.
cheers,
jo
On Sun, Jun 30, 2019 at 10:18 PM Jens-Hanno Sch
hi,
On Thu, Jun 13, 2019 at 10:57 PM David C. Partridge
wrote:
>
> Hi folks
>
> I've read that the implementation of Frank Markesteijn's X-Trans
> interpolation code in darktable is much faster than that in LibRaw or dcraw.
>
> Is that correct?
i don't know. does libraw still ship demosaicing at
hi,
these parameters are unfortunately not very easy to interface with.
these are straight binary dumps of the history params structs you'll
find in the source code of the respective modules (see for instance
for exposure:
https://github.com/darktable-org/darktable/blob/master/src/iop/exposure.c#
hmm.. this doesn't show the extra space. must be a new bug then.
-jo
On Sat, Apr 27, 2019 at 4:59 AM Christian wrote:
>
> Hi,
> find attached the style file.
>
> Chris
>
>
> Am 26.04.2019 um 18:01 schrieb johannes hanika:
>
> > i used to have instances
hi,
i used to have instances of such an issue with styles that had
"basecurve " instead of "basecurve" (note the space) in their xmp. can
you double check whether that's the case here, too? or send a .dtstyle
file so we can check.
cheers,
jo
On Fri, Apr 26, 2019 at 11:31 PM Christian wrote:
>
i second the 'getting old' bit. and i really like IRC. i could never
get the hang of these fancy websites that force you to use a mouse.
for slack at least there used to be an IRC bridge. it seems mattermost
may be an alternative that does support IRC, for those of us who
insist on animated gifs fo
heya,
equalizer? should be local contrast.
it means that there is some caching issue between preview and full
pipeline. this is really a debugging message that should never occur,
but it seems occasionally it does. can you trigger it explicitly? if
so i'd be interested to learn about it so we cou
hi,
i had a very similar problem with hangs during startup. in my case
deleting the old /usr/local/lib/darktable directory did the trick (old
plugins were installed there which happened to be renamed/not compiled
any more, so they were neither removed nor overwritten by a new 'make
install').
che
hi,
let me know how you go with the anscombe transform, that sounds
important. in principle we should run it before black point
subtraction, to be able to correctly extract the zero-mean values for
black. the current transform wouldn't work with such data, however.
cheers,
jo
On Thu, Feb 21, 20
heya,
just to be sure it is very clear.. what parafin is referring to is
that darktable catches say a sigsegv and writes out the stack trace
(not only in theory you could debug it if you had run it through gdb),
see src/common/system_signal_handling.c.
(not a fan of popup modal dialogs for my par
heya,
there were ideas to draw the overlay on top of the center view
instead, at least optionally. this would pan and zoom with the center
view directly. don't remember how far the discussion went though.
there may have been side effects for masking.
cheers,
jo
On Tue, Jan 29, 2019 at 8:51 PM J
.. did it output a crash report file in /tmp/ ? that would contain the
gdb backtrace.
-j.
On Mon, Jan 28, 2019 at 4:55 PM David Vincent-Jones wrote:
>
> Don't know if this helps:
>
> Thread 15 "worker res 1" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffbeffd700 (LWP
ize);
void dt_free_align(void *mem);
which may need to be amended a bit and probably they aren't used very
consistently throughout the code base. occasionally there may also be
some glib malloc wrapper in use..
cheers,
jo
On Tue, Jan 29, 2019 at 3:12 AM Mark Feit wrote:
>
> On 1/28
hi,
i agree that we should focus on code stability :)
re: malloc() and 0: linux overcommits, i.e. it will likely never
return 0 even if your memory is all full. this means checking for 0 is
completely useless in this context.
roman setup coverity scan for rawspeed in the past. i thought it was
a
heya,
in general the gsoc concept is a bit heavy on our personal resources.
i cannot promise to do mentoring.
i think your project ideas are great though. some of them could be
very large scale projects (full featured timelapse), some more sunday
afternoon (black frame). the list might require so
heya,
i had one or two shots in the past where i missed this feature, too
(have an 8mm peleng fisheye). in my case it was mainly about
straightening horizon lines or similar. i ended up doing these in
hugin and forgot about it. other than that i think this is a very
reasonable feature request.
to
heya,
sorry for the late answer, usual madness. but i think you're raising a
few important points here. let me try to answer some of it:
On Fri, Dec 7, 2018 at 4:04 AM rawfiner wrote:
> For wavelet codes, there is a 2x multiplier on B and R channels, while it is
> not the case for the anscombe
awesome! thanks for rolling the tarball for us!
-jo
On Mon, Dec 3, 2018 at 3:25 AM Pascal Obry wrote:
>
>
> we're proud to announce the first release candidate for the upcoming
> 2.6 series of darktable, 2.6.0rc0!
>
> the github release is here: [
> https://github.com/darktable-org/darktable/rele
heya,
On Fri, Nov 23, 2018 at 5:24 PM Aurélien Pierre
wrote:
>
> Hi everyone,
>
> my darktable is installed on Ubuntu Budgie (fork of Gnome 3), but it was the
> same when I used Gnome Shell. I have a custom screen ICC profile installed
> in gnome-color-manager, and loaded in darktable through c
re: colord: is there the more minimalistic xiccd maybe?
cheers,
jo
On Sat, Nov 24, 2018 at 11:48 AM Alexander Rabtchevich
wrote:
>
> Hello
>
> And there is no colord in Mate desktop, at least on Linux Mint. So I have to
> select correct profile from the list manually each time I load Darktable.
hi,
this sounds weird, since the last changes to the core of that
algorithm seem to be from 2017.
the bug report rawfiner linked may be related to this commit:
911133c87b45be22251cf7252ed729d1632a27b2 and that
51bfe2f29411c0146d0aea70bdf073647d606a40 (i.e. this is just how it
works if you don't w
hehe, i wouldn't post backtraces from anything but <10min old git, would i :)
i think the last people who touched this are houz and parafin, around
where the module->init() call takes place. the last line in the
backtrace is probably a red herring, the problem is that rawprepare's
init() function
hi!
looks like an interesting project you're working on.
if you have a look at the source of darktable-cli, it's really short:
https://github.com/darktable-org/darktable/blob/master/src/cli/main.c
you could probably link your code directly to libdarktable.so the same
way. i don't understand you
heya,
just so i don't lose track of it. i just got this crash (see attached).
what happens is that for some obscure reason, we need a module_t (not
only module_so_t) when updating legacy blendop params in old presets.
i happen to have one for rawprepare (which is called "debug dng" so i
don't thi
heya,
with an open SDK there is the problem of backward compatibility. how
would you deal with that? don't offer support? what if the plugin
author disappears and the code rots? you'd be making old history
stacks useless. i like how we are committed to keeping old image edits
alive.
is there anyt
..that old picture again? it has a ton of noise in green. fwiw i like
what i can do in dt better than the fine grained noise that stays in
the OP's RT version. but as pascal pointed out, it seems to be a waste
of time to comment on this here. noise preferences are very
subjective, and yes, by all m
Hey,
One more reason for gamma.c: legacy. In 2009 when the pipeline was the one
of ufraw, this was actually used. So in case someone opens 10yo shots now
they depend on the iop.
Re: colorpicker. that's a known issue, we don't run multiple pipelines so
the colorpicker reads whatever there is at th
heya,
it used to do the gamma in the olden days. now it just does what you
observed: convert to uint8 for display and any marshalling of data at
the end of the pipeline in gui mode can take place here. it's
certainly not applying gamma. i suppose we could delete these old
gamma lut table lines of
heya,
this is an IIR filter (infinite impulse response, as opposed to the
straight forward FIR, finite impulse response, which would be for
instance a 5-tap b-spline filter) which approximates a gaussian. it's
especially well suited for large filter supports. why do you need to
know? for sports or
hi,
is this the precise error message you get? i would try to disable the
check and run it anyways, be it supported or not. note that you'll
break your (non existing..) warranty :) also i'm really not sure you'd
get a fast raw processor this way. my guess is if you manage to get it
running it'll b
heya,
[..]
> Actually, I even wonder if OpenCL is relevant for this as it's a linear
> operation performed on only one pixel at the time over the flatten array. I
> wouldn't be surprised if the OpenCL version were slower on some systems than
> a good SSE2 version.
maybe on some systems. the th
hi,
clang needs libomp-dev, not libgomp which gcc uses. i assume you have
that installed?
cheers,
jo
On Fri, Sep 14, 2018 at 5:45 AM Matthias Bodenbinder
wrote:
>
> Am 13.09.18 um 15:58 schrieb sturmflut:
> > Hi all,
> >
> > IIRC this has something to do with clang not linking against libatomic
ly sure we'll need such a thing for nlmeans though. curious to
hear if you have any findings!
cheers,
jo
On Wed, Sep 12, 2018 at 9:22 AM rawfiner wrote:
>
> hi,
>
> Le lun. 10 sept. 2018 à 14:47, johannes hanika a écrit :
>>
>> hi!
>>
>> nice, your downsca
members.
>
> Also, if you trusted me enough to give me admin rights on redmine, I would be
> happy to merge duplicates or close the solved issues to make some room.
>
> Have a good day !
>
> Aurélien.
>
>
> Le 10/09/2018 à 08:55, johannes hanika a écrit :
>
> hi,
&
heya,
sorry i don't know much about user interfaces and expectations. the
scrolling is in line with what blender does for proportional edit for
instance. sounds like it should be configurable. but i can't find such
an option and i don't know enough about the mask code to be helpful
here.
cheers,
.. okay, it has been removed. iirc this is the loop that used to be
parallel (needs some added sync inside):
https://github.com/darktable-org/darktable/blob/master/src/control/jobs/control_jobs.c#L1236
-jo
On Mon, Sep 10, 2018 at 3:26 PM johannes hanika wrote:
>
> heya,
>
> to
heya,
to tell you the truth i don't remember the state of the exporter. we
did have this option precisely for what you describe. one pixel
pipeline one GPU, and several for the export. i think it did lead to a
certain amount of race conditions for sequence numbers etc, and for
CPU based export, it
heya,
this seems a bit hard to diagnose from here.. did you try to reproduce
the exact sql query in the command line interface ( "sqlite3" ) ? you
can see whatever dt does using "darktable -d sql". also did you start
that from a clean database? for debugging, it may be helpful to backup
your ~/.co
hi,
On Wed, Sep 5, 2018 at 9:09 PM Heiko Bauke wrote:
>
> Hi Johannes,
>
> Am 05.09.2018 um 12:08 schrieb johannes hanika:
>
> > as to your question, integrate gmic or reimplement. does it make much
> > of a difference?
>
> main differences:
>
> * using libg
hi heiko,
are you on irc at some point? my internet connection is intermittent
these days, but discussing these things sounds like an interactive
medium would be better suited.
i was traditionally looking at the easiest module (sharpen,
src/iop/sharpen.c) for reference. for the opencl kernel, you
hi,
thanks for putting this list together! yes we're terrible dealing with
these things. time seems to be the limiting factor here. the problem
with recruiting new people to go in and fix these things is that you
need someone to review the changes. which pretty much amounts to the
bottle neck for
hi!
nice, your downscaled images look impeccable :) maybe they jump up or
down by one pixel or so?
do you have any example result images for the denoising already? are
you running before or after black point subtraction? if you can, i
think you should run before.
exciting stuff :)
cheers,
jo
hi heiko!
this sounds great!
as to your question, integrate gmic or reimplement. does it make much
of a difference? can the code run on cropped regions of interest and
in floating point? does it work for preview, i.e. does a downscaled
image look similar when processed to first processing and the
cale, I always get 1.
> Is the roi_out variable used in modify_roi_out different from the one in
> modify_roi_in?
>
> Maybe am I not catching something about the role of these passes.
>
> Thanks for any help!
>
> Cheers,
> rawfiner
>
> 2018-05-10 23:13 GMT+02:00
to save the scale in roi_out->scale, but
>> in modify_roi_in if I try to print roi_out->scale, I always get 1.
>> Is the roi_out variable used in modify_roi_out different from the one in
>> modify_roi_in?
>>
>> Maybe am I not catching something about the role of thes
; I think that it would make easier to have a "uniform" output (i.e. an output
> where noise has been reduced quite uniformly)
> I have not tested this idea yet.
>
> Cheers,
> rawfiner
>
> Le lundi 11 juin 2018, johannes hanika a écrit :
>>
>> hi,
>>
&g
e darktable blog post) to see how it performs.
>
> cheers,
> rawfiner
>
>
> 2018-01-27 13:50 GMT+01:00 johannes hanika :
>>
>> heya,
>>
>> thanks for the reference! interesting interpretation how the blotches
>> form. not sure i'm entirely convinced by th
heya,
On Wed, Jun 6, 2018 at 8:22 AM, Heiko Bauke wrote:
> Hi,
>
> Am 05.06.2018 um 09:56 schrieb johannes hanika:
>>
>> On Tue, Jun 5, 2018 at 9:35 AM, Sarge Borsch
>> wrote:
>>>
>>> https://developer.apple.com/macos/whats-new/
>>>>
>
hi,
On Tue, Jun 5, 2018 at 9:35 AM, Sarge Borsch wrote:
> https://developer.apple.com/macos/whats-new/
>> Apps built using OpenGL and OpenCL will continue to run in macOS 10.14, but
>> these legacy technologies are deprecated in macOS 10.14. Games and
>> graphics-intensive apps that use OpenGL
hi,
i'd recommend #darktable on freenode or alternatively place any
specific questions on this list.
cheers,
jo
On Sun, Jun 3, 2018 at 8:29 AM, Martin Marmsoler
wrote:
> Hi,
>
> I cloned the darktable code from git and I saw there aren't any comments in
> the code. Is there somewhere an introd
heya,
On Wed, May 9, 2018 at 12:27 PM, rawfiner wrote:
> 2018-05-08 17:16 GMT+02:00 johannes hanika :
>> i'm guessing you want to detect whether you are running a
>> DT_DEV_PIXELPIPE_FULL pipe in darkroom mode (as opposed to
>> DT_DEV_PIXELPIPE_PREVIEW or _EXPORT) an
heya,
for modules that work on raw data, the full pipeline is unscaled
(hence your constant scale factors). all we do here is provide input
cropped to the region of interest your module requested during the
modify_roi_in() pass that is run before process() is called (there is
a default implementat
era.py to profile the camera and nlm_raw_profiled
>> to denoise a raw image. The code isn't elaborated and slow as hell, but it
>> provides an idea of the results. It only works with Bayer sensors.
>>
>> Best,
>> Bjoern
>>
>> 2018-02-18 13:33 GMT+01:
hi!
sure, everything that improves noise reduction will be a welcomed
addition. glancing over the paper you mention, it is based on
non-local means and a global minimisation/total variation step. keep
in mind that for interactive usage we need to render several
megapixels through all necessary mod
far as I understand, it gives a way to choose an adaptated window size
> for each pixel, but I don't see in the code anything related to that
>
> Maybe is this paper related to the TODOs in the code ?
>
> Was it planned to implement such a variable window approach ?
>
> O
hi,
if you want, absolutely do play around with K. in my tests it did not
lead to any better denoising. to my surprise a larger K often led to
worse results (for some reason often the relevance of discovered
patches decreases with distance from the current point). that's why K
is not exposed in th
heya,
please keep replies on the list in case anyone else is interested or i
get lost or similar :)
-jo
On Mon, Jan 8, 2018 at 4:56 PM, ben rudgers wrote:
> Just a clarification on my last email.
>
> 0. I was able to apply 20 or so operations without a crash before I applied
> the frame.
>
> 1.
ill also correlate to the edited file.
>
> + Discarding the history stack seems to allow the file to receive a few
> edits before crashing.
>
> Thanks,
>
> Ben
>
>
>
> On 01/07/2018 02:40 PM, johannes hanika wrote:
>>
>> hi,
>>
>> thanks for
hi,
thanks for the report.
some questions:
does that only happen on this specific image? did darktable write a
stack trace to /tmp/darktable-bt-* ? if so, could you poste this file?
how much ram does your machine have?
cheers,
jo
On Mon, Jan 8, 2018 at 9:23 AM, ben rudgers wrote:
> Behaviors:
hi,
On Mon, Dec 4, 2017 at 3:39 PM, Terry Duell wrote:
> On Mon, 04 Dec 2017 03:10:51 +1100, Tobias Ellinghaus wrote:
>
>> we're proud to announce the first release candidate for the upcoming 2.4
>> series of darktable, 2.4.0rc0!
>>
>> the github release is here: https://github.com/darktable-org
hi,
yes i think that request makes sense.
cheers,
jo
On Fri, Dec 1, 2017 at 11:37 AM, Aurélien PIERRE
wrote:
> Hi,
>
> I have been using the local contrast module with the laplacian filter on the
> git/master version for a few months now, and I noticed that it's impossible
> to push highlights
heya,
On Sun, Dec 3, 2017 at 1:12 AM, Dominik Markiewicz
wrote:
> Hi,
> Small tip from my side. It's not perfect (yet! :) but it speedup my
> processing a bit.
>
> I've split my workflow for a few steps. For each step I've select a few
> modules I'm using 99% of the time. Then I've selected them
.. also the screenshot shows the output of `exiftool' not `exiv2' so
it's not clear whether libexiv2 would report the correct id to dt to
pass it on to lensfun..
-jo
On Mon, Nov 6, 2017 at 1:37 AM, Patrick Shanahan wrote:
> * Holger Klemm [11-05-17 04:29]:
>> Yesterday I tested the Tamron 10-24
On Mon, Oct 16, 2017 at 11:21 PM, Tobias Ellinghaus wrote:
> Am Sonntag, 15. Oktober 2017, 14:51:47 CEST schrieb Aurélien PIERRE:
>> Hi,
>>
>> this technic aims at solving all kinds of blurs (static and motion
>> blurs). The most challenging configuration is when the blur is not
>> uniform along t
hi,
1) 16s in single-thread python sounds like it would be possible to do
< 100ms in a programming language.
4) that depends on the order of modules. if you want to do it in the
current sharpen module as an option, it'll come pretty much last. if
you do it early, dt will transparently cache the o
.. and that is images, not bytes in the db, right? most impressive :)
any particular operations that show significant slowdown due to this?
or does it just work?
cheers,
jo
On Tue, Sep 26, 2017 at 4:45 AM, Patrick Shanahan wrote:
> this morning my library contained >88.5k
>
>
> --
> (paka)Patr
hi,
i disagree. i really like variable length arrays. and std::vectors
dynamically allocate memory on the heap, with standard implementations
locking a global mutex on the way, causing slowdown for multithreaded
cases. just incrementing the stack pointer is a simple thing, it's
thread local and li
heya,
On Thu, Sep 7, 2017 at 12:57 PM, Heiko Bauke wrote:
> Hi,
>
> Am 03.09.2017 um 13:46 schrieb Heiko Bauke:
>>
>> yes I just dropped the tonecurve information because this gave me the
>> best results in some test cases. Investigating the source code of
>> darktable-chart I realized that drop
hi,
that means you are dropping the tonecurve information? or is that
baked into the clut, too?
cheers,
jo
On Sun, Sep 3, 2017 at 6:38 AM, Heiko Bauke wrote:
> Hi,
>
> Am Samstag 2. September 2017 schrieb johannes hanika:
>> wow, supercool, thanks for this effort! what exactl
wow, supercool, thanks for this effort! what exactly was the tweak you
needed to do for darktable-chart?
-jo
On Sat, Sep 2, 2017 at 11:13 PM, Heiko Bauke wrote:
> Hi,
>
> the G'MIC film emulation tool (see http://gmic.eu/film_emulation/index.shtml
> ) is very nice for emulating the look of old a
ght be
> possible to include it in the upcoming 2.4.0 release...
>
> Cheers,
> Ingo
>
>
> Am 14.05.2017 um 21:06 schrieb johannes hanika :
>
> nice thanks! will give it a read!
>
> -jo
>
> On Mon, May 15, 2017 at 6:55 AM, Ingo Liebhardt
> wrote:
pull it in as a dependency.
cheers,
jo
On Fri, Jul 28, 2017 at 9:24 PM, Heiko Bauke wrote:
> Dear Johannes,
>
> Am 12.07.2017 um 10:06 schrieb johannes hanika:
>>
>> sounds weird, will try to reproduce. the fitting of this function is
>> using a spline, which ma
heya,
sounds weird, will try to reproduce. the fitting of this function is
using a spline, which may be prone to ringing, in between the colours
you fixed. it has a linear part that fixes this issue for purely b/w,
but may lead to issues for b/w + single colour.
cheers,
-jo
On Tue, Jul 11, 2017
heya,
On Thu, Jun 22, 2017 at 4:35 AM, Moritz Mœller (The Ritz)
wrote:
> On June 20, 2017 18:34:27 Roman Lebedev wrote:
>>
>> On Tue, Jun 20, 2017 at 5:55 PM, Moritz Moeller
>> wrote:
>>>
>>> On 20.6.17 11:43 , Tobias Ellinghaus wrote:
>>> I'm using a local build with [...] Wolfgang Mader's
>>>
ers,
> Ingo
>
>
>
> Am 08.05.2017 um 22:58 schrieb johannes hanika :
>
> heya,
>
> doesn't sound too bad for something that hasn't been optimised at all
> yet. did you describe what you do on a high level somewhere on your
> blog? or is the best docume
's hope... actually, up to now I was really focusing on
> the algorithm itself and on demosaicking quality. Code is still dirty and I
> think there's potential.
> I'd use FFT for convolutions. As said, some more info to come tomorrow.
> Cheers,
> Ingo
>
>
> Am 07.0
t; works quite well in OpenCL.
so there may be hope :)
cheers,
jo
>
> Cheers,
> Ingo
>
>
>> Am 07.05.2017 um 20:03 schrieb johannes hanika :
>>
>> heya,
>>
>> nice results! especially the high iso one shows quite a bit more
>> pleasant noise behav
heya,
nice results! especially the high iso one shows quite a bit more
pleasant noise behaviour in the gray center patch.
how bad is the performance? do you think it could be improved? does it
use SIMD/openmp yet and how promising would an opencl code path be?
cheers,
jo
On Mon, May 8, 2017 at
17 at 2:54 PM, johannes hanika wrote:
> great, we've got a flamewar! let me join the fun:
>
> i'm very much unconvinced by their examples re: lens blur or generic
> sharpening. it has the typical fourier artifacts (even though the
> ringing seems surprisingly well balance
great, we've got a flamewar! let me join the fun:
i'm very much unconvinced by their examples re: lens blur or generic
sharpening. it has the typical fourier artifacts (even though the
ringing seems surprisingly well balanced in their examples. but i can
still see it). i think our current local co
hi all,
i added a few minor updates to the color checker lut module and
related workflow:
1) the tonecurve has a new mode: adjust color automatic in RGB. this
pretty much turns the tone curve into a prophoto-rgb cure
2) darktable-chart uses this mode in a tonecurve when fitting luts to
pairs of
hi all, especially hi to all yahoo users here.
i think all of you noticed the bounce messages we sometimes get from
this list. it's not all that often but kind of annoying. turns out
it's some anti-spam mechanism enforced by yahoo that goes berserk (see
for instance this email thread for the mail
wow, this looks interesting and useful!
cheers,
jo
On Wed, Mar 22, 2017 at 11:55 PM, Heiko Bauke wrote:
> Hi,
>
> in Darktable masks can be blurred by a Gaussian filter. I have implemented
> an experimental feature to modify parametric and drawn masks by another kind
> of filter called guided
there a official benchmark for these darktable OCL kernels for
> evaluation?
> Thanks.
>
>
>
> yan.wang
>
>
> From: johannes hanika
> Date: 2017-02-22 19:00
> To: yan.wang
> CC: darktable-dev
> Subject: Re: Re: [darktable-dev] Darktable on
f my patch is OK, could you please merge it and remove beignet from
> black list?
> Thanks.
>
> Yan Wang
>
>
> yan.wang
>
>
> From: johannes hanika
> Date: 2017-02-22 17:11
> To: yan.wang
> CC: darktable-dev
> Subject: Re
hi,
thanks for looking into this!
/0 is not nice in any case.. but i doubt your fix is the best we can
do. num should be incremented whenever a value is smaller than or
equal to a threshold, which is chosen based on the min and max of
these very values. the case num==0 should really never happen
hi,
a few modules have similar requirements. you can have a look for
instance in the ashift.c module, where it says:
// only for preview pipe: collect input buffer data and do some other
evaluations
if(self->dev->gui_attached && g && piece->pipe->type ==
DT_DEV_PIXELPIPE_PREVIEW)
{
there is
hi,
as of dev documentation: there's our irc channel which you may find
most useful.. and src/iop/useless.c
https://github.com/darktable-org/darktable/blob/master/src/iop/useless.c
which implements all required callbacks and comes with a couple of
code comments that should get you started.
cheers
hi,
how much do you trust your numbers? they look very weird to me. such a
speedup sounds more like one is running single threaded :)
did you run it a couple of times one after the other? to rule out disk
prefetching etc? using the minimum time of three consecutive runs may
be a good indication.
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
On Mon, Jan 30, 2017 at 5:38 PM, Dan Torop wrote:
> I should also mention that the Bayer downscale code for th
i'm not sure i understand this.. but could you try again now please?
-jo
On Thu, Jan 19, 2017 at 2:11 PM, johannes hanika wrote:
> those pyramids are terrible. and the boundary conditions are the
> worst. they are different if the image dimension is a multiple of 2
> (that'
me. I'm getting a black bar on the right. Only
>> happens using laplacian filter. Tried four images. Happens for every one.
>> Fresh git pulled 5 minutes ago.
>>
>> Regards
>>
>> Dave Jones
>>
>>
>> On Thu, 19 Jan 2017, 14:50 johannes hani
heya,
if any one of you uses git master.. could you tell me if the current
version resolves your opencl boundary handling issues? it seems to be
fixed for me now.
cheers,
jo
On Mon, Jan 16, 2017 at 6:48 PM, johannes hanika wrote:
> if i manage to fix this boundary handling thing.. ope
if i manage to fix this boundary handling thing.. opencl should be a
lot faster especially on this local laplacing. maybe there's something
odd with the setup.
-jo
On Tue, Jan 17, 2017 at 5:12 AM, David Vincent-Jones wrote:
> Yes, definitely related to OpenCL!
>
> Frankly, on my system OpenCL 'f
yeah sorry.. will fix it once i get my life back end of this week :)
-jo
On Mon, Jan 16, 2017 at 8:09 AM, Christian Kanzian
wrote:
> Hi,
>
> Looks like this issue: https://redmine.darktable.org/issues/11434
>
>> darktable 2.3.0+git247.4b67f41-1.1 ... openSUSE 42.2 (Recently
>> installed OpenCL)
hi,
yeah not sure the ui is perfect yet.. maybe you're running into the
issue that you can't create patches, but only delete or update? also,
sometimes the colour picker will give you a patch with unexpected
colour because it matches colour + brightness (and in fact usually
after reconsidering i f
yeah that is annoying. is it a good idea to add that file to
.gitignore? or is this indeed the mechanism to update the submodule?
-jo
On Wed, Jan 4, 2017 at 7:57 AM, Ulrich Pegelow
wrote:
> Am 03.01.2017 um 17:29 schrieb Roman Lebedev:
>>
>> On Tue, Jan 3, 2017 at 7:22 PM, Ulrich Pegelow
>>>
>>>
On Sun, Dec 18, 2016 at 12:09 AM, Tobias Ellinghaus wrote:
> Am Samstag, 17. Dezember 2016, 04:17:57 CET schrieb Aurélien PIERRE:
>> Yes I did as said in the post on DT's blog.
>>
>> Tobias, I'm on laptop with Intel® Core™ i7-2670QM CPU @ 2.20GHz × 8 and
>> Intel Sandybridge + Nvidia Geforce GT 6
1 - 100 of 179 matches
Mail list logo
