Re: [darktable-dev] Re: enable DMARC to avoid messages being classified as spam

[Jørn Villesen Christensen]

Hi there,

Looking at the header of the mail I receive from this list, I *think* 
there is something that could be done to help gmail.


The header states:

Authentication-Results: mx3.***.dk;
  dkim=none;
  dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" 
header.from=web.de (policy=quarantine);
  spf=pass (mx3.***.dk: domain 
ofSRS0=nkjO=LI=lists.darktable.org=darktable-...@ml.darktable.org  designates 
195.201.91.78 as permitted 
sender)smtp.mailfrom=SRS0=nkjO=LI=lists.darktable.org=darktable-...@ml.darktable.org

So while it seems that there is a valid spf record, somehow it is also 
marked not aligned.


I asked for help from GPT, and got this answer:

Ensure SPF Alignment: Make sure that the domain in the Return-Path 
aligns with the domain in the From header.


I am unsure if that is a good answer... I mean... I thought the idea 
with From and Return-Path could be different. The From is the address of 
the sender, while Return-Path should be the mailing list.


I don't know... just putting this out there so that someone smarter than 
me sees it and can make sense of it :)


BR
Jørn





On 03/04/2024 09.50, Jan Ingwer Baer wrote:

The problem is more on the side of GMail, then on the side of the
darktable list-server.

A dmarc entry check against the 'From:' field in the message header,
which is the e-mail address of the original sender (In your case:
gmail.com). GMail has to extend the spam detection for correct
processing of mailing lists. Every change that could be done on the side
of darktable would violate standards for e-mails, which is never a good
idea.

Have a look the the wikipedia entry for DMARC:

https://en.wikipedia.org/wiki/DMARC




On 02-Apr-24 22:43, Germano Massullo wrote:

Hello, can you please take action? GMail is everyday marking messages
from darktable mailing lists as spam
Thank you
___ 


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




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

Re: [darktable-dev] Lighttable: Preload / pre-caching of full previews

[Jørn Villesen Christensen]

Hi,

On 03/01/2022 19.53, Pascal Obry wrote:

Le lundi 03 janvier 2022 à 19:40 +0100, Jørn Villesen Christensen a
écrit :

Hi,

I did not know that tool, no, but then again... judging from the
documentation, it only generates thumbnails. My feature requests
concerns full previews.

Full preview is only one kind of thumbnails, just a larger one.

No magic :)


Sorry for the late reply, but I did not have time to try it out before 
tonight.


Thank you for the hint. It seems obvious in hind sight :-o

It works (if I set size to 8) though it is a bit less fluent in the 
workflow than automagic preview generation. You have to close darktable 
and wait for all images to be processed instead of only a certain 
selection. Oh well... works for now.


~Jørn


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

Re: [darktable-dev] Lighttable: Preload / pre-caching of full previews

[Jørn Villesen Christensen]

Hi,

I did not know that tool, no, but then again... judging from the 
documentation, it only generates thumbnails. My feature requests 
concerns full previews.


Thank you anyway :-)

~Jørn


On 03/01/2022 18.43, thokster wrote:

Do you know:

https://darktable-org.github.io/dtdocs/en/special-topics/program-invocation/darktable-generate-cache/ 





Am 03.01.22 um 18:30 schrieb Jørn Villesen Christensen:

Hi there,

First off: Thank you for a great application. I enjoy using darktable 
very much, and I feel that (with the latest 3.8) it got both better 
and faster on my machine. Thank you! :-)


I have a feature request, though. If it is already implemented, then 
maybe I need a pointer to a place in the documentation :-D But, the 
request is: The ability (within lighttable mode) to enable preload / 
pre-caching of full previews.


To put some more words on my work situation: When I am culling images 
in lighttable mode, I go to full preview mode (shortcut 'w' or 'f') 
and flick through the images. Whenever darktable encounters a "new" 
image, it takes a second to render a full screen preview (or more if 
I have already done some edits). It then caches it so the next time 
(within same session) I show that image, it is shown immediately. 
This delay, however, is a bit annoying when I flick through the 
images for comparison. I therefor often find myself scrolling fast 10 
to 20 images ahead, triggering a preview-generation, for then to go 
back to "start" and actually viewing the images.


I would love it, if i did not have to do the little scroll back and 
forth dance, but that darktable would just start generating previews 
whenever I went into full preview mode.


I know there are some open questions (How many previews to generate? 
What happens if the cached images hits the cache limit? What then 
when you zoom in on a photo?) which I would be happy to discuss, but 
first step would be to check in whether a) I am the only one with 
this request? b) Is this already implemented (and I just haven't 
found the feature)?


BR
Jørn


___ 


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




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

[darktable-dev] Lighttable: Preload / pre-caching of full previews

[Jørn Villesen Christensen]

Hi there,

First off: Thank you for a great application. I enjoy using darktable 
very much, and I feel that (with the latest 3.8) it got both better and 
faster on my machine. Thank you! :-)


I have a feature request, though. If it is already implemented, then 
maybe I need a pointer to a place in the documentation :-D But, the 
request is: The ability (within lighttable mode) to enable preload / 
pre-caching of full previews.


To put some more words on my work situation: When I am culling images in 
lighttable mode, I go to full preview mode (shortcut 'w' or 'f') and 
flick through the images. Whenever darktable encounters a "new" image, 
it takes a second to render a full screen preview (or more if I have 
already done some edits). It then caches it so the next time (within 
same session) I show that image, it is shown immediately. This delay, 
however, is a bit annoying when I flick through the images for 
comparison. I therefor often find myself scrolling fast 10 to 20 images 
ahead, triggering a preview-generation, for then to go back to "start" 
and actually viewing the images.


I would love it, if i did not have to do the little scroll back and 
forth dance, but that darktable would just start generating previews 
whenever I went into full preview mode.


I know there are some open questions (How many previews to generate? 
What happens if the cached images hits the cache limit? What then when 
you zoom in on a photo?) which I would be happy to discuss, but first 
step would be to check in whether a) I am the only one with this 
request? b) Is this already implemented (and I just haven't found the 
feature)?


BR
Jørn


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

Re: [darktable-dev] Change of behviaour reg. (implicit) discard of history – intentional?

[Jørn Villesen Christensen]

On 13/01/2020 12:28, Patrick Shanahan wrote:

* Jørn Villesen Christensen  [01-13-20 05:14]:

Hi there,

I have been using Darktable 3.0 for a while – and thank you for your great
work. Darktable has some nice new features that I really enjoy.

However, there is one feature that I find a bit annoying, it has to do with
(implicit) discard of history.

Example:

1. I have a photo with say 20 edits in the history.
2. The last thing I have done was to play with a module, lets say Tone
Curve, but decided against it. I therefore click on entry 19 in the
history, and I get the photo before me playing around.
3. I leave the photo for a while and then come back to it. (Actually
not necessary for anything else than demonstrating my poor memory :-D ).
4. When I come back to it, I decide to add a bit of noise filtering (a
step I often add in the end because it is heavy on the processing).
When I enable the de-noise filter, the whole image change lighting –
and it takes me a second or two to realise that it is because the
entry no. 20 (the reverted Tone curve edit) has not been discarded,
but instead the history has been fast-forwarded and the de-noise has
been added as entry 21.

In this scenario, I am used to edit no. 20 being discarded, and the de-noise
filter just applied on the image "as is".

*Unless* you "compress" the history stack, the focus location on the stack
is only pertinent if you make a new edit, then that "net edit" will
replace everything above your location on the stack.


Hm... now I cannot reproduce the thing either. It did happen to me a 
couple of times the last couple of days (and this morning) but it looks 
like I should have taken my time to make a "proof of concept" of it 
before mailing here.


Sorry for the noise and thank you for your replies. I will take up the 
issue again if I can nail it better.


~Jørn

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

[darktable-dev] Change of behviaour reg. (implicit) discard of history – intentional?

[Jørn Villesen Christensen]

Hi there,

I have been using Darktable 3.0 for a while – and thank you for your 
great work. Darktable has some nice new features that I really enjoy.


However, there is one feature that I find a bit annoying, it has to do 
with (implicit) discard of history.


Example:

1. I have a photo with say 20 edits in the history.
2. The last thing I have done was to play with a module, lets say Tone
   Curve, but decided against it. I therefore click on entry 19 in the
   history, and I get the photo before me playing around.
3. I leave the photo for a while and then come back to it. (Actually
   not necessary for anything else than demonstrating my poor memory :-D ).
4. When I come back to it, I decide to add a bit of noise filtering (a
   step I often add in the end because it is heavy on the processing).
   When I enable the de-noise filter, the whole image change lighting –
   and it takes me a second or two to realise that it is because the
   entry no. 20 (the reverted Tone curve edit) has not been discarded,
   but instead the history has been fast-forwarded and the de-noise has
   been added as entry 21.

In this scenario, I am used to edit no. 20 being discarded, and the 
de-noise filter just applied on the image "as is".


I see there has been some changes in the history section (in the visual 
appearance, at least), the questions are:


 * Is this intentional?
 * If no, can we revert to the original behaviour?
 * If yes, can we have an option to revert it? (Sorry).

Thank you, once again, for your amazing work.

BR
Jørn



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

Re: [darktable-dev] Filmic (RGB or not) explained

[Jørn Villesen Christensen]

Sorry...  I of course meant the Tone Equalizer.

~Jørn

On 09/12/2019 11:07, Jørn Villesen Christensen wrote:

Thank you, Aurélien, for this video. I enjoyed it.

You mention a video on the Tone module; I have not been able to find 
that. Is it out yet?


~Jørn


On 01/12/2019 01:08, Aurélien Pierre wrote:


Hi,

This is my video on filmic RGB, explaining how it works and how to do 
it in real-life cases: 
https://www.youtube.com/watch?v=zbPj_TqTF88=youtu.be I hope 
it resolves most of the misunderstandings and trial-errors sessions 
that always end-up in frustration.


A shorter addendum is on the way to explain specifically to users of 
darktable 2.6 what changed between the 2.6 and 3.0.


Cheers,

Aurélien.


___ 
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




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

Re: [darktable-dev] Filmic (RGB or not) explained

[Jørn Villesen Christensen]

Thank you, Aurélien, for this video. I enjoyed it.

You mention a video on the Tone module; I have not been able to find 
that. Is it out yet?


~Jørn


On 01/12/2019 01:08, Aurélien Pierre wrote:


Hi,

This is my video on filmic RGB, explaining how it works and how to do 
it in real-life cases: 
https://www.youtube.com/watch?v=zbPj_TqTF88=youtu.be I hope it 
resolves most of the misunderstandings and trial-errors sessions that 
always end-up in frustration.


A shorter addendum is on the way to explain specifically to users of 
darktable 2.6 what changed between the 2.6 and 3.0.


Cheers,

Aurélien.


___ 
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] Automatically select the most focused photo in a burst of photos

[Jørn Villesen Christensen]

I would love to have that feature. I find the current focus preview 
functionality useless.


Br
Jørn

On 06/10/2019 18:36, Aurélien Pierre wrote:


Ok, let's go for a "sharpness score" + focus peaking feature. That 
way, users will have a way to check which area is in focus, and 
compare images between them with a score.


It won't made it to next release, but maybe first minor update.

Le 06/10/2019 à 17:05, Robert Krawitz a écrit :

On Sun, 6 Oct 2019 16:40:37 +0200, =?UTF-8?Q?Aur=c3=a9lien_Pierre?= wrote:

argh. Tales of over-engineering…

I don't really disagree with you, just want to point out that getting
it anywhere near correct (i. e. without a huge number of false
positives and false negatives) is a difficult problem.


Just overlay the euclidean norm of the 2D laplacian on top of the
pictures (some cameras call that focus-peaking), and let the
photographer eyeball them. That will do for subjects at large aperture,
when the subject is supposed to pop out of the background. For small
apertures, the L2 norm will do a fair job. And it's a Saturday afternoon
job, hence a very realistic project given our current resources.

That's fair, I just think that this kind of algorithm will likely
select a lot of photos that are badly out of focus (because the focus
locked on a much more expansive background) and miss ones where it's
the relatively small subject that's in focus.


What you ask for is AI, it's a big project for a specialist, and it's
almost sure we will never make it work reliably. The drawback of AIs,
even when they work, is they fail inconsistently and need to be
double-checked anyway.

So, better give users meaningful scopes and let them take their
responsibility, rather than rely on witchcraft that works only in
Nvidia's papers on carefully curated samples.

Or maybe just implement focus peaking, as you say, but with a UI
similar to the camera's UI (flashing regions that are in best focus).
Then it's up to the user to select the best photos based on their
knowledge of the desired subject.


Le 06/10/2019 à 16:18, Robert Krawitz a écrit :

On Sun, 6 Oct 2019 15:02:39 +0200, =?UTF-8?Q?Aur=c3=a9lien_Pierre?= wrote:

That can be easily done by computing the L2 norm of the laplacian of the
pictures, or the L2 norm of the first level of wavelets decomposition
(which is used in the focus preview), and taking the maximum.

As usual, it will be more work to wire the UI to the functionality than
writing the core image processing.

Consider the case where the AF locks onto the background.  This will
likely result in a very large fraction of the image being in focus,
but this will be exactly the wrong photo to select.

Perhaps center-weighting, luminosity-weighting (if an assumption is
made that the desired subject is usually brighter than the background,
but not extremely light), skin tone recognition (with all of the
attendant problems of what constitutes "skin tone"), and face
recognition would have to feed into it.


___ 
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

[darktable-dev] LUT-exports

[Jørn Villesen Christensen]

Hi,

I have been doing a little of video editing the last week and I wanted 
to do some colour adjustment on the footage. Basically my cameras did 
not output the same colours, so to say, to I went the laborious way of

  a) exporting all frames to jpegs
  b) select a handful of frames of each video clip
  c) adjust the colours to my liking
  d) use darktable-cli to apply the same changes to all files
  e) combine the frames into videos I could then edit.

If anyone wonders... it was quite a bit of a hassle and took lots of 
time (and computing time).


Looking around in my video editing software (I currently use Shotcut) I 
see there is a LookUp Table filter. In other words; a generic 
color-to-color filter and it made me think...


 => Can Darktable export LUTs? Has anyone done that?

If so, this could really have sped up my time... snap a few frames, edit 
them in Darktable, export LUTS, import to Shotcut, done.


One could also think (for a different scenario) a module that would 
import LUTs and apply them first in the pipeline, if somebody needed to 
adjust LUTs that they did not first created themselves (with Darktable).


BR
Jørn


Ps.: My initial thought was to expand Darktable with video capabilities 
- but that, I guess, is a bigger challenge :-D



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

Re: [darktable-dev] Darkroom UI refactoring

[Jørn Villesen Christensen]

Hi,


An alternative suggestion (as I have also found the module list a bit... 
difficult to work with sometimes :-D ). I have often wished for a search 
box, so here is an idea; not thought through, but meant as inspiration:


How about one big list of modules, but with collapsible sections (and 
thus not have the top buttons for bases, tones, colours, etc.).


At the top of the list, there would be a search bar that would let you 
easily filter on

  - name of module
  - tags associated (from the developers) with the module, such as 
bases, colours, enhancements...


In the list, there would be two active foldable sections:
  - Enabled modules.
  - All modules.

You can right click on the list to
  - Create a new (nameable) section.
  - Order the sections (maybe All Modules should stay at the bottom, 
Enabled module should stay at top).

  - Add / Remove modules to/from the custom sections.
  - Add a colour marker to the custom sections. When the modules are 
displayed in the Enabled Modules list, they would be colour coded with 
that colour, or have a colour marker (dot).


Perhaps the order of the modules (in the All Modules and Enabled Modules 
sections) could be selectable to

  - Sorted alphabetically
  - Sorted according to path in the pipeline.


In addition to that, I do not quite like way that modules unfolds under 
it's name in the list. I think I would prefer a list of modules (as I 
described above :) ) and clicking on each module, would open it up in a 
separate Module Settings area.


Reason: Sometimes when modules have (parametric and drawn) masks they 
become tall and thus, when open, requires me to scroll excessively (?) 
when going up/down the list, searching for something. When clicking on 
another module (thus triggering closing and opening of modules) the 
change in horizontal position of the list have sometimes also annoyed 
me. Having the list and the module settings separate, keeps the list 
more steady, compact, and thus I believe I can maintain a better overview.


BR
Jørn




On 08/10/18 06:59, Dominik Markiewicz wrote:

Hi,
I've also my workflow, but it's a bit different then yours (crop is one 
of basic corrections for me, I almost never do noise removal as a one of 
first steps). I'm not a big fan of arbitrary change here. Agree with 
Jochen that custom tabs could be quite nice.


To achieve something similar I just enable modules, add them as 
`favorite` and save this as a preset. Then add shortcuts for each of 
presets and I can easily switch between my groups of modules.


Regards,
Dominik

pon., 8 paź 2018 o 06:42 Jochen Keil > napisał(a):


Hi,

On Mon, Oct 8, 2018 at 5:39 AM Aurélien Pierre
mailto:rese...@aurelienpierre.com>> wrote:
 >
 > The real question here is : could you get past the change and
benefit from it ?
 >
 > I'm biased here, since I developed repetitive strain injury in
the wrist at the early age of 23. So I'm basically trying to improve
the efficiency of the workflow by decreasing as much as possible the
number of user interactions on each picture, especially the mouse
interactions.
 >
 > If it's only for cropping, it can be fixed. At the end, I think
it really depends on how many hours you spend each week on
darktable. Because editing a whole wedding is definitely not the
same as editing a bunch of holidays pictures, so I guess every user
will have a different sensibility to workflow matters and the
occasionnal users will mostly care about the overhead of the
refactoring (having to learn things again) while the regular users
will see it as a long-term investment.

So, how about custom tabs, that can be named freely and where users
can add and arrange modules to their liking?

The existing arrangement could be shipped as a preset, and other
presets could be added easily.

Make it configurable instead of trying to figure out what's right for
everyone (hint: won't happen)

Cheers,

   Jochen


 > Le 07/10/2018 à 23:02, Jason Polak a écrit :
 >
 > Hi!
 >
 > I can certainly see the logic of your idea. I definitely prefer the
 > current setup, if only because that's what I started with. I
think the
 > only way to see if this is a good idea is to poll users because I am
 > sure there are some that would like your way and some that prefer the
 > current way.
 >
 > I do have a specific criticism about your approach, though. I think
 > cropping should come early in the editing process. I care much more
 > about adjusting the general exposure and crop (composition) before I
 > could even think about lens correction or noise reduction. This is
 > doubly so because I take a multi-pass view on editing. I first do
some
 > basic edits of exposure, cropping, and tone curve adjustments to the
 > shots I think are half-decent, and then promote the 

Re: [darktable-dev] GCC 7

[Jørn Villesen Christensen]

Hi again,

Apparently, no, that is not enough. rm -r build/ did the job, and this link:

https://stackoverflow.com/questions/673407/how-do-i-clear-my-local-working-directory-in-git

suggests git clean -d -x -f.

Anyway... it compiles now. Sorry for the noise.

~Jørn


On 2018-01-27 21:31, Jørn Villesen Christensen wrote:

Yes, I think so. git clean -f should do that, right?

~Jørn


On 2018-01-27 21:21, Roman Lebedev wrote:

You have already tried removing the build dir?

On Sat, Jan 27, 2018 at 5:14 PM, Jørn Villesen Christensen
<darktable-...@mettle.dk> wrote:

Ok. Thank you for your replies. I'll have another look later.

One reason why I thought it might have been due to gcc 7 was these 
two posts

(among others):

https://github.com/svaarala/duktape/issues/1602

https://github.com/collectd/collectd/issues/2423

But thank you once again :)

~Jørn



On 2018-01-27 16:04, Jean-Luc Coulon (f5ibh) wrote:


Hi
2018-01-27 9:57 GMT+01:00 Tobias Ellinghaus <m...@houz.org
<mailto:m...@houz.org>>:

 Am Samstag, 27. Januar 2018, 06:38:57 CET schrieb Jørn Villesen
 Christensen:
 > Hi there,
 >
 > It seems (to me) that darktable does not support gcc 7. Is 
there any
 > effort at the moment to support this? Or if not, what is the 
latest

 > gcc-version that is supported?

 gcc 7 should be supported, several of us are building with it all
 the time.

I use gcc 7 and I dont experience any problem related to it.
And I build git version daily (or mostly)

 [ ... ]
 > got gcc v7.2 along with it.

 I am using 7.3 at the moment, but I am fairly certain that I used
 7.2 before.


I have used 7.2 and I use 7.3 from debian


  > BR
  > Jørn

 Tobias

Jean-Luc



___ 


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




___
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] GCC 7

[Jørn Villesen Christensen]

Ok. Thank you for your replies. I'll have another look later.

One reason why I thought it might have been due to gcc 7 was these two 
posts (among others):


https://github.com/svaarala/duktape/issues/1602

https://github.com/collectd/collectd/issues/2423

But thank you once again :)

~Jørn



On 2018-01-27 16:04, Jean-Luc Coulon (f5ibh) wrote:

Hi
2018-01-27 9:57 GMT+01:00 Tobias Ellinghaus <m...@houz.org 
<mailto:m...@houz.org>>:


Am Samstag, 27. Januar 2018, 06:38:57 CET schrieb Jørn Villesen
    Christensen:
> Hi there,
>
> It seems (to me) that darktable does not support gcc 7. Is there any
> effort at the moment to support this? Or if not, what is the latest
> gcc-version that is supported?

gcc 7 should be supported, several of us are building with it all
the time.

I use gcc 7 and I dont experience any problem related to it.
And I build git version daily (or mostly)

[ ... ] 


> got gcc v7.2 along with it.

I am using 7.3 at the moment, but I am fairly certain that I used
7.2 before.


I have used 7.2 and I use 7.3 from debian


 > BR
 > Jørn

Tobias

Jean-Luc


___ 
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

[darktable-dev] GCC 7

[Jørn Villesen Christensen]

Hi there,

It seems (to me) that darktable does not support gcc 7. Is there any 
effort at the moment to support this? Or if not, what is the latest 
gcc-version that is supported?


Observations behind this question:

I just did a git pull on the master branch and tried to compile it. I 
got the following error (and others similar):


/home/jvc/Dev/darktable/src/common/mipmap_cache.c: In function 
‘dt_mipmap_cache_unlink_ondisk_thumbnail.part.3’:
/home/jvc/Dev/darktable/src/common/mipmap_cache.c:426:42: error: ‘.d/’ 
directive output may be truncated writing 3 bytes into a region of size 
between 1 and 4096 [-Werror=format-truncation=]
 snprintf(filename, sizeof(filename), "%s.d/%d/%d.jpg", 
cache->cachedir, mip, imgid);

  ^~~~
/home/jvc/Dev/darktable/src/common/mipmap_cache.c:426:42: note: using 
the range [-2147483648, 2147483647] for directive argument

In file included from /usr/include/stdio.h:862:0,
 from /home/jvc/Dev/darktable/src/common/dtpthread.h:28,
 from /home/jvc/Dev/darktable/src/common/cache.h:21,
 from /home/jvc/Dev/darktable/src/common/mipmap_cache.h:21,
 from /home/jvc/Dev/darktable/src/common/mipmap_cache.c:19:


After a bit googling, I realised it was because I upgraded my Ubuntu and 
got gcc v7.2 along with it.


BR
Jørn

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

Re: [darktable-dev] Debugging of darktable.

[Jørn Villesen Christensen]

Hi Roman,

Thank you for your quick answer :-)

On 2017-12-04 22:34, Roman Lebedev wrote:

On Tue, Dec 5, 2017 at 12:28 AM, Jørn Villesen Christensen
<darktable-...@mettle.dk> wrote:

I have been trying to debug darktable (with gdb) but without any luck.

It's not designed to be runnable without installation.


Ok. Is there then something I am missing or doing wrong since gdb cannot 
debug into other files than main.c? Is there a special trick?


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

[darktable-dev] Debugging of darktable.

[Jørn Villesen Christensen]

Hi there,

I have been trying to debug darktable (with gdb) but without any luck.

My main problem of running darktable from the build directory is that it 
will not load any modules. I have tried to play with --datadir, 
--moduledir, and symlinks, but without any luck. I can get the UI up 'n' 
running - but no modules are loaded.


Alternatively I have tried to install darktable in a temporary directory 
next to the build dir, but that fails as well. It launches well, but 
then gdb fails to debug any other files than main.c and I suspect it is 
due to the changed file structure.


So... is it possible for any of you to sketch up how you debug darktable?

BR
Jørn Christensen
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Module ordering and icons

[Jørn Villesen Christensen]

Hi,

There is a "more module" section at the bottom of the pane that I always 
go to when I cannot find the module I'm looking for. Here, they are in 
alphabetical order.


~Jørn


On 2017-11-30 20:16, Colin Adams wrote:
It used to happen to me at first. But after a little while, I had marked 
as favourites the modules I use, so then it is easy to find them.


On Thu, 30 Nov 2017 at 19:14 Daniele De Felice 
> 
wrote:


Maybe it's just me that I have trouble finding the module I am
looking for.
If this does not happen to any of you... :)


On 30/11/2017 18:27, Timothy Spear wrote:

I am not a developer on dt. However, I think the order makes
perfect sense.
Here is why, if you apply the edits out of the order they are
applied to the image, you end up potentially having to reapply a
specific edit.
I see this issue all the time on LightRoom forums where people are
not applying the edits in the order the software was designed. And
then the user is left trying to figure out the unintended effects.
The one comment I will say is, I wish the user manual was included
somehow on the installation (Windows user). There have been times
where I am not connected to the net and I am playing with dt and
need to figure something out...

Tim


On Thu, Nov 30, 2017 at 12:19 PM, Daniele De Felice
> wrote:

Ok, thank you for your answer.
I get that this makes sense from a developer/poweruser point
of view.
But, from a end-user point of view, as a feedback on my side,
is very difficult to find any particular module since the
order has no meaningful appearance.

For example, let's say that I am looking for the Equalizer
module (by the way, I love this module).

There is no way for me to understand that I will find it
between the "Local contrast" and "Shadows and highlights"
modules :)

(warning: maybe original english name are slightly different)

Would be easier if I could list modules in alphabetical order.
I don't mean that this should reflect on actual application of
the modules, just in the way that modules are displayed.

This being said, thank you anyway for the great software and
for the Linux support.
Daniele

On 30/11/2017 17:38, Maurizio Paglia wrote:

Ciao Daniele,
modules are listed in the same order the software uses to
apply them.
You can find this explanation in the user manual.

A feature allowing users to re-arrange module list in order
to be more comfortable with everyone own forkflow has been
requested (I did that too) but developers seem to be not
convinced.

Maurizio

2017-11-30 17:30 GMT+01:00 Daniele De Felice
>:

Hi guys,

sorry for writing here but I cannot find any official
forum or equivalent.

I *love* the software but cannot find a way to better
arrange the modules.

The modules on the right panels are in no particular order:

The icons are very similar, the order is *not*
alphabetical and I cannot re-arrange them.

Is there a way to solve any one of these issues?

Maybe any of the following would work:

- make icons (much) bigger, maybe 2x or 2.5x

- re-arrange modules order in cusrom oder

- put them in alphabetical order

- having a search box at the top

Thank you :)

Daniele








___
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






___
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


___
darktable 

Re: [darktable-dev] Fixing the scroll-bar issue

[Jørn Villesen Christensen]

Hi there,

On 2017-10-12 09:50, Tobias Ellinghaus wrote:

Am Mittwoch, 11. Oktober 2017, 20:04:34 CEST schrieb Rolf Meyerhoff:

DT has actually two scrollbars for the lighttable. One is located at the
outer most right edge and one at the outer most left edge of the main
window.

However, they are not accessible with a mouse because they're overlaid
by the 'side panel open/close click areas' (or whatever they're called).
The side panels have their own scrollbars.


Precisely.


No, they are not "accessible" because they are not scroll bars in the first
place. We just draw some grey rectangles of various shades as an indicators.


Well, they are. At least the one associated with the modules pane. I can 
click and scroll on that one.



It always annoyed me that I could see the scrollbars but I couldn't use
them. It would be great of someone could fix that.


That would be less of a fix than a new feature added. One that I were not
opposed to. But it's definitely more involved than just moving the widget to
another place and wiring up a signal.


I think I will see if I can find time to look at this issue - whether 
the outer one is a scrollbar or not. If the latter, I can perhaps copy 
stuff from the modules pane.


(Looking closely now, I do see a small difference at the top and bottom 
of the two "scrollbars". The modules one have rounded corners, while the 
light table one do not.)


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

[darktable-dev] Fixing the scroll-bar issue

[Jørn Villesen Christensen]

Hi there,

I have been using Darktable from time to time and think I will be using 
it more in the future. I have a few ideas of what modules I would like 
to see in Darktable and I thought I might throw in a few hours myself.


Short about me: I have been working 7 years now as a software developer 
and architect in a Windows oriented environment. Mostly I have been 
working with Delphi, C#, and C++. In my private life I have been running 
Linux for ~15 years and done some C++ programming - but without GUI.


In order to get started and to do something useful, I thought I would 
look at a bug that I also find annoying. It is described in these two 
bug reports:

  https://redmine.darktable.org/issues/10947
  https://redmine.darktable.org/issues/10711

My idea was basically to move the scrollbar from the outer position 
(where it is currently) to just next to the film roll. See attached photo.


Questions:
 a) Are there already other people working on solving these bugs?
 b) Does my proposed solution seem like a good idea?
 c) Would you have any pointers to me on how to get started (which 
files I should look into or other tips on how *you* would go about 
solving this).


BR
Jørn Christensen


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

Re: [darktable-dev] Deconvolution and Python framework

[Jørn Villesen Christensen]

On 2017-10-11 15:35, Pete Hall wrote:
Just an opinion from a devoted user... It might be a very useful tool 
for me. I shoot a lot of sporting events. It's common for me to find a 
great shot ruined because at the critical moment, the camera focused on 
the wrong player, or on the goal keeper's net. Even if it can't be made 
efficient for the normal workflow, it could still be a very useful tool, 
at least for me.


Same for me - I think that would be an awesome feature, although I am 
kind of sceptical that it will be the magical bullet for you, Pete ;-)


But nonetheless, I hope that it will be possible to fit this 
functionality into the workflow of Darktable - although I do see the 
challenges with the time requirements.


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