Re: [darktable-dev] Problem with some Leica DNG files

[Roman Lebedev]

On Tue, Aug 1, 2017 at 1:04 AM, Laurent Latxague  wrote:

> Regarding this particular issue :
>
> (2) All DNG pictures appear strongly pixellized (with ctrl-Z in the
>> lightable) contrary to my CR2 or RAF files
>>
> That only shows low-quality thumbnail, so it is kind-of expected.
>
>
> In the lightable, using Z or ctrl-Z of JPEG files straight from the camera
> is ok; on the corresponding DNG files it pixellizes. But meanwhile, if I
> work on the DNG file (even a little, for example by putting a bit more
> exposure in the darkroom), and then come back to the lightable, then Z or
> ctrl-Z magnifies the thumbnail correctly...
> I'm sorry to insist, but don't you think it's a bug regarding the way DT
> handles Leica DNG files ? Why these Leica DNG thumbnails would be expected
> (initially at least) to be of low quality and not the others (from Canon or
> Fuji) ?
>
https://www.darktable.org/usermanual/ch08.html.php#gui_options
I suspect "don't use embedded preview JPEG but half-size raw" is disabled?
The thumbnail embedded in leica raw's, as you can see, is really tiny.
You could enable that option, and then you will never see the embedded
thumbnail.


> --
>
Roman.

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

Re: [darktable-dev] Problem with some Leica DNG files

[Laurent Latxague]

Regarding this particular issue :


(2) All DNG pictures appear strongly pixellized (with ctrl-Z in
the lightable) contrary to my CR2 or RAF files

That only shows low-quality thumbnail, so it is kind-of expected.



In the lightable, using Z or ctrl-Z of JPEG files straight from the 
camera is ok; on the corresponding DNG files it pixellizes. But 
meanwhile, if I work on the DNG file (even a little, for example by 
putting a bit more exposure in the darkroom), and then come back to the 
lightable, then Z or ctrl-Z magnifies the thumbnail correctly...
I'm sorry to insist, but don't you think it's a bug regarding the way DT 
handles Leica DNG files ? Why these Leica DNG thumbnails would be 
expected (initially at least) to be of low quality and not the others 
(from Canon or Fuji) ?

--

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

Re: [darktable-dev] Tagging module: What the...

[August Schwerdfeger]

I have used nothing but the Ctrl+T method for some time (I experience lags
of about 10 seconds between typing a tag name into the module and its
actual appearance in the text box).

For a while, I could get the Ctrl+T tagging to go faster by keeping the
name of a non-existent tag (e.g., "abcdefg") in the module text box, but
now even that does not work very well.

--
August Schwerdfeger
aug...@schwerdfeger.name

On Mon, Jul 31, 2017 at 3:39 AM, Tobias Ellinghaus  wrote:

> Am Samstag, 29. Juli 2017, 22:14:09 CEST schrieb August Schwerdfeger:
> > Darktable 1.4.2, 1.6.9, 2.0.7, and 2.2.4, on Fedora, CentOS, and OS X.
> >
> > There is something seriously wrong with Darktable's tagging module.
> >
> > As I have used successive versions of Darktable with databases containing
> > an increasing number of tags, the tagging module has gradually become so
> > slow in its operation as to be essentially unusable.
> >
> > For example, recently, on a database containing ~2500 tags, I attempted
> to
> > attach a single tag to ~250 images. This operation took approximately
> three
> > minutes, during which time Darktable was unresponsive and consistently
> used
> > about 100% of two cores.
>
> That sounds bad. How did you tag the images? By selecting the tag in the
> tagging module and clicking the "attach" button, or using the quick tag
> feature (ctrl-t, type, enter)? Could you please try the latter if you
> didn't
> do so before and tell me if that's faster?
>
> > By way of comparison, I accessed a copy of the database file directly and
> > used an INSERT INTO command to apply the same tag to the same images.
> This
> > took about 20ms.
> >
> > Since actually attaching the tag is clearly not taking six minutes of
> > processor time, what else is the tagging module doing that could possibly
> > be causing these delays (and, what is more to the point, how do I work
> > around it so I can actually use the thing again)?
> >
> > --
> > August Schwerdfeger
> > aug...@schwerdfeger.name
>
> Tobias

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

Re: [darktable-dev] Problem with some Leica DNG files

[Laurent Latxague]

Yes, my mistake, it works now... You'll receive the file that freezes DT 
soon !



Le 31/07/2017 à 17:52, Roman Lebedev a écrit :
On Mon, Jul 31, 2017 at 6:46 PM, Laurent Latxague > wrote:


Ok I was able to log to redmine.darktable.org
 etc. but don't know what to do then
and how to attach my file (26Mb)...

Not sure what you mean, the link i posted has field "Files" with max 
file size of 48.8 MB



Le 31/07/2017 à 17:07, Roman Lebedev a écrit :

On Mon, Jul 31, 2017 at 5:59 PM, Laurent Latxague
> wrote:

I'm currently using DT 2.2.5, and the compressed DNG + the
JPEG associated files are directly copied from the SD card to
the computer.

I first imagined those files corrupted in one way or another,
but RawTherapee on the other hand is indeed able to open them...

 Aha, interesting,
https://redmine.darktable.org/projects/darktable/issues/new
 +
attach one of such images...

What's the reason for the low quality thumbnails BTW ?

Well, they are thumbnails, *thumb* *nails*, very small, pretty
fast :)


Le 31/07/2017 à 16:18, Roman Lebedev a écrit :

On Mon, Jul 31, 2017 at 5:04 PM, Laurent Latxague
> wrote:

Hello !

Hi.

I have never experienced any problems with my former
cameras (Canon 5D II, III, Fuji X-Trans) in DT, but
since I switched to Leica some things are going wrong...

Which dt version?

(1) Generally speaking, Leica support seems rather poor
in DT, hence my first disappointment (I recently
purchased a used M typ 240). No lens support for example
for the lens correction module. BTW how can I contribute
as a user to help in this way ? (I read the following
page https://raw.pixls.us/ but there is already a M240
picture, so what ?)

Lens correction is lensfun problem,
http://lensfun.sourceforge.net/lenslist/

http://lensfun.sourceforge.net/calibration/


(2) All DNG pictures appear strongly pixellized (with
ctrl-Z in the lightable) contrary to my CR2 or RAF files

That only shows low-quality thumbnail, so it is kind-of
expected.

(3) A few DNG pictures (actually one picture for the
moment) can't be loaded in the darkroom, a message says
that the white balance cannot be read from the camera,
and then DT freezes...

(4) Some thumbnails (2 actually and always the same ones
despite several imports of the original files) appear as
skulls...

That is the same problem.
Are those DNG straight out of camera, or?

(5) Last, but not least the above 3 "faulty" files
appear flawlessly... in RawTherapee ! Very irritating
since I don't intend to move to RT...

Any help or suggestion please ?

TY in advance ! --

Roman.

-- 




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



Roman.



-- 





--

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

Re: [darktable-dev] possible bug in color look up table module

[Heiko Bauke]

Dear Roman,

Am 31.07.2017 um 17:45 schrieb Roman Lebedev:

I suspect you (or your editor) have run clang-format/etc on that file.
Don't do that.


mentioning  clang-format I remember I run clang-format on that file 
indeed.  I did to ensure that my changes are compatible with darktable 
coding style conventions.  I assumed running clang-format would affect 
only lines of code that have been touched by me.


I plan to write a fix for the color look up table module.  I will try to 
 keep the change set as small as possible when opening a pull request.



Heiko


--
-- Number Crunch Blog @ https://www.numbercrunch.de
--  Cluster Computing @ http://www.clustercomputing.de
--   Professional @ https://www.mpi-hd.mpg.de/personalhomes/bauke
--  Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Problem with some Leica DNG files

[Roman Lebedev]

On Mon, Jul 31, 2017 at 6:46 PM, Laurent Latxague  wrote:

> Ok I was able to log to redmine.darktable.org etc. but don't know what to
> do then and how to attach my file (26Mb)...
>
Not sure what you mean, the link i posted has field "Files" with max file
size of 48.8 MB

>
> Le 31/07/2017 à 17:07, Roman Lebedev a écrit :
>
> On Mon, Jul 31, 2017 at 5:59 PM, Laurent Latxague  wrote:
>
>> I'm currently using DT 2.2.5, and the compressed DNG + the JPEG
>> associated files are directly copied from the SD card to the computer.
>>
>> I first imagined those files corrupted in one way or another, but
>> RawTherapee on the other hand is indeed able to open them...
>>
>  Aha, interesting, https://redmine.darktable.org/projects/
> darktable/issues/new + attach one of such images...
>
> What's the reason for the low quality thumbnails BTW ?
>>
> Well, they are thumbnails, *thumb* *nails*, very small, pretty fast :)
>
>
>> Le 31/07/2017 à 16:18, Roman Lebedev a écrit :
>>
>> On Mon, Jul 31, 2017 at 5:04 PM, Laurent Latxague 
>> wrote:
>>
>>> Hello !
>>>
>> Hi.
>>
>>> I have never experienced any problems with my former cameras (Canon 5D
>>> II, III, Fuji X-Trans) in DT, but since I switched to Leica some things are
>>> going wrong...
>>>
>> Which dt version?
>>
>>> (1) Generally speaking, Leica support seems rather poor in DT, hence my
>>> first disappointment (I recently purchased a used M typ 240). No lens
>>> support for example for the lens correction module. BTW how can I
>>> contribute as a user to help in this way ? (I read the following page
>>> https://raw.pixls.us/ but there is already a M240 picture, so what ?)
>>>
>> Lens correction is lensfun problem, http://lensfun.source
>> forge.net/lenslist/ http://lensfun.sourceforge.net/calibration/
>>
>>> (2) All DNG pictures appear strongly pixellized (with ctrl-Z in the
>>> lightable) contrary to my CR2 or RAF files
>>>
>> That only shows low-quality thumbnail, so it is kind-of expected.
>>
>>> (3) A few DNG pictures (actually one picture for the moment) can't be
>>> loaded in the darkroom, a message says that the white balance cannot be
>>> read from the camera, and then DT freezes...
>>>
>>> (4) Some thumbnails (2 actually and always the same ones despite several
>>> imports of the original files) appear as skulls...
>>>
>> That is the same problem.
>> Are those DNG straight out of camera, or?
>>
>>> (5) Last, but not least the above 3 "faulty" files appear flawlessly...
>>> in RawTherapee ! Very irritating since I don't intend to move to RT...
>>>
>>> Any help or suggestion please ?
>>> TY in advance ! --
>>>
>> Roman.
>>
>>
>>> --
>>>
>>>
>>> ___
>>> darktable developer mailing list to unsubscribe send a mail to
>>> darktable-dev+unsubscr...@lists.darktable.org
>>>
>> Roman.
>
>
>
> --
>

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

Re: [darktable-dev] Problem with some Leica DNG files

[Laurent Latxague]

Ok I was able to log to redmine.darktable.org etc. but don't know what 
to do then and how to attach my file (26Mb)...



Le 31/07/2017 à 17:07, Roman Lebedev a écrit :
On Mon, Jul 31, 2017 at 5:59 PM, Laurent Latxague > wrote:


I'm currently using DT 2.2.5, and the compressed DNG + the JPEG
associated files are directly copied from the SD card to the computer.

I first imagined those files corrupted in one way or another, but
RawTherapee on the other hand is indeed able to open them...

 Aha, interesting, 
https://redmine.darktable.org/projects/darktable/issues/new + attach 
one of such images...


What's the reason for the low quality thumbnails BTW ?

Well, they are thumbnails, *thumb* *nails*, very small, pretty fast :)


Le 31/07/2017 à 16:18, Roman Lebedev a écrit :

On Mon, Jul 31, 2017 at 5:04 PM, Laurent Latxague
> wrote:

Hello !

Hi.

I have never experienced any problems with my former cameras
(Canon 5D II, III, Fuji X-Trans) in DT, but since I switched
to Leica some things are going wrong...

Which dt version?

(1) Generally speaking, Leica support seems rather poor in
DT, hence my first disappointment (I recently purchased a
used M typ 240). No lens support for example for the lens
correction module. BTW how can I contribute as a user to help
in this way ? (I read the following page
https://raw.pixls.us/ but there is already a M240 picture, so
what ?)

Lens correction is lensfun problem,
http://lensfun.sourceforge.net/lenslist/

http://lensfun.sourceforge.net/calibration/


(2) All DNG pictures appear strongly pixellized (with ctrl-Z
in the lightable) contrary to my CR2 or RAF files

That only shows low-quality thumbnail, so it is kind-of expected.

(3) A few DNG pictures (actually one picture for the moment)
can't be loaded in the darkroom, a message says that the
white balance cannot be read from the camera, and then DT
freezes...

(4) Some thumbnails (2 actually and always the same ones
despite several imports of the original files) appear as
skulls...

That is the same problem.
Are those DNG straight out of camera, or?

(5) Last, but not least the above 3 "faulty" files appear
flawlessly... in RawTherapee ! Very irritating since I don't
intend to move to RT...

Any help or suggestion please ?

TY in advance ! --

Roman.

-- 




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



Roman.



--

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

Re: [darktable-dev] possible bug in color look up table module

[Heiko Bauke]

Dear Johannes,

Am 31.07.2017 um 04:18 schrieb johannes hanika:

oh, nice, thanks for looking into this!

i can't parse your diff, it has so many white space changes. could you
maybe fix it or explain what it does? is it just a special case for
the zero-patch case?

yeah the solver sucks. unfortunately eigen is written in c++, so i'm
hesitant to pull it in as a dependency.


in the color look up module we have to solve a linear system of size 
(N+4)x(N+4) where N is the number of color patches.  The problem is that 
for N<=4 the coefficient matrix A has rank N, not the full rank N+4. 
This means that the system has non-unique solutions.  Thus we have to 
pick a reasonable solution among the infinite set of solutions for N<=4. 
 I think the most reasonable solution is to set as many as possible 
coefficients to zero.  For the remaining coefficients, one can derive a 
smaller full-rank linear system.  This approach is numerically very 
stable and explained in more detail in the python prototype attached to 
this e-mail.


Assuming that all source colors are different, the (N+4)x(N+4) 
coefficient matrix has full rank and can be solved by various methods. 
LU-decomposition with partial pivoting but also numerical solution via 
singular value decomposition as implemented in the python script work 
quite well.  I also tried various variants of Newton iteration, which 
often also gives accurate results.  In the Newton iteration approach, 
one minimizes |A*x - b|, where x is the vector of unknowns and b the 
right-hand-side of the linear system.  For the Newton iteration, one has 
to find an approximate solution to a linear system of the form 2*A^2 * y 
= c.  I tried various methods for solving the latter equation.


The modified version of colochecker.c in my github repository deals only 
with the N=0 case.  The diffs may show an unreasonable large change set 
because my editor has automatically removed white spaces at the end of 
lines.



Heiko


--
-- Number Crunch Blog @ https://www.numbercrunch.de
--  Cluster Computing @ http://www.clustercomputing.de
--   Professional @ https://www.mpi-hd.mpg.de/personalhomes/bauke
--  Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org#!/usr/bin/env python3
# -*- coding: utf-8 -*-

# calculate interpolation coefficients as needed in
# the darktable color look up module 

# import math and plotting modules
import numpy as np
from pylab import *
from scipy.optimize import minimize, curve_fit
from scipy.linalg import *

# the source colors
S=array([37.99, 13.56,  14.06,  # dark skin
 65.71, 18.13,  17.81,  # light skin
 49.93, -4.88,  -21.93, # blue sky
 43.14, -13.10, 21.91,  # foliage
 55.11, 8.84,   -25.40, # blue flower
 70.72, -33.40, -0.20,  # bluish green
 62.66, 36.07,  57.10,  # orange
 40.02, 10.41,  -45.96, # purple red
 51.12, 48.24,  16.25,  # moderate red
 30.33, 22.98,  -21.59, # purple
 72.53, -23.71, 57.26,  # yellow green
 71.94, 19.36,  67.86,  # orange yellow
 28.78, 14.18,  -50.30, # blue
 55.26, -38.34, 31.37,  # green
 42.10, 53.38,  28.19,  # red
 81.73, 4.04,   79.82,  # yellow
 51.94, 49.99,  -14.57, # magenta
 51.04, -28.63, -28.64, # cyan
 96.54, -0.43,  1.19,   # white
 81.26, -0.64,  -0.34,  # neutral 8
 66.77, -0.73,  -0.50,  # neutral 65
 50.87, -0.15,  -0.27,  # neutral 5
 35.66, -0.42,  -1.23,  # neutral 35
 20.46, -0.08,  -0.97   # black
])
S=reshape(S, (24, 3))

channel=1 # select a channel, (0, 1, 2) for (L, a, b)
# reduce number of color mappings for testing
# try N>4 for the nummerically instable cases
N=5
q=array(range(0, 24))
np.random.shuffle(q)
S=S[q[0:N], :] # random selection of original colors

# construct coefficient matrix

# the radial basis function
def kernel(a, b):
r2=dot(a-b, a-b)
return r2*log(r2) if r2>1e-12 else 0

A=zeros((N+4, N+4))
for i in range(0, N):
for j in range(0, N):
A[i, j]=kernel(S[i, :], S[j, :])
A[i, N+0]=A[N+0, i]=1
A[i, N+1]=A[N+1, i]=S[i, 0]
A[i, N+2]=A[N+2, i]=S[i, 1]
A[i, N+3]=A[N+3, i]=S[i, 2]

T=zeros((N+4))
T[0:N]=S[:, channel] + 10*randn(N)  # target color channel, start from original color and modify

# quadratic cost function to be minimized (A must be symetric)
def N2(x):
return norm(dot(A, x)-T)

# gradient of cost function
def dN2(x):
return 2*dot(A, dot(A, x)-T)

# jacobian of cost function
def ddN2():
return 2*dot(A, A)

# solve the linear system, treat special cases N=0, N=1, N=2, N=3, N=4
# extra, solve cases N>4 by different methods

# for N<=4 the linear system has rank N, i.e. less than the dimension
# of the coefficient matrix the linear 

Re: [darktable-dev] Problem with some Leica DNG files

[Roman Lebedev]

On Mon, Jul 31, 2017 at 5:59 PM, Laurent Latxague  wrote:

> I'm currently using DT 2.2.5, and the compressed DNG + the JPEG associated
> files are directly copied from the SD card to the computer.
>
> I first imagined those files corrupted in one way or another, but
> RawTherapee on the other hand is indeed able to open them...
>
 Aha, interesting,
https://redmine.darktable.org/projects/darktable/issues/new + attach one of
such images...

What's the reason for the low quality thumbnails BTW ?
>
Well, they are thumbnails, *thumb* *nails*, very small, pretty fast :)


> Le 31/07/2017 à 16:18, Roman Lebedev a écrit :
>
> On Mon, Jul 31, 2017 at 5:04 PM, Laurent Latxague  wrote:
>
>> Hello !
>>
> Hi.
>
>> I have never experienced any problems with my former cameras (Canon 5D
>> II, III, Fuji X-Trans) in DT, but since I switched to Leica some things are
>> going wrong...
>>
> Which dt version?
>
>> (1) Generally speaking, Leica support seems rather poor in DT, hence my
>> first disappointment (I recently purchased a used M typ 240). No lens
>> support for example for the lens correction module. BTW how can I
>> contribute as a user to help in this way ? (I read the following page
>> https://raw.pixls.us/ but there is already a M240 picture, so what ?)
>>
> Lens correction is lensfun problem, http://lensfun.
> sourceforge.net/lenslist/ http://lensfun.sourceforge.net/calibration/
>
>> (2) All DNG pictures appear strongly pixellized (with ctrl-Z in the
>> lightable) contrary to my CR2 or RAF files
>>
> That only shows low-quality thumbnail, so it is kind-of expected.
>
>> (3) A few DNG pictures (actually one picture for the moment) can't be
>> loaded in the darkroom, a message says that the white balance cannot be
>> read from the camera, and then DT freezes...
>>
>> (4) Some thumbnails (2 actually and always the same ones despite several
>> imports of the original files) appear as skulls...
>>
> That is the same problem.
> Are those DNG straight out of camera, or?
>
>> (5) Last, but not least the above 3 "faulty" files appear flawlessly...
>> in RawTherapee ! Very irritating since I don't intend to move to RT...
>>
>> Any help or suggestion please ?
>> TY in advance ! --
>>
> Roman.
>
>
>> --
>>
>>
>> ___
>> darktable developer mailing list to unsubscribe send a mail to
>> darktable-dev+unsubscr...@lists.darktable.org
>>
> Roman.

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

Re: [darktable-dev] Problem with some Leica DNG files

[Laurent Latxague]

I'm currently using DT 2.2.5, and the compressed DNG + the JPEG 
associated files are directly copied from the SD card to the computer.


I first imagined those files corrupted in one way or another, but 
RawTherapee on the other hand is indeed able to open them...


What's the reason for the low quality thumbnails BTW ?


Le 31/07/2017 à 16:18, Roman Lebedev a écrit :
On Mon, Jul 31, 2017 at 5:04 PM, Laurent Latxague > wrote:


Hello !

Hi.

I have never experienced any problems with my former cameras
(Canon 5D II, III, Fuji X-Trans) in DT, but since I switched to
Leica some things are going wrong...

Which dt version?

(1) Generally speaking, Leica support seems rather poor in DT,
hence my first disappointment (I recently purchased a used M typ
240). No lens support for example for the lens correction module.
BTW how can I contribute as a user to help in this way ? (I read
the following page https://raw.pixls.us/ but there is already a
M240 picture, so what ?)

Lens correction is lensfun problem, 
http://lensfun.sourceforge.net/lenslist/ 
http://lensfun.sourceforge.net/calibration/


(2) All DNG pictures appear strongly pixellized (with ctrl-Z in
the lightable) contrary to my CR2 or RAF files

That only shows low-quality thumbnail, so it is kind-of expected.

(3) A few DNG pictures (actually one picture for the moment) can't
be loaded in the darkroom, a message says that the white balance
cannot be read from the camera, and then DT freezes...

(4) Some thumbnails (2 actually and always the same ones despite
several imports of the original files) appear as skulls...

That is the same problem.
Are those DNG straight out of camera, or?

(5) Last, but not least the above 3 "faulty" files appear
flawlessly... in RawTherapee ! Very irritating since I don't
intend to move to RT...

Any help or suggestion please ?

TY in advance ! --

Roman.

-- 



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





--

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

Re: [darktable-dev] Problem with some Leica DNG files

[Roman Lebedev]

On Mon, Jul 31, 2017 at 5:04 PM, Laurent Latxague  wrote:

> Hello !
>
Hi.

> I have never experienced any problems with my former cameras (Canon 5D II,
> III, Fuji X-Trans) in DT, but since I switched to Leica some things are
> going wrong...
>
Which dt version?

> (1) Generally speaking, Leica support seems rather poor in DT, hence my
> first disappointment (I recently purchased a used M typ 240). No lens
> support for example for the lens correction module. BTW how can I
> contribute as a user to help in this way ? (I read the following page
> https://raw.pixls.us/ but there is already a M240 picture, so what ?)
>
Lens correction is lensfun problem, http://lensfun.sourceforge.net/lenslist/
 http://lensfun.sourceforge.net/calibration/

> (2) All DNG pictures appear strongly pixellized (with ctrl-Z in the
> lightable) contrary to my CR2 or RAF files
>
That only shows low-quality thumbnail, so it is kind-of expected.

> (3) A few DNG pictures (actually one picture for the moment) can't be
> loaded in the darkroom, a message says that the white balance cannot be
> read from the camera, and then DT freezes...
>
> (4) Some thumbnails (2 actually and always the same ones despite several
> imports of the original files) appear as skulls...
>
That is the same problem.
Are those DNG straight out of camera, or?

> (5) Last, but not least the above 3 "faulty" files appear flawlessly... in
> RawTherapee ! Very irritating since I don't intend to move to RT...
>
> Any help or suggestion please ?
> TY in advance ! --
>
Roman.


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

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

Re: [darktable-dev] Redmine bug #10333 and X-Trans demosaicking re-visited

[johannes hanika]

hi ingo!

wow, that's great news :) unfortunately i only found time to have a
very quick look, i hope things cool down a little here near end of
year.

so now wer'e talking what time frame for a full 20MP export? 10-20sec?
we'll need to discuss what to do with the additional fftw dependency.
i guess we could wire it as an optional with #ifdef? but that would
change the rendering of pictures on different machines.

cheers,
 jo

On Mon, Jul 31, 2017 at 3:58 AM, Ingo Liebhardt  wrote:
> Hi Jo,
>
> In the meanwhile I applied FFTW, and I found some other ways to save
> processing time.
> All in all, processing time is now roughly half, and it’s usable even on my
> weak machine.
> The description in the dropbox location is adapted accordingly.
>
> Again, I’d like to thank François Guerraz for giving me a helping hand.
> Pixel peeping can cause one to lose track of the big picture, and he
> convinced me to go less heavy on the chroma filtering, which I admit was a
> good thing to do.
> The noise behaviour for high iso is now a bit less favourable, but the
> chroma response is better. Chroma noise can still be handled by the
> corresponding modules of darktable, based on the user’s preference.
>
> All in all, my impression is that it’s more usable than Markesteijn.
> If you want to take a look: https://github.com/ILiebhardt/darktable
>
> I’ll now clean it up and try to prepare a proper commit, maybe it might 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:
>
> Hi Jo,
>
> I made a high level description of the algorithm.
> You can download it at
> https://www.dropbox.com/s/wshrkfhylnikpei/FDC%20high%20level%20desc.pdf?dl=0
>
> Together with the code, it shows quite well how the algorithm works.
>
> I already made some comments on a few performance considerations myself.
> I’ll work on these in the coming weeks…
> In the end, I’m quite optimistic now that this can be made to run reasonably
> quickly.
>
> Cheers,
> 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 documentation reading the code? maybe it would be
> good to do one pass over the high level algorithm to find out whether
> there may be a better/faster way to achieve the same result before
> diving into low level code optimisation.
>
> cheers,
> jo
>
>
> On Tue, May 9, 2017 at 8:12 AM, Ingo Liebhardt 
> wrote:
>
> Hi Jo,
>
> OK, here we go, some measurements.
> And I must admit that they are not too encouraging.
> see below...
>
> Am 07.05.2017 um 21:57 schrieb Ingo Liebhardt :
>
> The 30 sec are export time on a full res image.
> For darkroom mode, it's slow but usable. It's not that abysmal. :-D
> I'll give you the remaining measurements tomorrow.
> I do think that there'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.05.2017 um 20:48 schrieb johannes hanika :
>
> hi,
>
> On Mon, May 8, 2017 at 6:33 AM, Ingo Liebhardt 
> wrote:
> Hi & thx :-)
>
> Well my machine I use for this is super-weak: intel core m3, 4.5W TDP. Very
> energy efficient :-( Takes around 30 sec with this machine.
> It uses openmp.
>
>
> okay :) that's export time on a full res image or for darkroom mode?
> how does it change if you switch on the equalizer module, to give me a
> sense how slow your machine is?
>
> Equalizer module alone on this machine takes 14 secs, increasing the overall
> export time to 51 secs, full res image.
>
>
> It has basically 3 building blocks:
> 1. Markesteijn 1 pass for obtaining luma and directionality.
> 2. Some 11x11 correlation filtering, where the filter has complex numbers as
> filter values.
> 3. Median filtering of chroma.
>
> Now, 1 is already pretty optimized.
> 3 is already quite OK.
> I see quite some potential for 2. Some initial experiments I did show that
> using FFTW3 for the filtering could very well be worth it.
>
>
> okay. how much percent is step 2? i mean, how fast would it go if you
> set the time to 0 (just skip the code for a test..)?
>
> Building block 2 still has two parts: first the correlation filters (could
> be switched to convolution) and then some trigonometric functions (basically
> e^(PI*x), which I guess boils down to trigonometric functions).
> Taking out the correlation filters reduces the time from 36 secs to 27 secs.
> Nearly 10 secs off, which is not 

Re: [darktable-dev] Tagging module: What the...

[Tobias Ellinghaus]

Am Samstag, 29. Juli 2017, 22:14:09 CEST schrieb August Schwerdfeger:
> Darktable 1.4.2, 1.6.9, 2.0.7, and 2.2.4, on Fedora, CentOS, and OS X.
> 
> There is something seriously wrong with Darktable's tagging module.
> 
> As I have used successive versions of Darktable with databases containing
> an increasing number of tags, the tagging module has gradually become so
> slow in its operation as to be essentially unusable.
> 
> For example, recently, on a database containing ~2500 tags, I attempted to
> attach a single tag to ~250 images. This operation took approximately three
> minutes, during which time Darktable was unresponsive and consistently used
> about 100% of two cores.

That sounds bad. How did you tag the images? By selecting the tag in the 
tagging module and clicking the "attach" button, or using the quick tag 
feature (ctrl-t, type, enter)? Could you please try the latter if you didn't 
do so before and tell me if that's faster?

> By way of comparison, I accessed a copy of the database file directly and
> used an INSERT INTO command to apply the same tag to the same images. This
> took about 20ms.
> 
> Since actually attaching the tag is clearly not taking six minutes of
> processor time, what else is the tagging module doing that could possibly
> be causing these delays (and, what is more to the point, how do I work
> around it so I can actually use the thing again)?
> 
> --
> August Schwerdfeger
> aug...@schwerdfeger.name

Tobias

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