Re: [darktable-user] Re: OpenCL: 1050ti or RX560?

[Remco Viëtor]

On vendredi 1 septembre 2017 00:25:48 CEST Brune Wayce wrote:
> So, please let me if I'm correct, particolare when therm is "(???)":
> 
> AMD PROPRIETARY DRIVERS
> 1. Official from amd, but only for the newest cards, only for kernel 4.8
> and 4.10, only for "stable versions" of redhat, centos and ubuntu
> 2. Manually unpacking the driver you can install to almost any distribution
> rpm or deb based, provided that the kernel is 4.8 or 4.10 and the card is
> supported by the driver
> 3. Some new cards (rx550) are supported only by kernel 4.11
> 
> AMD OPEN DRIVERS
> 1. Valid for almost every card
> 2. Available for every distro (also debian testing) (???) and every kernel
> (???)
> 3. Accettable performance
> 
> NVIDIA PROPRIETARY DRIVERS
> 1. Valid for almost every card
> 2. Available for every distro (also debian testing) (???) and every kernel
> (???)
> 3. Good performance
> 
> NVIDIA OPEN DRIVERS
> 1. Valid for almost every card
> 2. Available for every distro (also debian testing) (???) and every kernel
> (???)
> 3. Accettable performance
> 
> Thank you all,
> BW
> 
> 
> darktable user mailing list
> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
>From earlier discussions it became very clear that for both NVidia and AMD you 
need to download the proprietary drivers for OpenCL (and CUDA for NVidia, but 
that's not relevant for darktable).
In the case of AMD, even if you can start with the open drivers, you still 
need to use parts of the proprietary driver package.
For NVidia, you'll just have to install the proprietary drivers (easy enough 
in OpenSUSe, don'tk now about other distributions).

With *only* the open drivers, you will not be able to use openCL. 

Wrt. to the card you selected from NVidia: the 1050 is the entry-level card in 
the latest series. If you cannot stretch to the 1060, you might be better off 
just staying with your current system: to use the GPU, the data has to be 
prepared on the CPU and transferred to and from the GPU.
This is an extra cost to using openCL which has to be more than compensated 
for by the GPU. So even if a lower level graphics card would in theory do the 
/calculations/ faster, those extra costs make that total treatment time 
doesn't improve.

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] opencl .. a fresh install

[Remco Viëtor]

On lundi 7 août 2017 08:40:01 CEST David Vincent-Jones wrote:
> Yes, I have a nvidia card. (Quadro K1000M)
> 
> I installed and ran clinfo but the dt core options still shows opencl
> not available.
> 
> searched for nvidia-modprobe and it is not found.
> 
> I used the fairly simple opensuse install procedure (which worked well
> on the previous release) and to make sure I ran the process again
> including a reboot.
> 
> Any idea where I should go from here?
> 
> David
> 
> On 08/06/2017 09:47 PM, Ulrich Pegelow wrote:
> > Am 07.08.2017 um 04:03 schrieb David Vincent-Jones:
> >> I have just moved my openSUSE version from 42.2 to 42.3 and now dt does
> >> not appear to recognize the installed openCL.
> >> 
> >> [opencl_init] could not find opencl runtime library 'libOpenCL'
> >> [opencl_init] could not find opencl runtime library 'libOpenCL.so'
> >> [opencl_init] found opencl runtime library 'libOpenCL.so.1'
> >> [opencl_init] opencl library 'libOpenCL.so.1' found on your system and
> >> loaded
> > 
> > This tells us that at libOpenCL.so.1 is present on your system and
> > darktable has been able to load it.
> > 
> >> [opencl_init] could not get platforms: -1001
> > 
> > That tells us that libOpenCL.so.1 failed when checking for available GPUs.
> > 
> > I assume you have some NVIDIA card.
> > 
> > Please try the following. As root call program clinfo (should be
> > supplied by package clinfo-2.0.15.03.24-2.3.x86_64 or the like). Then
> > start darktable again as a normal user. If darktable now works with
> > OpenCl this is an indication of a permission issue on your system.
> > 
> > NVIDIA relies on a program /usr/bin/nvidia-modprobe that needs to be set
> > SUID root. I found that frequently distributions remove the SUID bit for
> > security reasons. It's up to you if you set it manually (chmod +s
> > /usr/bin/nvidia-modprobe).
> > 
Also, you need the closed-source drivers from NVidia, and those are not 
available throught the standard repositories. Even if you added the NVidia 
repositories, they get disabled on update to a new version. That means you'll 
have to add those repos again (for the new OS version)...

As the default nouveau driver works for the system, this only becomes evident 
when you use a program that requires the closed-source drivers (CUDA, or 
OpenCL typically need the closed-source drivers, as well as programs that use 
more advanced openGL functions, or insist on hardware support for openGL)

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] collect images attending to exposure time

[Remco Viëtor]

On vendredi 4 août 2017 14:31:12 CEST Marcial wrote:
> Hi all,
> 
> I use quite a lot the rules to exclude or include the collected images.
> I can choose among a lot of criteria, but I miss the option of doing it
> attending to the exposure time. Is it possible and I am missing it, or
> it's just not feasible? If that's the case, I would like to suggest that
> it could be implemented, as it would be very useful.

While such an option might be very useful to *you*, I've literally never felt 
the need to filter on exposure time (look up the exposure time for a given 
image, yes, selecting images based on exposure time, no).

So for now, I 'd be a bit careful in saying that it would be an option that's 
"very useful" for a significant number of users (of course, if a developer 
feels it's a useful option, '1' becomes a significant number of users).



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Leica D-Lux typ 109, lens correction

[Remco Viëtor]

On vendredi 28 juillet 2017 15:33:48 CEST Frank J. wrote:
> Am 28.07.2017 um 13:50 schrieb GianLuca Sarto:
> > Hello All,
> > 
> > this small camera needs a strong lens correction: while out-of-camera
> > JPGs are fairly correct, the RAW files are appalling.
> > 
> > The Lens Correction menu says "lens not found".
> > 
> > Is there a way to trick DT to use Panasonic's LX100 lens correction, if
> > available, since it should be in many ways a clone?
> > 
> > thanks for your attention,
> > 
> > -Gian
> 
> Hi,
>  try to edit the lensfun-data in "/usr/share/lensfun".
> 
(...)
> 
> Your changes will be erased with the next update of lensfun. 
Which is exactly why I suggested copying that file to ~/.local/share/lensfun:
then it will NOT be overwritten in case of an update...
Also, editing the file in /usr/share/lensfun has unpleasant effects when you 
make a mistake in editing, xml can be very finicky about syntax.


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Leica D-Lux typ 109, lens correction

[Remco Viëtor]

On vendredi 28 juillet 2017 13:50:36 CEST GianLuca Sarto wrote:
> Hello All,
> 
> this small camera needs a strong lens correction: while out-of-camera
> JPGs are fairly correct, the RAW files are appalling.
> 
> The Lens Correction menu says "lens not found".
> 
> Is there a way to trick DT to use Panasonic's LX100 lens correction, if
> available, since it should be in many ways a clone?

What you could try:
- copy /usr/share/lensfun/v1/compact-panasonic.xml to 
~/.local/share/lensfun/v1 (under a new name)
- edit that copy to include the proper camera and change the lens name
"DMC-LX100" to whatever your camera reports.
- save the edits, and (re)start darktable 

or see http://lensfun.sourceforge.net/calibration-tutorial/lens-calibration.html

disclaimer: the above is a summary of what has been reported in this list in 
earlier threads, I never needed to try this. That said, if things go pear-
shaped, delete the copy in ~/.local/share/lensfun/v1 and you should be back 
where you started.

An alternative would be to create your own correction profile using Hugin.
E.g. http://hugin.sourceforge.net/tutorials/calibration/en.shtml describes how 
to do this (take care when collecting the images you need!).

Remco





darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Demosaic module

[Remco Viëtor]

On vendredi 28 juillet 2017 07:04:47 CEST Jason Polak wrote:
> Hi Paul,
> 
> Cameras typically capture photos with individual red, green, and blue
> photosites separately. So before demosaicing, your Raw is just all that
> information before it is combined into a usual picture. Demosaic turns
> this mosaic into a usual picture. So you probably want this on!
> 
> On 2017-07-28 12:27 AM, Paul Deverson wrote:
> > I can’t seem to activate the Demosaic module. With every other module I
> > can turn it on and off by clicking on the on/off switch icon. But not
> > Demosaic.

You want the demosaic module on *only* when working on a *raw* file, and 
darktable enforces this. 

The original post was about not being able to switch it on, so my guess is 
that Paul was *not* working on a raw file (cameras typically have the option to 
produce jpg files, some also provide the raw data).

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Download of daily updated lensfun list?

[Remco Viëtor]

On jeudi 6 juillet 2017 14:16:29 CEST Аl Воgnеr wrote:
> Am Wed, 5 Jul 2017 15:51:27 +0200
(...)
> http://lensfun.sourceforge.net/development/
> The source code is available from a git repository hosted at
(...)
> 
> I assume these git-files are here:
> https://github.com/lensfun/lensfun/tree/master/data/db
> 
> But the files there are not from the last days, but months old.
> 
The last commit to that branch was done 27 days ago. The older files stay there 
as they are still needed as part of the complete database.

> So is this not the development brunch of lensfun?
> 
"Development branch" does not mean "all files change all the time". It only 
means "new code/data can get added here at any time and we don't guarantee 
stability or absence of bugs". Also, typically only a few contributors can 
modify the depository (checking in new files, creating or merging branches). 
And in most open source projects, even those people are volunteers and might 
have other things to do. So a last commit 27 days ago in what is a fairly 
stable library isn't all that surprising.

And typically, as an end used you don't want to pull from a development 
branch, unless you really know what you are doing.

Although in this specific case (pulling a lens or camera xml file from a 
development branch) breaking lensfun isn't all that likely.

> 
> http://lensfun.sourceforge.net/lenslist/
> Before you start to calibrate new lenses or report missing cameras
> please check http://wilson.bronger.org/lensfun_coverage.html for a
> daily updated list covering the status of the current development
> version.

That list can easily be generated every night by an automated script. So the 
list is new, but that doesn't mean that there are new cameras or lenses added 
every day.

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] tagging groups of images

[Remco Viëtor]

On lundi 26 juin 2017 03:48:54 CEST Lars Kotthoff wrote:
> To be clear, what I'd like to have would be an option (or different
> shortcut) to switch between the two behaviours. I totally see that applying
> something to a group of images doesn't always make sense, but in some cases
> it does.
> 
> Maybe this can be implemented by using another modifier? E.g. Ctrl-t tags
> with the old behaviour, Ctrl-Shift-t tags everything in a group.
And click/shift-click for mouse actions then?

Digikam faced the same problem and they implemented it as a series of 
configurations settings: for each group of actions you get three options: whole 
group, top of group only, or ask each time. And there they went from "top of 
group only" to "whole group"; that lasted exactly one version... 

Not saying setting this behaviour as a configuration option is better, just 
another possibility. A combination might be ideal (setting as default, 
shift-... to use opposite for one action), if you can remember the behaviour 
you set.

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] tagging groups of images

[Remco Viëtor]

On dimanche 25 juin 2017 11:53:53 CEST Coding Dave wrote:
> Hi,
> 
> I agree with Lars. Many actions applied to a group make sense to be applied
> to each item of the group. If the elements are in a group they are
> semantically very close and such intended actions on a group would usually
> be ment for each individual item in the group. There are exceptions from
> that rule, of course, like applying a style to a group may have a different
> intention. Whereas changing e.g. the time offset/metadata should work on
> all elements of that group.

While applying a style to all images of a group sounds like it's always the 
wrong thing to do (you don't want to apply the same styles to a developed jpg 
and an undeveloped raw), other cases are a lot less clear.

- Some tags related to image content should probably be applied to all images 
in a group.
- But if you use tags to specify e.g. an intended use (print, screen, ...) you 
probably don't want them applied to all images of the group.
- ratings &color flags: depends on the way you use the different flags.
- anything related to use rights: I can easily see different metadata data for 
different files within a group.
And only you know what your different tags mean, darktable has no way to figure 
that out.

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] TV characterizing (was : Which config for Darktable)

[Remco Viëtor]

On vendredi 23 juin 2017 19:50:29 CEST I. Ivanov wrote:
> I tried to calibrate the TV to some extend (and I still use it this
> way). In a nut shell - I turned of all improvements that the TV offers
> like eye care or dynamic contrast (whatever I was able to find out) -
> these can be turned back on after the calibration if you wish. 
Are you sure about that? I always understood that a profile was only valid for 
the device settings with which it was created. Changing the device settings 
implies generating a new profile...

> I used
> chromecast and with it - spyder 5 and displaycal. With this - in expert
> mode of the TV - I was able to tweak brightness and adjust it as per
> what spyder 5 was detecting. Then I was able to adjust the RGB values
> independently and again - spyder 5 would detect it.
> 
> But this is where all ended. Displaycal would show patches on the screen
> and spyder 5 would measure them but there is no known to me way to load
> the generated profile on the TV.
> 
Iirc, in most cases a monitor profile is used to correct an image before it is 
sent to the monitor (or TV, in this case), so it resides, and is only used, on 
the computer driving the TV.

> If you use the computer to calibrate it - over hdmi cable - it would be
> only valid while the computer is plugged in.
Which follows from the above.
 
> Professional services charge quite a bit but my understanding is that it
> still boils down to measuring on the screen and adjusting manually the
> controls.
Actually, there are 2 phases. 

First, you try and get the device as close as possible to the ideal rendering 
as you can with the (hardware) controls. That is the calibration phase.

Then you measure the response of the monitor against a number of defined 
colours, from these measurements you calculate a correction table or function 
that's to be applied to all images sent to the monitor (profiling phase). With 
most standard hardware (amateur level) this profile is stored and used only on 
the computer driving the screen device. Perhaps this is different on high grade 
(professional) screens?

And I'm not surprised that calibration and profiling done by professional 
service is pricey, it's rather time consuming if done correctly. On the plus 
side, the generated profiles should be valid for quite a while.

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Which config for Darktable

[Remco Viëtor]

On vendredi 23 juin 2017 14:57:05 CEST Guillermo Rozas wrote:
> >> Honest question: what is the sense of doing this? If one is using the
> >> open source drive on "moral grounds", taking the OpenCL blob from it
> >> and using it when convenient doesn't make it any less closed. I
> >> confess that I don't know the status of the proprietary drivers for
> >> AMD, are they fundamentally worse than the open ones?
> > 
> > There are no functional/usable/not-broken  free/open source opencl
> > drivers.
> > At least if you try to use darktable, and not just run some toy
> > benchmarks.
> 
> I get that. What I don't understand is what is the sense of using the
> open source driver AND the OpenCL part of the closed one, instead of
> directly using the closed source driver. Is more of a philosophical
> question :)
> 

I think it is mostly philosophical for the end user (although using the closed 
source driver means you have to do a bit more work).

It's not at all only philosophical for anyone who has to distribute such 
closed source drivers, which come with licenses incompatible with the GPL (by 
definition, as they are closed source...).

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Is it possible to configure "alias lenses"

[Remco Viëtor]

On mercredi 14 juin 2017 11:25:33 CEST Аl Воgnеr wrote:
> Am Wed, 14 Jun 2017 09:16:04 +0200
> 
> schrieb Maurizio Paglia :
> > Same problem at my side... I have a Tamron 17-50 with VC capability
> > that is not included in the lens database on my distribution but
> > correction for Tamron without VC works.
> > In any case I tested Tobias script yesterday evening and it works
> > perfectly.
> 
> I hope there will be a general solution soon without doing tricky
> things.

There is a general solution already: add those lenses to the lensfun database 
as user additions. If I understand the system correctly, that should work as 
long as the lens provides an ID value to the camera.
 
> Until now I do not understand what the script does exactly. I do not
> want to edit the original raw-file. In the xmp-file I didn't find the
> lens.
As normally those fields are in the RAW file already and should not be changed 
(as they are descriptive of the conditions under which the original image was 
taken), there is no reason to add them to the XMP sidecar.

> It shouldn't be a lot of work to do this.
Perhaps not, if you assume that such lenses have the exact same optical 
system. If you want to play it safe (good starting point if you are going to 
distribute the data to 1000s of users) you'll have to verify that for every 
lens you want to add as an alias"...

What I personally would like to see is a system where you can configure which 
lenses you own/use, and darktable then limits the selections offered to those 
lenses (ideally with an option to see the full list, for the cases where you 
hire a lens for just one or a few shoots).

Remco



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Is there a repo for the newest lensfun-database?

[Remco Viëtor]

On lundi 29 mai 2017 23:26:11 CEST Аl Воgnеr wrote:
>...
> In the meantime I know, why 0.3.2 didn't work sometimes, I use
> different cameras and one was the new Pentax KP, which is not supported
> until now. When I assigned a Pentax K3 instead, it worked generally.
> Probably not a good idea. I don't understand why the camera is needed
> to correct distortion.

Correction parameters depend on the crop factor, easiest to just use the 
camera body to store that, and not expect the average user to enter the crop 
factor (most will know what body they use, but probably can't be bothered to 
figure out what a crop factor is, let alone which one applies to their camera).
Also, the camera body used could help limit the number of possible lenses: 
lens IDs are not unique between brands, Canon/Nikon/Tamron/Sigma/... can use a 
given ID value for wildly different lenses. I don't think any program uses that 
info though, and its use is complicated when adapters are used.

But, unless lensfun changed the database format, there is no reason to upgrade 
the lensfun *library* only to get access to data for a new camera/lens. As 
described by Roman, grabbing the latest database files and installing them 
under your home directory should work just fine (again, if the database format 
didn't change). And it's easy to correct if it doesn't work (contrary to a 
library upgrade, which can be a pain to undo)

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Greetings and clarifications about styles usage

[Remco Viëtor]

On lundi 22 mai 2017 20:21:06 CEST Journeyman wrote:
> On 22/05/2017 01:18, Guillermo Rozas wrote:
> > Darktable has a definite order in which modules are
> > applied and by default each module is applied only once. When you
> > apply a style that contains modules that already are in the history
> > stack you're not applying the module twice, you're just replacing the
> > original instance of the module by the new one in the style (possibly
> > with different options).
> 
> I cannot truly confirm this. This is what I tried:
> - create my style including: base curve, orientation, lens correction
> - open a ARW file in Darktable
> - apply my style
> - resulting history stack has duplicates

Did you try clicking on "compress history stack"?
Whenever I had a situation with several apparently duplicate entries, 
one click removed them.

History stack is just that: a history of what you did. Useful if you want to 
go back to an earlier stage of your processing. If you want to see the order 
in which the modules are /applied/ (as opposed to the order in which they were 
activated/selected), look under the tab marked with the 'power' symbol (circle 
with vert. half bar).

And, this stuff is straight from the manual and the FAQ. Rather useful 
resources to understand the program and remove a lot of guesswork...

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] style

[Remco Viëtor]

On lundi 22 mai 2017 16:02:59 CEST Michael wrote:
> in darktable to apply the same settings to a group of images you need to
> create a style and the apply that style to the desired images?

No, you can, in light table view, copy a history stack (or part of one) from 
one image to others: select the source image, click "copy" in the right bar 
section "history stack) (or "copy all" for the whole stack), then select 
target images and click "paste" (or "paste all").

> I think the way it works is that you save a style and then the settings of
> that style are transferred to the original image when you apply that
> setting. So if you have setting 'a'  equal to brightness +3 and contrast -2
> and a settings 'b' equal to brightness +0 and contrast +0 if you apply
> setting 'a' and then 'b' and the 'a' again you wind up with things looking
> like 'a'. They are not compounded. At least that is what it seems to look
> like in my experiments.

Yes, that's what happens, same as in the darkroom view: each instance of a 
module replaces earlier instances /with the same name/. (Where 'earlier' 
refers to the moment you decide to use/modify the module, the order in which 
modules are aaplied during calculation of the final image is hard-coded)

> I think they should be compounded.

Well, I prefer the current situation: if I copy a history stack from one image 
to another, I do that because the images are taken under similar conditions 
and require similar treatment (at least as a first approximation).

If you want a style that is additive to a certain base style, make sure you 
use *duplicates* of the modules you want to apply. Even in that case, it still 
won't work the way you suggest when you apply such a style twice.

Remco.

P.S. I know not all modules can be applied multiple times, but the ones for 
which it makes sense, usually can.

P.P.S. All this about order of application and effects of applying styles is 
described in the manual...

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] New lens --- where do I put the lensfun database entry?

[Remco Viëtor]

On samedi 20 mai 2017 13:22:22 CEST Romano Giannetti wrote:
> Hi all,
> 
>  I have a problem with DT 2.2.4 --- I have bought a new camera, and
> trying to see if I like it --- a Panasonic TZ100. The lens is not in the
> stock lensfun database yet, but I found the entry in the lensfun
> database --- reported below hoping it's correct. Now, I tried to put it
> in a file in ~/.local/share/lensfun/, the adding it directly to the main
> file in /usr/share/lensfun/compact-panasonic.xml, but no matter what I
> do, the lens is not shown in the list of available lenses.
> 
>  What am I doing wrong?
> 
> 
> Romano
> 
> 
> 
> 
>  
>  Leica
>  DMC-TZ100 & compatibles
>  fixed lens
>  festes Objektiv
>  panasonicTZ100
>  2.75
>  3:2
>  
>   b="-0.040959" c="-0.0636536"/>
>   b="-0.0535213" c="0.00920877"/>
>   b="-0.0124246" c="0"/>
>   b="-0.00155103" c="0"/>
>   b="0.00368039" c="0"/>
>   b="0.00140267" c="0"/>
>   b="0.00153697" c="0"/>
>   b="-0.000878659" c="0"/>
>  
>  
>  
>   model="poly3" focal="23.7" vr="1.0004000" vb="0.000"/>  model="poly3" focal="36.6" vr="1.000" vb="1.000"/>  model="poly3" focal="54.8" vr="0.9997000" vb="1.000"/>  model="poly3" focal="91" vr="0.9996000" vb="0.9995000"/> 
>  
> 
> 
You did close and restart Darktable after the addition? It's possible the 
database is only read from file at start-up.

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] JPG export image size

[Remco Viëtor]

On samedi 29 avril 2017 10:01:43 CEST David Vincent-Jones wrote:
> Looking at the openSuse 'official' repos. I find 2 options, I was using
> the first one.
> 
> Question: will there be any downside to my making the switch? Should I
> do a total un-install?
> 
>   * home:darix:darktable...
>
>  Amaster&package=darktable>
> 
>   o 2.3.0~git598.87e9b98
> home:darix:darktable...
>
>  Astable-2.2&package=darktable>
> 
>   o 2.2.4~git4.af01996
Neither of these are _official_ repositories supported by OpenSuse; see their 
list of (semi)-official repositories at
https://en.opensuse.org/Package_repositories#Factory_and_Project_repositories 
. And even for some there, I quote: "These are repositories available which 
are not officially supported by openSUSE, but they contain useful packages 
which 
you should feel free to use *at your own risk*."

The repositories you refer to are external, third party repositories that use 
an infrastructure provided by OpenSuse, but OpenSuse does not guarantee 
anything about the contents. That said, I've used several (a lot...) of those 
without any problems, but that could have been pure chance... 

Like Roman said, you should be fine just selecting the other version without a 
complete uninstall first. They main problem you could run into when downgrading 
to a lower version number is a  change in the database layout, but I suspect 
Roman would have mentioned that. Do remember what you did, and make a backup 
of the database, just in case. 

Remco.

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Levels vs Tone curve

[Remco Viëtor]

On vendredi 28 avril 2017 23:42:34 CEST I. Ivanov wrote:
> Mostly preference to my understanding. Levels and zone mapping are
> targeting to lighten / darken certain areas. Tone curve is more complex
> and affects also the color intensity. A good approach with tone curve is
> to change to manual mode - then you can adjust lightness separately from
> the color. My personal preference is between zone map and tone curve -
> depending on the particular case. I rarely use levels. This is more of a
> habit.
> 
> Regards,
> 
> B
> 
> On 2017-04-28 09:52 AM, Bernhard wrote:
> > and to make it even more diverse:
> > 
> > I don't use both of them - I do black- and white-point in exposure
> > module and use the zone module instead of curves ...
> > 
> > 
> > regards
> > Bernhard
> > 
> > http://www.bilddateien.de
> > 
> > David Vincent-Jones schrieb am 28.04.2017 um 18:02:
> >> I am sure that we each have different ways of using these modules. I
> >> do my basic processing with the tone curve and then as a close to
> >> final step often (particularly with B&W) use the levels to shift the
> >> gray mid-point.
> >> 
> >> David
> >> 
> >> On 04/28/2017 05:53 PM, darkta...@911networks.com wrote:
> >>> DT 2.2.4
> >>> 
> >>> What's the difference between the levels and the tone curve?
> >>> 
> >>> * Should it be one or the other?
> >>> * Which one is better/easier for setting the white point and the black
> >>> 
> >>>point?
> >>> 
> >>> * What are the differences?
> >>> 
> >>> I've read the "introducing the levels module", it doesn't explain the
> >>> difference
For me it's mostly a balance between ease of use and precision of the 
correction: 
- "Exposure" (or "levels") are easy to use, but only have 2 (or 3) points to 
adjust. They are the only ones that allow precise correction of white and 
black point. 
- "Tonecurve" is the most precise for anything but black and white points, but 
requires more care, and I find it difficult to use for the dark tones. (hint 
for 
devs: add a logarithmic mode like for the basecurve?)
- "Zones" is somewhere in between, although I won't try to correct black and 
white point with it.

"Exposure" has the added advantage that you can correct black and white points 
in both directions, the others only allow you to narrow the range. I find that 
the initial conversion can be too eager to clip highlights; this cannot be 
recovered with "levels" or "tonecurve", but only(?) with exposure. Tip: look 
up luminosity masks.

Remco



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] JPG export image size

[Remco Viëtor]

On vendredi 28 avril 2017 20:03:10 CEST David Vincent-Jones wrote:
> This appears to be a new problem, last day or 2, ... don't have 2.2.4
> unfortunately but hopefully the problem will work its way out with the
> next release. I will just have to re-size and email out of dt. This is
> the openSuse repo. version.
> 
> David
> 
> On 04/28/2017 07:53 PM, Pascal Obry wrote:
> > Le vendredi 28 avril 2017 à 19:50 +0200, David Vincent-Jones a écrit :
> >> 2.3.0~git598.87e9b98-50.1
> > 
> > So you're not using an official release. Can you try with a 2.2.4 to
> > check whether you have the same issue or not?
> > 
> >> typically: a raw 4810 x 2729 exported to jpg at 1500 x 1500 size 90
> >> quality remains full size and 5.0 mb. in the jpg format.> 
> > That's certainly not my experience! So something else is going on!
> > 
> > Thanks,
> 
> 
> darktable user mailing list
> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Well, the 2.3.0~git598.87e9b98-50.1 is *a* version in the OpenSuse build 
system repositories. Those are *not* official OpenSuse repositories.

https://software.opensuse.org/package/darktable shows that there are several 
build system repositories that have DT 2.2.4 versions (the repository 
providing the DT 2.3.0 git version actually has a 2.2.4 build as well). 

The DT version in the official repositories is 1.6.8 for the Opensuse Leap 42.1 
and 42.2 distributions, and 2.2.4 for the Tumbleweed distribution.

Remco.

P.S. I am using OpenSuse, and DT 2.2.4 (from the graphics OBS repo)

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] base curve questions

[Remco Viëtor]

On jeudi 20 avril 2017 08:33:48 CEST I. Ivanov wrote:
> These are interesting thoughts.
> 
> So - it is possible to ignore the base curve and use tone curve for
> example in manual mode. I did use however the base curve with the new
> fusion options. I guess I will have to try experimenting more. Looks
> like the supplied presets are simply a starting point.
That's how I consider them, at least.

As for the fusion options: one of the base-curve presets is "cubic spline". 
This 'curve' doesn't do anything. But it still allows you to use the fusion 
options.

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] base curve questions

[Remco Viëtor]

On jeudi 20 avril 2017 06:24:28 CEST I. Ivanov wrote:
> Hi All,
> 
> I have selected the base curve module as a favorite. What I noticed is
> that the presets available on the right (normal module position) are
> less than the presets that I can access from the favorites (bottom left
> of the image - looks like = but with 3 lines). The last has some very
> specific curves - like like 5D Mark II or 6D.
> 
> Why the sets are different and how some of these presets end up only in
> the favorites shortcut?
> 
> Does anybody happen to have a better curve specific to 70D that excels
> significantly and is willing to share it?
> 
> DT 2.2.4 on Ubuntu 16.04
Not really an answer to your question, but more a general observation 
regarding the base curves.

As you know, the basecurves are supposed to imitate the processing of specific 
camera's (or brands). Or, applying the basecurve for your camera (brand) 
should give the same result as you would have gotten by setting the camera to 
produce a jpeg. As far as I know that is exactly how the basecurves are 
created: take a raw and an in-camera jpeg, and tweak the curve until the 
processed raw looks the same as the in-camera jpeg.

If that's what you want, that's ideal. But that processing isn't necessarily 
the best for every image. Personally, I use a Sony A58, but I rarely use the 
Sony basecurve, as I feel that it compressed the highlights too much.  Instead 
I pick one that suits the image (to *my* taste). 

The DT manual actually suggests to /disable/ the basecurve module for certain 
cases, so it's not a necessary part of the workflow (unlike e.g. demosaicing).

So the whole notion of a "better curve" is a bit meaningless to me, unless you 
can specify what you mean by "better".

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] want to move from iPhoto to darktable Q2 and Q4

[Remco Viëtor]

On mardi 11 avril 2017 22:22:50 CEST Dr. Georg Troska wrote:
> Thank you very much for your answer.
> 
> I saw that feature to correct one folder in the docs, already. But I'm
> afraid to do this for 500 folders is a bit annoying :-)
> 
This may sound harsh, but if you have to correct 500 folders, it looks like 
you made a serious error in your initial setup.

*If* those albums correspond to physical folders on the hard disk, the best 
thing might be to start from scratch:
- make a backup of your current structure *and* of the current Darktable 
database (in case something goes wrong)
- quit darktable and drop the current database, 
- rename the folder structure to what you want
- re-import everything in Darktable.

All relevant data concerning each image are normally stored within the XMP 
files Darktable writes. That means that edits and geotagging will be recovered 
on the new import (see section 2.2.7 of the manual).
___

WRT one of your other questions about creating virtual albums:
that is possible (see "Collect images", section 2.3.2), but those collections 
are /virtual/, i.e. have no existence outside the Darktable database. What I 
do in a similar case: select the images to display, and "export" them in 
optimal resolution to a directory outside the Darktable tree (see manual 
section 2.3.12), dedicated to your shared data. If you are using darktable, I 
expect you work with raw files, so you will have to export your images anyway 
after editing to show them.

As that directory tree and the images in it are outside Darktable's data, you 
can also reorganise them at a later date with no problems.

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] D500 file opening error

[Remco Viëtor]

On mardi 11 avril 2017 09:57:23 CEST Roman Lebedev wrote:
> On Tue, Apr 11, 2017 at 9:56 AM, Remco Viëtor  
wrote:
> > https://raw.pixls.us/ now has samples for the 14-bit uncompressed NEFs
> > (since this week) so DT might support them in one of the next versions.
> > For now, it seems only the compressed NEF formats are supported. So best
> > shoot in them, and perhaps do a test series with lossless and lossy modes
> > to check.
> In the cases where camera can produce more than one sample, it is best
> to provide
> the whole set, even if we miss just one sample. Because then all the samples
> can be visually compared, which is really great.

Indeed. 
I was replying from the point of view of a user, who wants to (or has to) be 
able to develop his raws now. As I'm not involved in development, I don't know 
exactly what you need, so I prefer leaving that side of things to those better 
informed.

And I'm impressed by the speed with which new cameras get incorporated once 
the information is available.

Remco.

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] D500 file opening error

[Remco Viëtor]

On mardi 11 avril 2017 07:57:25 CEST Marco Sartore wrote:
> Hello,
> 
> I am trying to open a NEF 14 bit uncompressed picture taken by my Nikon
> D500 (Darktable 2.2.3 on Ubuntu 16.10). The image is correctly imported
> and I can see its thumbnail in the appropriate window. When I click on
> it to open I get the error "failed to read camera white balance
> infromation from 'filename.NEF' !".
> 
> Any advice ?
> 
> Many thanks in advance,
> 
> Marco
 Looking at /usr/share/darktable/rawspeed/cameras.xml , both of the 
uncompressed modes for the Nikon D500 are marked with 'supported="no"'.
(For both 12- and 14-bit compressed modes, the normal records are present.)
I have no idea why, but it would explain why DT can't edit them.  

https://raw.pixls.us/ now has samples for the 14-bit uncompressed NEFs (since 
this week) so DT might support them in one of the next versions. For now, it 
seems only the compressed NEF formats are supported. So best shoot in them, 
and perhaps do a test series with lossless and lossy modes to check.

Remco.


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Cores or power per core?

[Remco Viëtor]

On samedi 8 avril 2017 21:03:39 CEST Peter Mc Donough wrote:
> Am 08.04.2017 um 20:09 schrieb Frank J.:
> > Am 07.04.2017 um 08:07 schrieb Remco Viëtor:
> > ...
> > 
> >>  And SSD is still quite a bit more expensive per TB...
> > 
> > ...
> > 
> >> Remco
> > 
> > Yes, but you don't have to replace the complete HDD by SSD.
> > 
> > I have a small SSD (120 GB) for Linux (faster booting and program start)
> > and for Darktable-Development (Import, generate Thumbs, rating, tagging,
> > work in darkroom).
> > 
> > When a filmrole is ready developed, then I move the fotos to the
> > "archive" on HDD to free the space on SSD.
> 
> I thought the original raw is never changed, so it probably doesn't
> matter for processing whether it is on an HDD or SSD. The location of
> dartktable's  database should be on an SSD.
> 
All the above is true. But: while you are working on an image the main 
bottleneck is CPU/GPU. /Personally/, I prefer a system where I have to wait a 
few seconds more to chance to the next image over one where I have to wait for 
the pipeline to catch up with my edits (the "working" overlay...). Said 
differently: I'd put priority on the CP/GPU speed/power, and not on disk I/O 
speed.

OP seemed to be on a rather tight budget, and in that case, an SSD might not 
be the most efficient investment. It all comes down to getting the best value 
for the money. What is best value for his money is something OP must decide 
for himself, all I can do is give my personal opinion and experiences.






darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Cores or power per core?

[Remco Viëtor]

On jeudi 6 avril 2017 22:00:21 CEST Ariel Kanterewicz wrote:
> You could maybe look at some benchmarks? Although what I think is more
> important is the performance of the new CPU vs the GPU you plan to keep.
> Another option is to upgrade the GPU and buy extra RAM for the main system,
> if you only want DT to work faster (an SSD would help too).
> 
> I have a Phenom II X4 945 with lots of RAM (started with 8 GB, have 16 GB
> now), I used to have a NVIDIA 460 and the switch to the Radeon 460 was a
> change between night and day. The NVIDIA perofrmed more or less equal to
> the CPU, the Radeon goes WAY faster than that. I even switched on the full
> sample option on export, it's still way faster than before.
> 
> On Thu, Apr 6, 2017 at 6:50 AM Vasilis Yiannakos 
> 
> wrote:
> > I am using Darktable on a 10-year-old-linux-based AMD Athlon X2 64, 8GB
> > DDR2, GeForce GT 640 2GB RAM ram and it runs pretty usable, but I am
> > considering a system upgrade, something with 8GB DDR3 and the same GPU.
> > The
> > question here is from which CPU would darktable benefit the most: AMD FX
> > 8320 (8 cores), AMD A10 (4 cores) or maybe an Intel i3 (2 cores) (these
> > are
> > the top I can get at my budget).

The catch is in the memory standard: currently, we are at DDR4, DD3 seems on 
its way out already. So upgrading memory might be quite difficult for DDR2.
Not sure how those changing standards influence the GPU or SSD choice (entry 
models use SATA III). And SSD is still quite a bit more expensive per TB...

Also, you compare two GPUs of different generations (NVidia 460: ~2012, Radeon 
460: 2016). Although NVidia seems to have some trouble with openCL (except the 
latest series, 1060 and above, but that's a higher price class).

Some other things to be aware of:
- I see DT use all available cores (4 on my machine) when switching directory 
in light table mode (i.e. when DT has to generate a lot of thumbnails). The 
rest of the time, all cores seem used as well (though in my case, at low 
intensity even when using profiled denoise). I didn't check GPU usage for this.
- you'll need OpenCL to actually use the GPU, and in practice that requires 
the proprietary drivers (both for NVidia and for AMD).
- AMD CPUs absorb more power, and thus generate more heat, than current Intel 
CPUs (120W for AMD vs. 65-95W for Intel). Also a larger GPU requires more 
power. and the PSU has to be able to provide that power (not really a problem 
for a new system, upgrading is different).
- perhaps pay attention to the sockets used by the different CPU's you are 
looking at: the AMD cpus seem to use a fairly old socket, abandonned for the 
latest Ryzen CPUs, which could limit potential future upgrades. The I3 uses 
the 1151 socket, which still seems current.

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Strange filmstrip behaviour in darkroom

[Remco Viëtor]

On jeudi 6 avril 2017 17:48:46 CEST Mark Heieis wrote:
> Hi,
> 
> I've been noticing some strange behaviour with the film strip when in
> darkroom mode.
> 
> 1) when I select an image to edit from lighttable, darktable enters darkroom
> but the filmstrip is not synchronized to the selected image being edited.
> (In this case, I have 363 images in the collection)
> 
> 2) the filmstrip is randomly(?) presenting duplication of images and missing
> others.
> 
> 3) It is not presenting all of the images in the collection. In one case,
> the selected image from lighttable appears for editing in darkroom but
> doesn't appear in the filmstrip. If another image is selected from the
> filmstrip, the previous image can only be re-edited by selecting it from
> lighttable again.
> 
> 4) selecting an image from the filmstrip does present the correct image for
> editing, however, the filmstrip adjusts to a completely different section
> of the strip. The selected image remains selected but one has to find it
> again.
> 
> I don't have any clue how, when or why this is happening to help isolate the
> problem.
> 
> darktable-2.2.3-1.fc25
> 

I noticed that there's a version 2.2.4 available now, source and at least 
OpenSuse rpm's.  I have no idea if using that version would help you.

But, there's no announcement for this version on the Darktable web site.

Remco



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Fwd: Darktable cannot open and replaced by a game....

[Remco Viëtor]

On lundi 3 avril 2017 15:56:38 CEST Patrick Shanahan wrote:
> 
> and if you would post text instead of html and wrap your lines at < 78
> cols.

Sorry about that, I *thought* I had configured my mailer to send only plain 
text (but then, KMail2 has played a few other unexpected tricks).

For the rest, I think I'll bow out of this discussion, just put a reminder in 
my agenda not to use DT on april, 1st.

Bye
Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Fwd: Darktable cannot open and replaced by a game....

[Remco Viëtor]

On samedi 1 avril 2017 14:59:22 CEST dt-l...@stefan-klinger.de wrote:
> Antoine Lassus (2017-Apr-01, excerpt):
> > I am facing a situation with Darktable 223  this morning it cannot open
> > anymore and instead I have a game window here attached.
> 
> April fools joke.  Joke is: When I pressed `1` or `2`, it rated the
> images that were selected when I closed DT.  Only eight of them, but
> be careful.

Indeed, unpleasant surprise...

It would be nice if at least the key that switched to the normal interface 
would be swallowed, and *not* 
transmitted as input to darktable's normal functions...

Btw, see https://redmine.darktable.org/issues/11559 for the developer's take on 
this joke.

Remco



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Fwd: Darktable cannot open and replaced by a game....

[Remco Viëtor]

On Saturday, April 1, 2017 12:02:13 PM CEST Remco Viëtor wrote:
> On Saturday, April 1, 2017 11:51:29 AM CEST Antoine Lassus wrote:
> > Dear Darktable team,
> > 
> > I am facing a situation with Darktable 223  this morning it cannot open
> > anymore and instead I have a game window here attached.
> > 
> > Thanks for your help.
> > Best,
> > Antoine
> > [image: Inline image 2][image: Inline image 1]
> 
> Yes, I had that as well.
> I managed to disable it the first time I started Darktable, but don't
> remember the key I used.
> 
> Not a nice joke... let's hope it only 'works' today like that.

Update: try hitting some letter keys, to get back to the normal interface.
(best be careful with the mouse, once I got into the "game" part, it seemed 
stuck there)


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Fwd: Darktable cannot open and replaced by a game....

[Remco Viëtor]

On Saturday, April 1, 2017 11:51:29 AM CEST Antoine Lassus wrote:
> Dear Darktable team,
> 
> I am facing a situation with Darktable 223  this morning it cannot open
> anymore and instead I have a game window here attached.
> 
> Thanks for your help.
> Best,
> Antoine
> [image: Inline image 2][image: Inline image 1]
> 

Yes, I had that as well. 
I managed to disable it the first time I started Darktable, but don't remember 
the key I used.

Not a nice joke... let's hope it only 'works' today like that.

Remco




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Does OpenCL require the AMDGPU-PRO driver? Yes, but does not require installation, just some libs

[Remco Viëtor]

On Saturday, April 1, 2017 8:22:24 AM CEST Tobias Ellinghaus wrote:
> Am Freitag, 31. März 2017, 13:26:56 CEST schrieb Remco Viëtor:
> 
> [...]
> 
> > Btw, don't bother with NVidia cards if you need [...] CUDA, but
> > don't want to use the proprietary drivers...
> 
> For CUDA you have to get an NVIDIA card, there are no alternatives.
> 
> > Remco
> 
> Tobias

I know. But CUDA also needs the proprietary drivers, which was my point.
If you don't want to use proprietary drivers, NVidia has no advantages, afaik. 
(but look here 
for more info: https://nouveau.freedesktop.org/wiki/.

Remco




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Does OpenCL require the AMDGPU-PRO driver? Yes, but does not require installation, just some libs

[Remco Viëtor]

On Friday, March 31, 2017 1:12:09 PM CEST Dave wrote:
> I have just bought a laptop with gtx1050 installed. 4GVram. Going through
> hell getting the drivers working though.
> 
> AMD is easier to get running *ducks and runs

As proven by the current thread :P

I don't know what OS you use, but I've never had problems getting the 
proprietary drivers to run 
under OpenSuse...

Btw, don't bother with NVidia cards if you need openGL/openCL/CUDA, but don't 
want to use 
the proprietary drivers...

Remco



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Does OpenCL require the AMDGPU-PRO driver? Yes, but does not require installation, just some libs

[Remco Viëtor]

On Friday, March 31, 2017 12:01:18 PM CEST Brune Wayce wrote:
> Hi,
> which NVidia card did you get?
> I'm looking for a new NVidia card for my pc (now I'm, working with the
> integrated gpu intel hd2500 and i5-3450) and I'm wondering if a NVidia 1050
> would be enough to get a sensible boost...
> 
I just looked into that myself, and decided to go for a GTX 1060 6Gb card, 
based on the results 
published by Phoronix in november last year (http://www.phoronix.com/scan.php?
page=article&item=darktable-opencl-gpu&num=1).

>From that article, it looks like the 1050 somehow doesn't work all that well, 
>esp. not compared to 
the next level up (which is the 1060). But it's the cheapest in the range... 
One thing I missed in 
the article I cited is the amount of memory each card carried, that might play 
a role in the results 
(the 1050 cards seem limited to 2Gb, the 1060 can have 6Gb).

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Re: Export for web - downscale

[Remco Viëtor]

On mercredi 29 mars 2017 11:04:18 CEST Lorenzo Bolzani wrote:
> I did another test: sharpening in darkroom or sharpening using a style in
> the "export selected" panel gives identical results.
> Instead, exporting a downscaled image, reopening this smaller image and
> then applying sharpening gives different, better, results.
> 
> So my advice was wrong or not ideal at least. It was based on this part
>  of the
> manual that I find quite confusing/ambiguous:
> 
> About export styles: "*You can use this feature to add processing steps and
> parameters that you want to be applied specifically to images before
> export, e.g. you may define a style that adds a stronger level of
> sharpening when you produce scaled-down JPEG files for the internet or add
> a certain level of exposure compensation to all of your output images.*"
> 
> But sharpening gets softened a lot during downscale so it doesn't seem a
> good example, more like a workaround.
> 
> So it seems like some separate post processing is needed.

Indeed, an option to apply a style after resampling would be nice. Even better 
if such a style 
could include the export parameters (esp. size).

As for sharpening related to downsizing: using a larger radius to offset the 
downscaling *might* 
work.

Remco.



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Dealing with blown blue channel

[Remco Viëtor]

On mardi 28 mars 2017 14:49:09 CEST Per Östlund wrote:
> Hi,
> 
> I've digitized my father's collection of old slides with the camera +
> macro lens + light table method. Most of the images look fine, but some
> images with certain blue hues are giving me a headache. I'm guessing the
> issue is that the light table I built used LEDs with a poor color
> spectrum for the task, causing the blue channel to blow out.
> 
> As soon as I touch e.g. the levels module I get the usual issue that
> very saturated blues turn black. Using the gamut clipping option in the
> input color profile module fixes that particular issue, but doesn't do
> anything for the colors otherwise.
> 
> The best solution I've managed to come up with so far has been to set
> the input color profile to "linear Rec709 RGB" which heavily desaturates
> the image, and then increasing the saturation a lot with the color
> correction module. Hardly an optimal solution, but with some tweaking I
> can usually get the colors to look approximately the same except that
> the blues don't clip anymore.
> 
> This method can require quite a lot of tweaking to look good though, so
> my question is if someone knows of a better way to handle this issue
> (besides reshooting with a better light source). Here's an example
> RAW-file (don't mind the blur, that's from the original slide):
> https://www.dropbox.com/s/6mshjycwm4n10xa/img_014.ARW?dl=0

First the good news: as far as I can see you have no blown channels in the raw 
file, even the 
blues stay within range of the sensor. The bad news is that with the default 
settings, a large 
part of the image gives 'out-of-gamut' warnings. And to be honest, the image 
looks over-
saturated. 

So what I tried was: 
- set base curve to 'leica' (less aggressive than the Sony default, esp. in the 
highlights).
- set gamut clipping to 'adobeRGB' (or sRGB).

then I used two copies of 'contrast brightness saturation', 
- the first for a global saturation correction of -0.2,
- the second was at saturation -0.35, with a parametric mask limiting the 
effect to the blue 
colors: 'b' channel from -128/-128 (full left) to -29/-3.

If all slides are similar, you could set this up for one slide and the create a 
style to apply those 
settings as a base to others.

But would it be possible that the original slides have faded a bit over time, 
and especially the 
red dye?

Good luck,

Remco




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Canon g7x mk ii - dark corners and incorrect focal length

[Remco Viëtor]

On lundi 27 mars 2017 15:56:29 CEST Graham White wrote:
> Yes, a lot of high end lenses suffer from this too; you don't see it
> with jpegs, because they have software correction applied in-camera, and
> if you process RAW ouput with a mainstream RAW processor, then it's not
> a problem either. I have a Panasonic Leica four thirds Summilux 25
> which has quite bad distortion unless you correct for it. We should
> try to push to get dt users generating their own LensFun data
> 
> Is there any software that will take a jpeg and a RAW of the same image
> (one with lots of straight lines, presumably) and work out LensFun data?

I don't know of any software that uses a RAW with the corresponding jpeg to 
calculate lens 
corrections. But Hugin can determine the correction parameters from a few RAW 
files (or rather 
uncorrected jpeg/png/tiff files):
http://hugin.sourceforge.net/tutorials/calibration/en.shtml or
http://libregraphicsworld.org/blog/entry/creating-lens-distorsion-models-with-hugin-lens-calibrator
 or
http://wilson.bronger.org/lens_calibration_tutorial/

Note that for a zoom you have to do the calibration at several focal lenghts.

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Canon g7x mk ii - dark corners and incorrect focal length

[Remco Viëtor]

On lundi 27 mars 2017 11:19:42 CEST Alex Delaforce wrote:
> The image problem is more than distortion. The image circle doesn't cover
> the sensor leaving black corners. If I use jpeg instead of RAW I think the
> processor stretches the image to cover the rectangle corners. 
That's exactly what happens, although Canon would describe it probably as 
"correcting the lens 
distortion" (which is also what happens). From what I found on the web, the 
lens has quite a bit 
of barrel distortion at the shortest focal length, which you would want 
corrected anyway.

> Which I think is a bit bodgy!
It depends on what you expect from the camera, I guess. For similar cameras 
that only provide 
jpeg output, no one would be the wiser. In this case, you also get access to 
the unprocessed 
raw file, so you see what happens during jpeg generation.

> I'm pretty sure I'm going to send the camera back. But I will try the xml
> file sent via this list first.

Are there any better alternative cameras in the same price bracket?

Remco.



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Canon g7x mk ii - dark corners and incorrect focal length

[Remco Viëtor]

On dimanche 26 mars 2017 13:23:52 CEST Alex Delaforce wrote:
> Hi,
> 
> This is a Darktable question not a camera question.
> 
> I get dark corners and reports of 8mm focal length with this compact.
> Should I get a different camera for use with DT or is there something I
> can do to fix this. I use DT with Ubuntu.
> 
> I use DT with my canon 6D with great results. I wanted a compact to
> carry when I don't want all my kit with me.
> 
> I really don't want to have to use Lightroom or the Canon DPP software
> as I love DT
> 
> Any advice gratefully received
> 
The camera itself is marked 8.8-36.8mm focal length, so that's more or less as 
expected. The 
24-100 mm cited in some tests is the equivalent for 35mm cameras, and related 
to the sensor 
size. Note that DT reads the focal length information from the EXIF data in the 
image file.

Vignetting is often a bit of a problem with zooms, but can be corrected in DT. 
If there's a correction profile available for the lens, such corrections can 
even be done semi-
automatically. 

But, while the *camera* has been added to the Lensfun database, but *lens* 
correction data 
aren't available (so far). You might try using the profiles for the Canon g7x 
('Mk I'). You can 
also try to generate the correction profiles yourself, there are tutorials for 
this on the web. This 
is easy enough for distortion, less so for vignetting, but in this case, the 
distortion correction 
seems to solve a large part of the vignetting problem:
http://www.imaging-resource.com/PRODS/canon-g7x-ii/canon-g7x-iiA4.HTM

Hope this helps, 

Remco



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] New Google JPEG compression algorithm

[Remco Viëtor]

On vendredi 17 mars 2017 16:46:23 CET Jean-Luc Lacroix wrote:
> "Google has developed and open-sourced a new JPEG algorithm that reduces
> file size by about 35 percent"
> 
> https://arstechnica.com/information-technology/2017/03/google-jpeg-guetzli-e
> ncoder-file-size/
> 
> Would DT benefit from it?
> 
You did pick up the bit about it needing 300MB per Mpix in the original?
That would mean for me at least 7 GB/image only for the compressions...
(that 300MB/MPix is mentioned on the Github repository here:
https://github.com/google/guetzli/ , linked to from the article you cited)

In addition, it seems to be slower than current jpeg encoders, and I thought 
the colour quality in 
the "eye" exemple less than in the traditional jpeg.

I'd suggest waiting a little bit longer.

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Printing Problem Epson ABW Mode

[Remco Viëtor]

On jeudi 16 mars 2017 09:17:47 CET KOVÁCS István wrote:
> Tiff compression might also be the culprit.
> Kofa
> 
> > The Epson program reads a tiff export just fine from LR…so i think DT may
> 
> have a bug in its tiff export.
> 
> 
___
_
> darktable user mailing list
> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
TIFF is a complex format with a lot of 'dialects' and options, so problems with 
importing a TIFF 
generated by another program are rather common. Not necessarily a bug in 
darktable.

But why do you need TIFF in this case? Afaik, PNG does almost everything TIFF 
does. the 
only difference I know of is that PNG is limited to only one layer (TIFF can 
handle multilayer), 
but that shouldn't be relevant if you use the file to print. (and PNG tends to 
give smaller files).

Remco

PS: Darktable (under linux) uses libtiff.so, so that might be the place to drop 
a bug report.






darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] OT: Merging multiple images

[Remco Viëtor]

On mercredi 1 mars 2017 15:56:57 CET darkta...@911networks.com wrote:
(...)
> 
> I would prefer first merge, then use DT. I can easyly convert the raw
> image to 16-bit TIFFs without any processing.
> 
(...)

Well, no, you can't: if you generate a TIFF from your raw, you'll have at least 
set the raw black 
and white point, aplied a demosaicing, an auto(?) white balance setting, and 
converted to a 
colour space. You might even have an exposition correction applied (depending 
on how you do 
the raw conversion). 

If you first do the conversion in DT, you can make sure that all the images get 
the exact same 
development, which will make combining the images much easier. Especially the 
WB setting is 
critical, as it determines the overall colour tone of your image. So setting 
this identical for all 
images of the series helps in getting a seamless merge. 

What I do in such cases is: pick a typical image (usually the brightest one 
where I don't want 
highlight clipping) and develop it more or less normally.
Make sure the white balance is set to *manual* (you can use the values auto WB 
gives you). 
Then, in the light table, I copy the history stack of this image to all the 
others in the series, and 
export the whole series as 16-bit PNG. (PNG tends to be a lot smaller than 
TIFF, with no loss 
in functionality for this use).






darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] OT: Merging multiple images

[Remco Viëtor]

On mercredi 1 mars 2017 07:57:32 CET Remco Viëtor wrote:
> On mercredi 1 mars 2017 06:57:46 CET darkta...@911networks.com wrote:
> > DT 2.2.3 on arch.
> > 
> > I took photos of a car at night and did some light painting with an
> > LED in 25 seconds blocks.
> > 
> > I have 9 images with each image a different area of the car lit by
> > the LED. How can I merge them and selecting the lit section?
> > 
> > They are all lined up (tripod).
> > 
> > Is there some software that will allow me to masks them.

On reflection, you might not even need masking. One of the layer blend options 
in GIMP (and I 
suppose Krita) uses the lightest of each of the inputs. That might do almost 
exactly what you 
want (perhaps with some modifications of layer opacity or some masking).




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] OT: Merging multiple images

[Remco Viëtor]

On mercredi 1 mars 2017 06:57:46 CET darkta...@911networks.com wrote:
> DT 2.2.3 on arch.
> 
> I took photos of a car at night and did some light painting with an
> LED in 25 seconds blocks.
> 
> I have 9 images with each image a different area of the car lit by
> the LED. How can I merge them and selecting the lit section?
> 
> They are all lined up (tripod).
> 
> Is there some software that will allow me to masks them.
> 
> Gimp is a problem, it's only 8 bit and I'd like to print the image
> to at least 11 by 14 and maybe 16 by 20. (the last time I tried, there
> was some banding in the skys)

You're right, it's off-topic.

That said, you don't have all that many options afaik.

The GIMP springs to mind, since version 2.8 it uses GEGL for most of its 
operations. GEGL is 
supposed to work in floating point. (Note that your final jpeg output will 
still be 8 bit/channel, but 
this shouldn't cause the banding).

Otherwise, there's Krita, mostly used for drawing/painting, but it also has 
layer and masking 
options.

And perhaps Hugin, though the masking options probably aren't optimal for your 
needs.

And of course, if you are a MacOS user, photoshop.

Remco



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Darktable with fujifilm, oversaturated blues.

[Remco Viëtor]

On mardi 28 février 2017 11:47:04 CET Roman Lebedev wrote:
> On Tue, Feb 28, 2017 at 12:12 AM, alex  wrote:
> > The Rec2020 RGB seeems to work best! however,
> > 
> > it seems to make normal shades of blue excessivly green..
> 
> Are you *really* sure you
> are changing gamut clipping in the input color profile module
> and *not* the input color profile in input color profile module?
> 
That is one of the options in the "gamut clipping" drop down list...

I didn't have time to check the exact list of options when I first replied, but 
after checking, 
both drop lists show a series of profiles/colour spaces.

As a first try, it seems the most logical to pick an input colour space, and 
clip the gamut to 
that *same* colour space. After that, you can of course experiment. 


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] automatically applies some settings

[Remco Viëtor]

On lundi 27 février 2017 00:00:18 CET Michael wrote:
> what I mean is when I open a new image up in dt five modules are activated
> automatically:
> 0- original image
> 1- orientation (which doesn't appear to do anything)
This uses metadata to decide if the image needs to be rotated (over +/- 90°), 
needed for 
portrait oriented images.
> 2- sharpen (improves slightly)
You usually want this, the way most cameras are constructed, and the 
demosaicing, lead to 
some blur, which this module counteracts (but cannot correct).
> 3- basecurve (that blurs details)
This module works per pixel, so doesn't influence neighbouring pixels (i.e. 
isn't be able to blur 
details). Inactivating this module should get you a very dark image lacking 
contrast.
> 4- color balance (blurs even more)
Strange, I never see that one automatically applied, but it also shouldn't blur 
the image (works 
on individual pixels only)
> 5- white balance (changes the colors of things)
That's its function: it corrects for the difference in the colour of the actual 
light and theoretical 
white light. You'll want it, without it you should get a very green image
> I want to eliminate modules 3, 4, and 5 and to understand what module 1 is
> doing.

Unless you have a small sensor in your camera (like 2-4 Mpixel), the image on 
your screen is 
reduced in size. DT needs some time to apply the pipeline when you open an 
image, or edit 
something. This can give you temporarily a less sharp image. How long that 
lasts, depends on 
your computer. 

And except for the sharpen module, none of the modules you list can lead to 
blurring of the 
image, as they all work on individual pixels, and not on groups of pixels.

But, if you insist, they can all be turned off (except 0), by clicking on the 
power button at the left 
of the module name (in the right sidebar in the darkroom). I'm pretty sure you 
won't like the 
result, though.

Are you by any chance new to darktable and raw development? In that case, 
reading the 
Darktable manual (which explains what the modules do and why they are in a 
certain order) 
might be a good start. Also, a site like http://www.cambridgeincolour.com/ (and 
several others) 
has good articles on most aspects of (digital) photography, including editing 
and post-
processing.




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] automatically applies some settings

[Remco Viëtor]

On samedi 25 février 2017 23:08:11 CET Michael wrote:
> I don't want dt to automatically apply some modules and I want to change
> other modules settings. How do I do it?

Well, some of the automatically applied modules can be switched on and off like 
any other 
(using the "power" icon). Some cannot be switched off, but those are all 
*essential* to get a 
displayable image with reasonable colours.

For me, the non-switchable modules are:
- raw black/white point: needed to limit the range of valid values from RAW
- demosaic : essential on raw, but there is a passthrough option (*)
- input color profile: getting into DT's colour space
- output color profile: getting the result into the required colour space.

All of these do have variables that the user can modify. In this they behave 
like any other 
module. 

But perhaps I'm missing something, and in that case, telling us which modules 
you want to 
switch off or modify might help.

(*) The demosaic does more than interpolate the raw data, it also decodes the 
data from 1 
channel/pixel (with 12- or 14-bit values) to whatever DT uses internally (at 
least 3 channels, 
perhaps an alpha channel as well). This makes the module essential.

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Fujifilm X100F RAW crash

[Remco Viëtor]

On samedi 25 février 2017 22:00:27 CET Richard Shaw wrote:
> Hi,
> 
> I'm getting a couple issues loading RAW files from a Fujifilm X100F which
> have used the Film Simulation filter.  Specifically:
> 
> Failed to read camera white balance information from blah
> file has unknown format
> 
> On that last one, darktable crashed and I have the crash report which I'll
> add to a bug report.
> 
> Is this RAW format not supported? if so, does anyone know when it's due to
> be supported?
> 
> darktable 2.2.3 macOS 10.12.3
> 
> Regards,
> R.
> 
> 
___
_
> darktable user mailing list
> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

http://www.darktable.org/resources/camera-support/ doesn't mention the X100F, 
which might 
imply it's not supported.

But don't forget that DT 2.2.3 was released february, 1st, and the camera came 
on the market 
about mid-january. That would have given the developers 2 weeks to get raw 
images from that 
camera, reverse-engineer the format and implement the required changes. Not 
very long. 

As for when it will be included? No idea, that depends on the amount of (spare) 
time the 
(volunteer, unpaid) developers have to work on it.

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] white balance

[Remco Viëtor]

On samedi 25 février 2017 01:38:01 CET Marcus Sundman wrote:

> Well, first we need sensible support for color cards in darktable. (Now
> you have to go through crazy many hoops to set your whitebalance from a
> color card, including multiple import/export and profile generation in
> an external program and custom command line tools and whatnot.)

First you need a correctly calibrated and profiled screen (and printer if you 
plan on printing). Without that, you'd have to work strictly by the numbers, 
because there's no way you can visualise the final result. (OK, if you publish 
on the web, >90% of the viewers won't have a profiled screen, but at least you 
know how it should look)

Then, setting your white balance from a *colour* card is looking for trouble 
(if it is at all possible to get any decent white balance from such a card).

As has been said already, for a white balance, you need a neutral spot in your 
image: light or dark gray, but not white or black. (Such a spot can of course 
be a *neutral* spot on your colour card). Remember that 'setting the white 
balance' means changing the ratios green/red and green/blue (in practice, 
green is set to 1.0, and the red and blue channels are multiplied by one value 
each, depending on colour temperature and tint, DT _shows_ those multipliers 
in the white balance module, and allows you to change them directly).

When you have that neutral spot in your image, in DT it's just a matter of 
choosing the "spot" mode in the white balance module and select a rectangle on 
the neutral spot.

The colour patches are used to create a *camera profile*, and yes, this needs 
an external programme (or two), just like screen or printer profiling. 
*Unlike* screen and printer profiling, it's something that's mostly needed for 
very colour critical work. (the few times I bothered with a camera profile, 
the results with a custom profile were identical or nearly identical to the 
default profile and I had no way to show which was better) And when you get to 
that level, you also have to be very careful about your lights all having the 
same colour, as the colour of the incoming lights influences what the camera 
"sees".

And just a small question: is there *any* raw developer that includes the 
possibility to generate an input profile from a colour card? 

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Darktable with fujifilm, oversaturated blues.

[Remco Viëtor]

On samedi 25 février 2017 11:47:44 CET alex wrote:
> I have some serious trouble using darktable with fuji's raw files. It
> seems that certain shades of deep blue are completely oversaturated,
> worst is blue ledlight. Rawtherapee handles the files just fine and in
> camera jpegs are also very good but darktable is doing something strange
> to the files. Link below contains a couple of shots and the rawfile in
> question.
> 
> https://www.dropbox.com/sh/7orybjumfljmt58/AACP22Pckk7mSTfITt8xFUB9a?dl=0
> 
That's a known phenomenon, and described in the manual, and it's not limited 
to Fuji raw files (I see it with my Sony raws as well). Iirc, it's caused by 
DT using unconstrained values within its pipeline, and some modules don't like 
L values outside the 0..1 range. 

A (partial) solution is to set gamut clipping in the "input profile" module to 
something else than off. What can also work is lowering the saturation with a 
parametric mask limiting the effect to the intense blues.

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] What is the exact order in which the modules are applied?

[Remco Viëtor]

On dimanche 12 février 2017 11:45:36 CET Dave wrote:
> They're applied from the bottom up ☝
> 
> On Sun, 12 Feb 2017, 13:38 Jordi Besora, 
> 
> wrote:
> > "*Don't wish it was easier, wish you were better*" - Jim Rohn
> > 
> > Hi,
> > 
> > I'm working on my workflow and I want to adapt it to the way darktable
> > works. To that effect, I've been looking for information on the order the
> > modules are applied, but I can't find it anywhere.
> > 
> > I've been checking this mailing list, where the subject has been discussed
> > (always with the wrong approach in mind, IMHO) plenty of times, but didn't
> > find any ordered list of modules. And the darktable website does not
> > feature a search button.
> > 
> > So, my question is: can you provide a list with all the modules ordered in
> > the order in which they are applied?
To be a bit more precise:
Modules are applied from the bottum up, using the list in the tab with the 
"power on/off" symbol (circle with vertical line)

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] OpenCL Support is not available.

[Remco Viëtor]

On mardi 7 février 2017 09:13:39 CET J. Paul Bissonnette wrote:
(...)
> Here is the OP from darktable -d opencl
> 
> ///
> jpb@maple:~$ darktable -d opencl
> [opencl_init] opencl related configuration options:
> [opencl_init]
(...)
> [opencl_init]
> [opencl_init] could not find opencl runtime library 'libOpenCL'
> [opencl_init] could not find opencl runtime library 'libOpenCL.so'
> [opencl_init] found opencl runtime library 'libOpenCL.so.1'
> [opencl_init] opencl library 'libOpenCL.so.1' found on your system and
> loaded
> [opencl_init] found 1 platform
> [opencl_init] found 1 device
> [opencl_init] device 0 `Quadro K2000' has sm_20 support.
> [opencl_init] device 0 `Quadro K2000' supports image sizes of 16384 x
> 16384
> [opencl_init] device 0 `Quadro K2000' allows GPU memory allocations of
> up to 499MB
> [opencl_init] device 0: Quadro K2000
>  GLOBAL_MEM_SIZE:  1997MB
>  MAX_WORK_GROUP_SIZE:  1024
>  MAX_WORK_ITEM_DIMENSIONS: 3
>  MAX_WORK_ITEM_SIZES:  [ 1024 1024 64 ]
>  DRIVER_VERSION:   378.09
>  DEVICE_VERSION:   OpenCL 1.2 CUDA
> [opencl_init] compiling program `demosaic_ppg.cl' ..
(...)
> [opencl_build_program] successfully built program
> [opencl_build_program] BUILD STATUS: 0
> BUILD LOG:

((etc. for a number of other programs and then:))
> 
> [opencl_init] compiling program `bloom.cl' ..
> [opencl_fopen_stat] could not open file
> `/home/jpb/.cache/darktable/cached_kernels_for_QuadroK2000/bloom.cl.bin'!
> [opencl_load_program] could not load cached binary program, trying to
> compile source
> [opencl_load_program] successfully loaded program from
> `/usr/share/darktable/kernels/bloom.cl'
> [opencl_build_program] could not build program: -5
> [opencl_build_program] BUILD STATUS: -2
> BUILD LOG:
> 
> 
> [opencl_init] failed to compile program `bloom.cl'!
> [opencl_init] FINALLY: opencl is NOT AVAILABLE on this system.
> [opencl_init] initial status of opencl enabled flag is OFF.
> [pixelpipe_process] [thumbnail] using device -1
> 
> //
> #[opencl_init] could not find opencl runtime library 'libOpenCL'
> #[opencl_init] could not find opencl runtime library 'libOpenCL.so'
> 
Don't forget to quote the next line as well,next time...
"> [opencl_init] found opencl runtime library 'libOpenCL.so.1'
"> [opencl_init] opencl library 'libOpenCL.so.1' found on your system and
"> loaded"

> Here is the output from locate libOpenCL
> 
> jpb@maple:~$ locate libOpenCL
> /usr/lib/i386-linux-gnu/libOpenCL.so.1
> /usr/lib/i386-linux-gnu/libOpenCL.so.1.0
> /usr/lib/i386-linux-gnu/libOpenCL.so.1.0.0
> /usr/lib/x86_64-linux-gnu/libOpenCL.so.1
> /usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0
> /usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0.0

You do have an openCL library installed, and DT finds it. (as shown already by 
the fact that DT starts compiling openCL kernels...)
What went wrong is that DT *failed* to compile one of the needed kernels.  
That can have several causes, from missing capabilities in the opencl library 
to bugs in DT's source or the opencl implementation you use.

Remco



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Move to new dual drive machine advice

[Remco Viëtor]

On dimanche 5 février 2017 12:06:29 CET Francesco Scaglioni wrote:
> HI,
> 
> On 05/02/17 10:41, Remco Viëtor wrote:
> > On dimanche 5 février 2017 09:56:26 CET Francesco Scaglioni wrote:
> >> Hi
> >> 
> >> On 04/02/17 16:59, Patrick Shanahan wrote:
> >>> * Francesco Scaglioni  [02-04-17 11:50]:
> >>> 
> >>> Explain more to me the problem with dt not preserving the directory
> >>> structure.  And I do not know if dt's moves are recursive, you may need
> >>> to
> >>> move each individual directory.
> >> 
> >> I can create the new folder structure locally that is not a problem.
> >> 
> >> The existing structure is :
> >> 
> >> home//me/Photos/year/month/projects( maybe up to 4 or 5 )/? sub-projects
> >> 
> >> If I ask DT to import recursively eg 2013 it will load the images from
> >> all sub-folders.  If I then ask DT to copy or move them to a new 2013
> >> destination it will do so but the folder structure below the original
> >> 2013 is not recreated in the new target folder and all images end up
> >> getting placed in the new 2013 folder root.
> > 
> > Does darktable have a problem with symbolic links? If not, why not have:
> > "/home/me/Photos/2017/..." for current year as direct storage on SSD
> > "/home/me/Photos/2016" as a symbolic link to "/home/me/media/photos/2016"
> > ?
> > And the same for 2003--2015, so 14 folders to move, 14 symlinks to create;
> > sounds like a job for a bash script. Note that the number of folders under
> > the year is not important here.
> > 
> > At the end of the year:
> > *close DarkTable*
> > move /home/me/Photos/2017/... to /home/me/media/photos/
> > create a new directory for 2018
> > create a symlink for 2017
> > 
> > This way, you keep the original folder structure.
> > Indeed, changing the folder structure is going to cause a lot of work, but
> > as long as it's repetitive, scripting should be possible, as it's
> > basically changing a *part* of the pathname in a known and constant way.
> 
> I had thought about symlinks ( I assume that they can be created
> recursively ) - my worry was that if I then decide to delete old photos
> then the symlink would be deleted and not the image.  If I edit and old
> photo and export a sidecar file would the sidecar file end up in the
> same folder as the image ?

If you'd have to create symlinks recursively down to the level of individual 
photos, there would be NO interest in using them... 

Sorry, but I guess you'll have to read up on what symbolic links are and do. 
Too much to explain here.

Remco.


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Move to new dual drive machine advice

[Remco Viëtor]

On dimanche 5 février 2017 09:56:26 CET Francesco Scaglioni wrote:
> Hi
> 
> On 04/02/17 16:59, Patrick Shanahan wrote:
> > * Francesco Scaglioni  [02-04-17 11:50]:
> > 
> > Explain more to me the problem with dt not preserving the directory
> > structure.  And I do not know if dt's moves are recursive, you may need to
> > move each individual directory.
> 
> I can create the new folder structure locally that is not a problem.
> 
> The existing structure is :
> 
> home//me/Photos/year/month/projects( maybe up to 4 or 5 )/? sub-projects
> 
> If I ask DT to import recursively eg 2013 it will load the images from
> all sub-folders.  If I then ask DT to copy or move them to a new 2013
> destination it will do so but the folder structure below the original
> 2013 is not recreated in the new target folder and all images end up
> getting placed in the new 2013 folder root.
> 
> With images going back to 2003, generally 12 sub-folders per year and
> then sub-sub folders below that doing the whole thing one folder at a
> time would be a real PITA.
> 
> Googling the issue resulted in a post from 2014 that suggested manually
> editing the DB to change image paths - again, not only does this sound
> risky but would need to be done for every folder thus not much to gain
> over using the GUI.  What I was looking for was a way to eg select
> 2013/* and move it en bloc whilst preserving the existing directory
> structure below 2013.
> 
> Cheers
> 
> Francesco
> 
> darktable user mailing list
> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Does darktable have a problem with symbolic links? If not, why not have:
"/home/me/Photos/2017/..." for current year as direct storage on SSD
"/home/me/Photos/2016" as a symbolic link to "/home/me/media/photos/2016" ?
And the same for 2003--2015, so 14 folders to move, 14 symlinks to create; 
sounds like a job for a bash script. Note that the number of folders under the 
year is not important here.

At the end of the year: 
*close DarkTable*
move /home/me/Photos/2017/... to /home/me/media/photos/
create a new directory for 2018
create a symlink for 2017

This way, you keep the original folder structure. 
Indeed, changing the folder structure is going to cause a lot of work, but as 
long as it's repetitive, scripting should be possible, as it's basically 
changing a *part* of the pathname in a known and constant way.

(Oh, and please ONLY reply to the mailing list. I'll read any follow-ups 
there, and have no need to receive 2 copies)

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] How to fix overblown white?

[Remco Viëtor]

On samedi 4 février 2017 09:03:18 CET Michael Below wrote:
> Hey,
> just a quick note about the basecurve: that curve is very early in the
> processing stack. So if you blow your highlights in this stage, they are
> gone, before you can do something about it. If there are exposure problems
> it is far better to use the contrast curve in the colour tab, because that
> is applied later. Cheers
> Michael

Yes and no. 

Note that I said it was not very useful to disable the basecurve *if you are 
going to enable it again later*. In DT, modules are applied in a fixed order, 
independant of when you activate them. In addition, DT works internally in 32-
bit floating point, and does not clamp the colour values within the pipeline 
(that's what the developers tell us, anyway: see section 3.2 in the manual). 
Of course, colour values *are* clamped to a fixed range at the end of the 
treatment (if only because you don't want values to wrap around when going to 
8 bit/channel), but that's not relevant in selecting which modules to use.

That is not to say that picking another basecurve to spare your highlights 
can't be useful, but this *will* influence the whole image, just like the tone 
curve. That was something the OP wanted to avoid. And that requirement means 
you will have to use some form of masking. I find that parametric masks can 
work rather well in such circumstances.

And don't forget that, in general, you will want to apply a rather aggressive 
S-curve to transform your sensor data (intensity linear with photon count) to 
something pleasing for you (intensity ~logarithmic with photon count). You 
have a choice of using one of the provided basecurves (optimised to reflect 
the basic style of different camera brands) or build your own in the tonecurve 
module.

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] OpenCl with AMD graphics card

[Remco Viëtor]

On samedi 4 février 2017 02:22:52 CET Jos Dassen wrote:
(...)
> It is clear that the amd module is not loaded. But I have no clue as to why.
> The installer did build a new kernel and that one was booted. If anyone has
> a clue, please let me know.
> I could find another hard disk and try with plain Ubuntu 16.04, but
> personally I doubt whether the problem lies with Mint. Thanks, Jozef Dassen

If the module you want isn't loaded, but you do have a GUI, that usually means 
there's another module that takes preference. From what you give us, we can't 
check that (the "grep" made sure of that).

Also, on my system (Opensuse Leap), the log file for X is /var/log/Xorg.0.log
so your command "ls /var/log/Xorg" wouldn't show it...
Look for lines starting with "EE" in there on a first pass.

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] How to fix overblown white?

[Remco Viëtor]

On vendredi 3 février 2017 22:03:47 CET Anton Aylward wrote:
> I have a picture of a white barrel cactus (Cleistocactus icosagonus) which
> was taken in strong light, bringing out the white 'leafs'.  The
> illumination is along one edge, rather like a crescent moon.  The crescent
> is overblown whenever I convert to JPEG, and I can't figure out how to
> manipulate it down without the rest of the image being darkened or
> distorted.

First thing to check is whether there's anything left to work with in the 
highlights: if you toggle the 'raw overexposure indicator' (the small square 
with the RGB bayer mask under the image') and you see all three channels 
marked as over-exposed, there's nothing really useful you can do (except 
retaking the image, not always an option) 

If that's not the case, and you are working from a RAW file, what you can try 
is using exposure correction with a luminance mask:
- go to the 'exposure' module
- set the 'exposure' slider to -1 EV (this will darken your whole image for 
now)
- then, select 'parametric mask' as 'blend mode', and in the 'input' sliders 
push the left closed triangle all the way to the right. Make sure you are at 
the tab marked with a 'g' (lowercase g!).

To refine your mask, you can play a bit with the positions of the left 
sliders. But check your image if you do that, I found that in some cases I got 
ugly artifacts when pushing that too much (same reason why I use -1 EV maximum 
with this maksing). If you want to visualise the mask, click once on the white 
square with the black disk on it (bottom right in the module).

Also, in the 'highlight reconstruction' module, select 'reconstruct in LCh' as 
method, that might get you back some detail in the blown parts.

But be prepared to always get some darkening in at least part of the image, 
unless you have a very clear separation between the overblown parts and the 
rest. You don't normally want too sharp a separation between the parts you 
correct and the rest, as that can easily give you edges/banding at the 
separation)

Btw, there's no reason to turn off the basecurve at any stage in the 
processing, only to turn it on again later.

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: why alway raw? was : Re: [darktable-user] Nikon D750 support?

[Remco Viëtor]

On mercredi 1 février 2017 19:04:39 CET Serge Schmitt wrote:
> Le mardi 31 janvier 2017 07:43:27 Remco Viëtor a écrit :
> > And I often prefer a slightly darker image than the default
> > jpeg gives me, anyway.
> 
> While I can understand and still mostly favor myself the use of raw files, I
> cannot understand the use of "default jpeg". Why use "default" settings
> while there are so many possibilities to tweak the image in camera ?
 
I agree that I could get the look I want by tweaking the camera settings.
What I meant here with 'default' was 'the default DT gives me'.

> As an "amateur" photographer for 55 years, I always have seen, first with
> "labo", to day with software, processing as mostly desperate attempts to
> remedy bad exposure... So the in camera process would be for most people the
> best choice...

And the in-camera processing is what most people use in practice. But those 
are not the users you find here (almost by definition, as DT is a RAW 
processor...).  

> In this meaning, and based on what I see on Flickr, Ipernity and others I'm
> conviced that one day I'll probably shoot 90% jpeg, which nevertheless can
> be sufficently (for my taste) tweaked in Darktable and Bros. Most people
> won't ever never see the difference when printed or on screen size.

Same thing, most people shoot jpeg only (is there any phone that produces RAW 
images?). They don't need more, and don't want more. Nothing wrong with that.
But that's not a reason for *me* to limit myself to what the camera is willing 
to produce. I prefer getting the best possible exposure in camera, and then 
get the image I want while working on a decently sized screen, with better 
tools than a camera can give me

Also, you took my reply out of it's context, which was a question about how to 
get the same image as the camera delivered. I just pointed out that, while 
reproducing the in-camera image might be a good starting point, it's not the 
aim of using RAW format, so he should not limit himself to that or get too 
fixated on that.

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Color look up table whitebalance

[Remco Viëtor]

On mardi 31 janvier 2017 02:56:08 CET Marcus Sundman wrote:
> On 30/01/17 22:01, johannes hanika wrote:
> > hi,
> > 
> > On Tue, Jan 31, 2017 at 5:42 AM, Marcus Sundman  wrote:
> >> On 30/01/17 10:13, johannes hanika wrote:
> >>> hi,
> >>> 
> >>> i suppose you've seen this
> >>> 
> >>> http://www.darktable.org/2016/05/colour-manipulation-with-the-colour-che
> >>> cker-lut-module/ ?
> >> 
> >> "to interact with the colour mapping, you can change both source and
> >> target
> >> colours. the main use case is to change the target colours however, and
> >> start with an appropriate palette"
> >> 
> >> However, I want to do the opposite. I want to start with an appopriate
> >> target palette (the xrite color checker card) and then pick the source
> >> colors from the picture.
> > 
> > more specifically i meant the second half of it, about the darktable-chart
> > tool.
> That is insanely complicated and time-consuming, involving multiple GUI
> tools as well as command line commands, generating ICCs etc. Imagine
(...)
> 
> And if there was a way to choose the whole palette at once (just mark
> the 4 corners of the palette in the picture, like you do in the xrite
> tool) it would be virtually as quick as the normal white balance. And if
> this tool would manage to find the palette by itself (like the xrite
> plugin does) then it'd be even faster than the normal white balance tool!

Have you tried using a white balance target, and the spot setting for the 
white balance module? IMO that should give you the result you want, with less 
hassle than the color target.

I don't see what you expect to gain from using a 24-patch colour target (which 
should be lit evenly btw., not like in the sample image you posted) instead of 
a white balance target (and using the "spot" option in the WB module in DT, of 
course). The more so since 24 patches for a LUT profile (which is what you 
propose to make) is not recommended (the profiles generated from such targets 
are matrix profiles)

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Nikon D750 support?

[Remco Viëtor]

On lundi 30 janvier 2017 16:22:15 CET Jani Kajala wrote:
> Thanks for the tips, activating "shadows and highlights" module and "base
> curve" + changing base curve from "Nikon like" to "Nikon D750" indeed did
> the trick, now getting identical starting point in LR and DT, and this
> matches also very closely to default JPG output from the camera.

Just keep in mind that the main reason to use RAW files is _not_ to reproduce 
the in-camera jpegs (if it was, why bother). That's not to say that it 
shouldn't be possible, but quite often you can do better than in-camera jpeg 
(esp. wrt highlights and sharpening).

A large part of the treatment depends on taste. For instance, I quite often 
use the Leica-like basecurve, instead of the automatically selected Sony-like. 
That gets me a darker image, with less blown highlights (the Sony-like curve, 
like some others, is _very_ flat at the right side, so less visible detail in 
e.g. clouds). If that makes the shadows too dark, exposure fusion, tone curve, 
etc. correct that. And I often prefer a slightly darker image than the default 
jpeg gives me, anyway.

So, for me, reproducing the in-camera jpeg would at best be a starting point.

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Ubuntu 14.04 support

[Remco Viëtor]

On samedi 28 janvier 2017 03:32:14 CET Jos Dassen wrote:
> Hello, 
> I see that newer darktable versions  not available any more on Ubuntu 14.04
> Trusty will no longer be receiving updates after 2.0.7.
> 
> Is there a good reason for that ??
> Point is that this is still under LTS (in the Mint version).I tried to
> update to 16.04 and, while darktable works, a lot of other stuff
> (especially hardware drivers) are still problematic on 16.04. I would
> prefer a bit more stability over going for the latest features as soon as
> they are available.

 I don't think that's anything the Darktable team controls or decides. 

The maintainers of any distribution (not only Ubuntu) are the ones who decide 
which versions get included in their repositories. The authors of the 
respective libraries and programs have no say in that.

It's not at all uncommon to see distributions stick to old versions of 
programs and libraries, esp. in LTS editions, which are supposed to be stable 
for a long(er) time.  And the user that chooses a LTS version presumably wants 
that stability as well.

Remco.

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Exported JPEGS always darker and more satuated

[Remco Viëtor]

On mercredi 18 janvier 2017 14:35:36 CET KOVÁCS István wrote:
> > What I changed was the export profile from sRGB to Adobe RGB (compatible).
> 
> And that is the cause of your problems. Compared to sRGB, Adobe RGB
> uses a different gamma, which makes your images darker when viewed
> using a non-colour-managed viewer; it also has a wider gamut, which
> makes colours more saturated.
> Most displays are relatively close to sRGB, so if you export as 'sRGB
> (web-safe)', you're likely to get reasonable colours even if your
> environment is not colour-managed.
> 
> If you publish on the web, you should probably stick to sRGB: even if
> everything is colour-managed on your computer, web-based galleries may
> rip the embedded colour profile from your image, and your audience is
> likely to use a non-managed environment, too.

Apart from that, why would you want to use a color space for your output 
that's larger than what most displays are able of showing, independant of 
proper calibration/profiling? Atm at least, only (some) high-end screens can 
show more than sRGB, so using sRGB for web export seems the best choice.

For printing it's a different story, best thing there is conform to what your 
print shop wants / can handle.

And  you cannot use the same export for both web and printing anyway, unless 
you make very small prints. Aside from colour problems, you get the best 
result if the image is displayed at 100%, i.e. without resizing. Any 
resampling will soften the image, and the methods used in most browsers are 
fairly crude (but fast).

Remco

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Exported JPEGS always darker and more satuated

[Remco Viëtor]

On mardi 17 janvier 2017 09:09:32 CET Jeena wrote:
> Hi,
> 
> > If all we get is before and after images, without any information about
> > settings, we can only guess at what the problem is...
> 
> What kind of settings should I provide? If I knew on which settings to
> work, I'd be able to test things myself.
> 
> /Jeena
> 
> darktable user mailing list
> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Well, the settings in the export section seem the most relevant. And indeed, 
what do you use to view the images? Although if that makes a difference, you 
probably use non-standard export settings anyway: even the most color-agnostic 
viewers can get sRGB images right most of the time.

More precisely, first thing that comes to mind: the export settings:
profile, colorimetric intent (not the most likely, but..), style, and (if you 
use a style) mode.

And if you apply a style on export, what modules does it contain, and do these 
use any kind of masking?




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Exported JPEGS always darker and more satuated

[Remco Viëtor]

On lundi 16 janvier 2017 17:14:01 CET I. Ivanov wrote:
> Hi,
> 
> If you are to turn on soft proof in DT - does it match what you have on
> output (assuming same profile is attached to both soft proof and the end
> JPG).
> 
> How about the gamut - is it giving a warning in the areas that are changing?
> 
> Regards,
> 
> B
> 
> On 2017-01-16 05:02 PM, Jeena wrote:
> > Hi,
> > 
> > I'm getting great rusults with darktable it's an awesome program. But
> > I have some strange behaviour when exporting my pictures as JPEGS,
> > they are always darker and have more satuation in them, therefor I'm
> > often losing details which are visible while editing like for example
> > the cloud in this image: https://jeena.net/t/darktable-export.png
> > 
> > Or colors which were spot on while editing suddenly have much more
> > contrast or satuation or something like in this image:
> > https://jeena.net/t/darktable-satuation.png
> > 
> > What can I do to prevent that? I already tried all combinations of
> > profile and intent but it didn't change anythng.
> > 
> > /Jeena
If all we get is before and after images, without any information about 
settings, we can only guess at what the problem is...

Remco


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Sharpening (round 2)

[Remco Viëtor]

On lundi 16 janvier 2017 18:35:51 CET darkta...@911networks.com wrote:
> Hi,
> 
> DT 2.2.1 on arch
> 
> I'm still having problems with the export: 900x900.
> 
> Here are my settings: http://i.imgur.com/QS74VlT.png
> 
But what do you do exactly in that extra style you apply on export?
And what's the exact command you use to mogrify your images?

Fairly standard advice seems to be to apply a little bit of extra sharpening 
after you have reduced the size of an image, to counter the softening effect 
that has (somehting like unsharp mask with radius ~1pixel, intensity to 
taste).

To me it looks like the mogrified version has had that extra sharpening 
applied (almost too much even, there's some suspicion of halo formation at the 
highest contrast edges).

Remco



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Mac OS Users: lua scripts working?

[Remco Viëtor]

On jeudi 12 janvier 2017 08:50:03 CET J Albrecht wrote:
> > On 11 Jan 2017, at 22:46, William Ferguson  wrote:
> > 
> > You could ask the MacOS GIMP packagers about the error and see if they
> > have any ideas
> I wouldn’t know where to begin to ask. Seems that something like this would
> require a certain degree of coordination between the Mac OS packagers of
> both Gimp and darktable. Based on similar User requests for
> interoperability between programs (a current one relating to darktable and
> DigiKam comes to mind) I can appreciate that the packagers have more
> pressing matters to contend with.
> 
> Well, this inability to call Gimp from Darktable isn’t a critical issue in
> any case. Back to the old way of doing things…

In an earlier message you posted :
> Python quit unexpectedly while using the libglib-2.0.0.dylib plug-in.
as part of the error messages you received.
Some use of Google seems to show that this error occurs when the  python you 
have was compiled against a different version of libglib-2.0.0.dylib than the 
one you have installed.

And if using "Gimp " on the command line gives the same error, 
then it's not a Darktable problem, but a version mismatch on your system.
(starting gimp from the command line doesn't touch Darktable in any way)


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org