+1 for one monitor UI, one monitor image (Re: [darktable-user] Dual monitor?)
Le 11/04/2016 08:21, HaJo Schatz a écrit : Thank you all for your replies! A 15" laptop it is then with a larger external monitor. Now I'm only keeping my fingers crossed for dt to support both monitors (UI on one, photo on other) one day. But no big deal, I just get a larger monitor for the additionally required screen estate :) Hajo Aha, it looks like I'm not the only one to have this exact idea. Also looks like: Le 11/04/2016 01:52, darkta...@911networks.com a écrit : Yes, I can drag it to one, but then it stays on that monitor. What I'd love to do is to have the lightable on the left monitor and the darkroom on the right. Let me make it more explicit: # Situation Often I observed that there is a trade-off between space eaten by toolbars (especially in darkroom) and convenience. # Idea IMHO dual screen allows to get the best of both worlds: * one monitor shows the lighttable /and all toolbars/ at all times * the other monitor shows the /only/ photo being edited when in darkroom mode, fullscreen, no toolbar, no border # Benefit Dedicating the first monitor to all non-photo stuff makes available the *full resolution* of the second monitor to be used for the photo. The user would have to move the pointer often between the two screens, but experience working with two screens for other stuff has already proven IMHO that it's not a problem. # PoC implementation A proof-of-concept might even be as easy to implement as " have the darkroom image widget in its own top-level window, instead of the center of the darktable window". The user can then just drag this window to their preferred monitor and voilà. What do you think? -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Export to JPG Pics are blurred
Le 12/05/2016 13:51, Blickwinkel a écrit : Hello, if I export the edited images to jpg these are blurred. The original pic size is 7424x4924 px Export configuration Jpeg 8bit Quality 100% Size 0x0 Does anyone have any idea why this may be? JPG exports are okay for me here with version 2.0.3 on Ubuntu 16.04 64-bit. Can you be more specific and post an example online ? -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Re: Export to JPG Pics are blurred
Le 12/05/2016 15:12, Blickwinkel a écrit : Here is a screenshot Left side is RAW edit, right side jpg http://www.fotos-hochladen.net/uploads/bildschirmfoto71niatemp3.png _ Left is definitely pixellated while right is smoothed. On the left, everything is rendered with 2x2 pixel blocks. Left looks less blurry but does not actually contain more details that right. So, it's not that "JPG are blurred". Temporary diagnostic: pictures aren't displayed 1:1 scale but they are scaled up 2:1, aren't they ? What software are you using to display JPEG on the right ? Can you ask it to display 1:1 size (pixel-perfect) ? On the left, are you seeing the RAW file with darkable ? Else with what ? Can you ask it to display 1:1 size (pixel-perfect) ? Can you share RAW and JPEG files ? It will help make a definite diagnostic. Regard. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] fish eye lens
Le 08/07/2016 14:47, Matthieu Moy a écrit : - Original Message - will darktable correct the distortion of a fish-eye lens? Yes: see the "lens correction" module (well, assuming that your fish-eye lens has less than 180° field of view, otherwise removing distortion is basically impossible). If your lens is not supported, you can get it calibrated: http://lensfun.sourceforge.net/calibration/ However, note that some "distortion" is unavoidable with very short focal lens: if you remove the optical distortion then straight lines in reality will remain straight in the picture, but you will still get the feeling of having the corners stretched. With an ultra-wide lens (very little optical distortion), I often _add_ distortion to make the image more natural (typically for landscape). In lens correction module, don't hesitate to cycle through most values of "geometry" option to find the best one for a particular case. Setting the geometry to "panoramic" often gives good and natural results in landscapes. -- Stéphane Gourichon http://fidergo.fr/ I write high quality, production grade software for companies. darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] Questions about darktable exposure fusion
Hello, Darktable exposure fusion released after 2.2.0 is interesting. I tested it, and as expected it brightened pictures a bit like draco tone mapping operator but with more natural colors and different style of controls. Great! LWN wrote about it in A look at darktable 2.2.0 [LWN.net] <https://lwn.net/Articles/710496/> that (emphasis mine): In scenarios where the dynamic range of a scene is too wide to be captured in a single shot, the photographer can shoot *multiple exposures* (e.g., one to capture the highlights and one for the shadows). Those exposure*s* can then be combined <https://www.darktable.org/2016/08/compressing-dynamic-range-with-exposure-fusion/> via darktable's new "exposure fusion" module. In essence, *the two frames (or however many were taken)* are stacked together, The link is to https://www.darktable.org/2016/08/compressing-dynamic-range-with-exposure-fusion/ I'm somehow confused because the latter link processes only one picture at a time. Please explain if the following assertions are right or wrong and explain: * Darktable basecurve fusion always considers only one image at a time. Never "two frames", several input files (be it bracketed exposure, flash/no flash, etc.). * Darktable basecurve fusion implements http://web.stanford.edu/class/cs231m/project-1/exposure-fusion.pdf in the restricted case where "sequence" is actually a copy of the same input data with digitally boosted exposure. * Darktable applies "traditional" basecurve upstream (i.e. before, or "first, then fed into") of Mertens/Kautz/Van Reeth algorithm. * In traditional darktable basecurve, the output values for any pixel in output image only depends on the input value of that same and only pixel in source image, not any surrounding pixel. * Darktable basecurve fusion is not reducible to an overall "meta-basecurve" because, following Mertens/Kautz/Van Reeth algorithm, it considers the neighborhood of each pixels in deciding which pixel to take, a kind of operation that traditional basecurve does not perform. * As a consequence, darktable implementation provides the benefit of the algorithm in term of rendering perception (preserve natural colours, etc), but not the improved noise in dark area of the flash/no-flash option, since there is only one input image. That would either need preprocessing of the whole algorithm before darktable, or feeding several pictures into darktable to implement the whole algorithm. Thank you in advance for clarification! Probably a number of people will benefit. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Not happy with the colours
Hello, Can you share raw, JPEG-from-dt, XMP (and possibly screenshot with explanations) on some site for others on the list to see ? Le 17/01/2017 à 19:28, Oliver Bedford a écrit : I'm not really happy with the colours dt produces from the raw files of my Canon EOS M3. E.g. in a photo taken of someone on a bright day in snow, the OOC jpegs have more saturation and brightness in the sky, the snow looks cooler (especially the shadows have more blue), whereas the skin tones look warmer than in the dt output. BUT: at the same time the gray jacket remains fairly neutral and doesn't have an unrealistic colour cast. I've tried to tweak the dt output using velvia, colour zones, tone curve, base curve, white balance, contrast, brightness & saturation but failed to get the overall look. There were always side effects (increase saturation --> gray jacket gets more blueish; adjust white balance --> gray clouds get a colour cast etc.). Would the procedure outlined in http://www.darktable.org/2016/05/colour-manipulation-with-the-colour-checker-lut-module/ help in this respect? Can the IT8 target also be used to calculate an enhanced colour matrix? This is perhaps of more general value than a LUT(???). Regards, Oliver darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] How to remove red flare from photo
Le 29/08/2016 à 16:06, Romano Giannetti a écrit : On 29/08/16 14:40, Stéphane Gourichon wrote: Le 28/08/2016 à 18:42, Jos a écrit : Hi, I have taken a picture from a sun set with my wife and son in the front. In the picture there is an annoying big red spot. Probably a reflection from the sun. I would like to know what is the best work flow or module(s) to use to remove this spot. I attached the problem part of the picture to this mail. Thanks. Hello, This can be done in this particular case, see attached picture! Wow! incredible... where is the +1 to click ;-). Thanks for the tutorial! Thanks for the feedback. Corrections: * enable channel mixer. On red output, set green input to 1.1 and blue output to -0.1. Other Should be: * enable channel mixer. On red output, set green input to 1.1 and blue *input* to -0.1. Other I forgot to add: disable exposure boost which was just meant to observe histogram. Happy that it suited you. To avoid flare next time, have you got a lens hood ? It not or if the light source appears in the frame, you can prevent flare to some extent by hiding light source with a finger or hand. In some cases you can consider taking two shots : one hiding the sun, the other not, and mix both in postprocessing. Best used with a tripod. Have a nice day! -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Practically, what was the problem fixed in 2.0.7? (Re: [darktable-user] PSA: ATTENTION NIKON OWNERS !!!)
Hello, darktable 2.0.7 was announced today with this: Base Support (fixes, was broken in 2.0.6, apologies for inconvenience) Le 07/10/2016 à 15:00, Roman Lebedev a écrit : As you may have seen, an issue with white level for some nikon cameras (or so i thought) was discovered by me: https://www.mail-archive.com/darktable-dev@lists.darktable.org/msg01196.html Web page says: For that reason, many nikon cameras in cameras.xml had completely arbitrary whitelevel specified, which resulted in wrong image => either way too bright (if 12bit wl was specified, and image is from 14bit-uncompressed) or too dark and with purple highlights (if 14bit wl was specified, and image is from 12bit-uncompressed) or with just purple highlights (all other cases, e.g. "*-compressed"). Using a D5200 for 3 years, I would consider myself savvy enough to notice such a problem if it hit me (be careful about shoot-time exposure ( careful about in-camera histogram, sometimes expose to the right) and darktable-time exposure, choose basecurve or even disable when appropriate, use highlight reconstruction). I never saw purple highlights (unless highlight reconstruction was turned off or tweaked, which is normal then). Now using darktable 2.0.3 on Xubuntu 16.04. I haven't noticed anything, perhaps because my raws are always 14-bit (don't know if compressed or not), never 12-bit. Questions: * Can someone provide a description and perhaps some examples of the symptoms to be checked? * What should affected users do? What does it break? * What if users have worked on photos in buggy versions? Should they e.g. shift exposure by 2EV or whatever? Thank you for your attention. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] Creating XMP file only when makes sense: rationale?
Le 20/11/2016 à 19:24, Tobias Ellinghaus a écrit :
That is not feasible as we rewrite the XMP files all the time. Not just when
you edit the image in darkroom.
IMHO this behavior pops up too regularly in discussions.
# Context: user feedback + usual reply
This is from memory, I might be wrong.
User: "darktable (writes an uninteresting XMP file | clobbers
interesting XMP file) for *each and any* raw or jpeg file that it
encounters at startup. This (slows down|clutters directories|loses minor
information|loses important work|feels wrong)."
Reply (from memory): (due to the way we organized things|we just write
XMP at some points in time and which causes overall behavior just like
you wrote|it's too difficult to change that behavior|just remove them if
undesired|make dir read-only)
Spirit of Free Software whispers : "Use the source Luke."
# Zooming out to get the big picture
From an outside perspective, current behavior still doesn't feel right.
From a functional point of view, there's no good reason to write a XMP
file for a file that was not even opened in darkroom.
Sure, darktable has default processing options, and might use them to
display thumbnails (in some configurations).
But by definition these options are *generated defaults*, so there's no
point in saving them.
Saving them "pins" those default to the particular version of darktable
just run, is there added value ever in that?
# Related information
Does current code causes an inclination for bugs like this one? Bug
#10012: Darktable overwrites existing XMP files
<https://redmine.darktable.org/issues/10012>
Also, option write_sidecar_files is not the wished behavior, as XMP
files are definitely useful when they contain not only generated
information, cf. 8.2. Core options | user manual | darktable
<http://www.darktable.org/usermanual/ch08s02.html.php>
# Guessing an implementation
Quick look at ./src/common/image.c void dt_image_write_sidecar_file(int
imgid):
> // TODO: compute hash and don't write if not needed!
Darktable *already features some tags "changed" and "exported"* in
database, searchable with the "collect images" structures filtering module.
Given the expected semantic of a "changed" tag, it looks efficient,
simple and natural to write something like:
if ( (no XMP file already exists) && (image has no tag "changed") ) {
skip xmp creation };
That way, XMP indeed gets created when relevant.
# Benefit and conclusion
Current implementations feels like darktable has "dirty hands" or goes
"like a snail/slob/slug": wherever it goes you see its trails that you
have to clean if they're undesired.
* With new behavior, user can open in darktable any dir (USB key from a
friend, whatever) and not clutter it.
* Only edited pictures (if any) will get a sidecar file, which makes it
easier to spot them e.g. for copy-paste back in external file manager.
* Opening wrong directory will not clutter it.
All those use case happened to me. I'm not covering all cases for the
sake of brevity, but I don't get why this was not approved earlier.
(1) Can a fellow savvy darktable wizard elaborate/explain?
(2) If someone offered a clean patch performing this exact change "just
opening a file does not create a XMP, an edit causes it", would you
merge it? If not, can you explain the rationale?
Thank you.
--
Stéphane Gourichon
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Weird colors and difficult noise reduction compared to LightRoom or RawTherapee
Le 08/12/2016 à 00:44, Saint Germain a écrit : Hello, I just bought a Samsung NX1 and would like to use Darktable to process the RAW (SRW). However I really tried but I couldn't manage to get correct colors or to have a good noise reduction in high iso situation (low light). I've tried LightRoom and RawTherapee and I managed (without knowing these softwares) to get quite good results in under 5-10 minutes. So far I think I've spent several hours with Darktable... I would really like to stay with Darktable (as I find the interface quite pleasant and it offers a lot of useful features) but I really need to have good colors and good noise reduction (at least comparable to LR and RT) without too much tinkering. From what I have heard, it seems that Darktable noise reduction is very powerful and actually superior to LR or RT. Basic noise reduction in LR or RT is very simple : 2 sliders and that's it (Luminance and Details). However it is quite effective, and I haven't been able to do better with Darktable (and it took me much more time, I even made a noise profile !). Perhaps am I doing something wrong ? Can someone guide me or show me how to proceed ? Hello. Thanks for sharing all details. Attached is my take on it. Given base material (high iso, not much actual detail) I took a somehow more aggressive approach than usual (on the "preserve detail" vs. "kill noise" spectrum). Here's the parameter dump: * disable base curve * disable profiled denoise * RAW noise reduction, default parameters * increase exposure +3.10EV so that brightest part (yellow title) is just on top * bilateral filtering, red 0.04 green 0.02 blue 0.1 * non-local means, default parameters * optionally, equalizer preset "noise reduction" * sharpen, default parameters Here are the rationales for those choices : * disable base curve: source is low dynamic range (paper) and furthermore already has its own base curve * disable profiled denoise: haven't imported your profile. Anyway, when strong, generally does not perform well with bilateral. * RAW noise reduction: filters part of noise, at the cost some high-frequency killing which is okay in this specific case * bilateral filtering: attenuates large area hue variations somehow, without losing details at this strength * non-local means: filters out some residual speckles * equalizer: reduces noise some more, at the cost of more loss of details * sharpen: to selectively recover edges attenuated by equalizer Somehow off-topic: * to correct barrel: chosen hackish lens correction parameters: NX10 and 20-50 F3.5-5.6 ED, looks good * set white balance "spot" selecting white part of title. Much better color, well, balance. Reset it to see how previous case could hide yellowish noise stains in white areas. * Subject is still. Why didn't you choose a longer exposure ? ISO would have been lower, so less noise to begin with. Regards. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org http://www.w3.org/1999/02/22-rdf-syntax-ns#;> http://ns.adobe.com/xap/1.0/; xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/; xmlns:darktable="http://darktable.sf.net/; xmp:Rating="1" xmpMM:DerivedFrom="SAM_1274.SRW" darktable:xmp_version="1" darktable:raw_params="0" darktable:auto_presets_applied="1" darktable:history_end="18"> 2 5 2 3 3 2 5 1 3 1 2 1 1 1 2 5 1 1 1 1 0 0 0 1 1 1 0 1 1 1 1 0 1 1 1 1 flip clipping basecurve denoiseprofile denoiseprofile temperature exposure rawdenoise globaltonemap bilateral nlmeans atrous bilateral atrous temperature lens atrous sharpen e051823ea086d53ce2073b3f84576b3fcdcc4c3ecdcc4c3ecdcc4c3fcdcc4c3ecdcc4c3fcdcc4c3fcdcc4c3ecdcc4c3f0100 gz09eJxjYIAAruuLrbmuK1vPmilpN2vmTLuzZ87YGRsb2zMwONgbGxcD6QYoHgVDCbAhsZmQ2ACgKQ0r 8040803f80bfbe62c63af00cb43a9ba14b3809149337daf49738 803f803f80bfbe62c63af00cb43a9ba14b3809149337daf497380100 00409c45638c913f803fc6184b40 68664640484280c0 0ad7233c 02009a99593fc842 704170410ad7233d0ad7a33c90c2753d 00404842003f803f gz04eJxjZ4CAs2d87M6eOWM3a6
Re: [darktable-user] Weird colors and difficult noise reduction compared to LightRoom or RawTherapee
Le 08/12/2016 à 17:55, Tim Rolph a écrit : On Thursday 08 Dec 2016 08:13:27 Robert Krawitz wrote: On Thu, 8 Dec 2016 12:08:52 +0100, =?UTF-8?Q?St=c3=a9phane_Gourichon?= wrote: Here's the parameter dump: * disable base curve * disable profiled denoise * RAW noise reduction, default parameters RAW noise reduction, unfortunately, won't help in my case, since my original is a JPEG. Shooting RAW isn't very practical at a game where I might shoot 2500 frames. https://rlk.smugmug.com/Photography/DarktableRawTherapee/ https://rlk.smugmug.com/Sports/Basketball/MIT-SarLaw-mbb-20161126/i-chq2xjG/ A Try NeatImage it's the best I have found at de-noising non raw images and its available as a standalone on linux for free. It also makes use of opencl / cuda capabilities so it's quick. Regarding NeatImage, apparently a Dutch company : https://ni.neatvideo.com/ says "the most advanced noise reduction algorithms in the industry." https://ni.neatvideo.com/overview/how-does-it-work links to https://ni.neatvideo.com/download/noise-profiles although it looks like there are less profiles than in darktable (well, for Nikon at least). Strange and heavy format. Speaking of good non-free noise reduction software, how about DXO Optics Pro, then? (Not for Linux, though). I've seen impressive demos of their PRIME denoiser in the past (and the denoiser before PRIME). Explanations on the current site boil down like profiled non-local means, so the secret sauce must be elsewhere? http://www.dxo.com/us/photography/photo-software/dxo-opticspro/features/prime -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
"color label" Re: [darktable-user] filter 'could be bug' (I think so)
Le 14/12/2016 à 05:40, darkta...@911networks.com a écrit : DT 2.0.7 on arch. I was filtering images by the color: yellow (that I use as a temp marker). Yes, what we call "color label". 1. Did process my image, (darkroom, metadata...) 2. When finished, I removed the color yellow and the image 'disappeared' (correct). BUT the metadata display staid the same and did not disappeared Here is the screen capture after removing the yellow tag and still displaying the metadata from the image that doesn't qualify for the filter (no image selected within the filter but the metadata display is still there): http://i.imgur.com/3f6Tveu.png Same for the tagging. It also shows the tags associated by the image that had the yellow color removed. The "old" metadata and tags displayed are refreshed as soon as you select another image, right? Looks like an issue with traditional code patterns where one has to write code to propagate information in one direction (e.g. from click to select image operation) and back (from selected image to various displays) and some paths are missing? What bugs me also is that line on top says "1 image of 13 in current collection is selected", which suggests that the image disappearing after color label removal is still considered "selected". How many images are shown in collection ? Is 13 before or after color label removal? Cheers. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Work loss, analysis and solutions Re: [darktable-user] Sidecar files being overwritten
Le 30/12/2016 à 03:47, Marcus Sundman a écrit :
Wait, what? Does this mean that I can't moves files from one computer
to another?
I regularly switch between different computers, and those presumably
have different library.db files, right?
Does something bad happen if I edit the same file from 2 different
computers? Will one overwrite changes made by the other even if I
don't have the file open in different computers at the same time?
Yes, and I think that overwrite-with-old-data happened to me, although I
have not at the time taken note of what happened precisely.
This can happen not only because of accessing photo collection from
different computers.
Another reason: a photo collection on an external drive. Even on the
same computer, the mount point is not always the same. Reasons are
varied: USB device name changing depending on what was plugged since
boot, duplicate disks labels, USB device stuck then unplugged/replugged.
As a result, the *same* library will contain a number of duplicates
history data and overwrite XMPs which were actual up-to-date data.
Also, when using one mount points, photos from other mount point appear
in database, as skulls.
# Scenario 1: changing computer, two libraries
(1) Mount disk to computer 1, edit photo.
(2) Unmount, mount to computer 2, edit photo, darktable cannot notify
the other database
(3) Go back to computer 1, mount disk, open darktable, your edits from
(2) are lost.
# Scenario 2: same computer and library, two mount points
(1) Mount disk, edit photo.
(2) Unmount, mount to different path, edit photo, darktable thinks it's
a different one
(3) Mount to first path, open darktable, your edits from (2) are lost.
# Analysis
The problem comes from current implementation assuming that when the
external world changes, its local beliefs ("reference by full paths that
are stable", "I am the one that edited it last", "I know it's history
better than the XMP") have priority.
These are reasons to consider per-image information in database a cache,
and XMP primary information.
# Ways to solving that
Way 1, today: having darktable read XMP file first avoids that loss.
This is the safest choice, and safe choice should be default in sane
software, leaving savvy users to change them to "optimized but unsafe"
choices like assuming database is more up-to-date.
Way 2, since Darktable 2.2: workaround giving up fast query on large
collections
darktable --library :memory:
Thank you Matthieu Moy for notifying about the library split in
darktable 2.2. It's a step to better solutions.
Way 3: best of both worlds by fixing broken assumptions
Compatible with moving between computers and mount points, allow big
collections (tags, etc) that need quick query capabilities.
That reference problem is not specific to darktable. Music library
managers, git, git-annex, virtualbox, vmware, docker and the like solved
it by storing all information related to a collection/VM/container *at
the root* of the collection, with a unique ID, independent on host
system, mount point and other factors.
In darktable context that would mean store per-photo information not in
user home dir but in a per-collection database at the root of the
collection, storing only relative paths in the database.
That requires the user once to point at a folder and tell darktable
"there is a collection that has this folder as root".
You can then open your collections on any machine with any mount point,
no more duplication, no skulls, no lost work.
Yet the potentially huge collection has its per-photo library. You still
can query your photos for tags, etc, very quickly.
What do you think?
--
Stéphane Gourichon
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Color label : selection
Hello. Similar need here. Sometimes I need to see all photos that have red and yellow label but no other. This typically happen when browsing photos, need to see all photos that have exact same label set (again, e.g. red and yellow but no other). (Blue sky UI: when right-clicking on photo in light table, a context menu that offers "show only images with label(s): red, yellow". Or a key shortcut.) My two cents. Le 03/01/2017 à 22:32, johannes hanika a écrit : hi, you can't easily select all images with /just/ red colour label attached to it. you'd explicitly need to exclude the green blue etc in the collection module (left panel somewhere, see the user manual link roman posted). if you do that often it may be worth creating a preset for this. hth jo -- Stéphane -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] sky viper
Le 08/01/2017 à 03:08, Michael a écrit : I got a Sky Viper and it has a wide angle lens. is there a lens correction module for it? If not what information do you need to create this module? Hello. Have you read http://www.darktable.org/2015/02/on-lens-detection-and-correction/ http://lensfun.sourceforge.net/calibration/ ? Also maybe http://wilson.bronger.org/calibration Regards. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
(documentation) Re: [darktable-user] Sidecar files being overwritten
Le 30/12/2016 à 05:27, Patrick Shanahan a écrit : if you are going to use a tool, you should learn about the tool the documentation is very good. Patrick is right, it's in the documentation. 2.2.7. Sidecar files | user manual | darktable <https://www.darktable.org/usermanual/ch02s02s07.html.php> https://www.darktable.org/usermanual/ch02s02s07.html.php Once an image has been imported into darktable the database entries take precedence over the XMP file. Subsequent changes to the XMP file by any other software are not visible to darktable – any changes get overwritten the next time darktable synchronizes the file. This behavior can be changed in the preferences dialog (see Section 8.2, “Core options” <https://www.darktable.org/usermanual/ch08s02.html.php>). On request darktable looks for updated XMP files at startup and offers a choice whether to update the database or overwrite the XMP file. 8.2. Core options | user manual | darktable <https://www.darktable.org/usermanual/ch08s02.html.php> https://www.darktable.org/usermanual/ch08s02.html.php look for updated xmp files on startup look for updated xmp files on startup Check file modification times of all XMP files on startup to find out if any got updated in the meantime by some other software. If updated XMP files are found a menu opens for the user to decide which of the XMP files to be reloaded – replacing darktable's database entries by the XMP file contents – and which of the XMP files to be overwritten by darktable's database. Activating this option also causes darktable to check for text sidecar files that have been added after import time – see option “overlay txt sidecar over zoomed images” in Section 8.1, “GUI options” <https://www.darktable.org/usermanual/ch08.html.php#gui_options> (default off). -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] sky viper
Keystone, okay. Not sure what you mean overall. Have you tried crop module and the keystone feature? http://www.darktable.org/usermanual/ch03s04.html.php#basic_group Apparently 2.2 has even better: http://www.darktable.org/2016/03/a-new-module-for-automatic-perspective-correction/ Le 08/01/2017 à 13:55, Michael a écrit : OH. it is just a matter of the keystone. That's cool. I always keystone my images! On Sun, Jan 8, 2017 at 2:03 AM, Stéphane Gourichon <stephane_darkta...@gourichon.org <mailto:stephane_darkta...@gourichon.org>> wrote: Le 08/01/2017 à 03:08, Michael a écrit : I got a Sky Viper and it has a wide angle lens. is there a lens correction module for it? If not what information do you need to create this module? Hello. Have you read http://www.darktable.org/2015/02/on-lens-detection-and-correction/ <http://www.darktable.org/2015/02/on-lens-detection-and-correction/> http://lensfun.sourceforge.net/calibration/ <http://lensfun.sourceforge.net/calibration/> ? Also maybe http://wilson.bronger.org/calibration <http://wilson.bronger.org/calibration> Regards. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org <mailto:darktable-user%2bunsubscr...@lists.darktable.org> -- :-)~MIKE~(-: darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] zooming in light table mode
Le 26/12/2016 à 21:04, Jean-Luc CECCOLI a écrit : In fact, the best is to keep shift depressed while releasing Z, else it may not work. Indeed, this is what makes the difference. But again, this is a continued discussion about a hack. As Tobias pointed out, there is a real intended sticky preview feature. It has to be better publicized. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] zooming in light table mode
Le 25/12/2016 à 21:22, darkta...@911networks.com a écrit : In the Z view, press the shift key, release the shift key and now you can use your left arrow for the previous image or right arrow to the next image while still in the 'Z mode'. Shift key? I don't see any effect of any shift key here (darktable 2.0.3 on Ubuntu). What works here is to keep Ctrl-Z pressed. Then left or right arrow work with or without shift, mouse wheel too. Ratings work with the mouse, not with the keyboard (French keyboard here, requires shift to be pressed to enter numbers.) I believe that in older versions, one mouse wheel action was enough to make the preview sticky. Le 25/12/2016 à 23:34, Tobias Ellinghaus a écrit : Alternatively just bind a key to the sticky preview in the preferences. Or even re-bind ctrl-z to that. No need for hacks. Oh, an actual feature existed and I wasn't the only one unaware ? I'm surprised to see that this was available for 2 years ( http://www.darktable.org/2014/12/released-darktable-1-6/ ). What I've been needing for years is a serial rate/reject UI. Looks like there's a valuable but slow growth feature here. Preview is not very different from setting lighttable to one-column and pressing tab to collapse all borders plus switch back. Actually the only extra thing I see there is a darker border around the picture. I've been using Ctrl-z for serial rate/reject, mainly because of the focus detection feature. Sticky preview will allow this plus rate with the keyboard without hack. Why do people hack ? Because some existing features being not visible enough, they explore and find working hacks. AFAIK sticky preview is not mentioned in user manual. Preview is shortly mentioned in introduction of Chapter 2. Lighttable https://www.darktable.org/usermanual/ch02.html.php . Shouldn't preview and sticky preview be somehow more salient? Congratulations anyway for the whole of darktable! -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)
Le 31/03/2017 à 18:16, dt-l...@stefan-klinger.de a écrit : In this thread we're just throwing more complexity (backups, undo in lighttable) at a problem that arose from DT's user interface. An application should protect a user from involuntarily causing damage, and in that respect DT is an adversary. I like the idea of keeping things simple, but can you tell a solution that does not increase complexity? IMNSHO the root cause for August's problem is that DT does too much when moving the mouse pointer. After clicking on an input field, the pointer has to stay there, otherwise editing is cancelled. This one has been an annoyance to me since day 1 of discovering darktable. It looks like darktable UI implements some sort of focus-follows-pointer behavior, which is uncommon these days. I do not know of any other gtk app that does this (or any recent app, what was the last one I saw behaving like this ... a Motif app maybe, 20 years ago?). Another example [1] is that the selection gets cleared when you move the pointer "incorrectly". You can observe this by trying to select and middle-click paste the path of an image from the image information pane. I've been bitten by DT's UI repeatedly. Honestly I'd prefer it to be a little bit more traditional. Looks like "focus follows mouse" is so traditional and forgotten that "new" users think it's something new? To DT developers: how comes that darktable UI has some sort of focus-follows-pointer behavior, while other gtk apps don't have that? -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)
Le 31/03/2017 à 18:38, Stéphane Gourichon a écrit : It looks like darktable UI implements some sort of focus-follows-pointer behavior, which is uncommon these days. I do not know of any other gtk app that does this (or any recent app, what was the last one I saw behaving like this ... a Motif app maybe, 20 years ago?). Thank you all for your examples of UI behavior. I was surprised no one mentioned side panels in lighttable, because it hit me many times. Then I tested (it hit me actually always on the same spot). I observed the others are not affected and on experimenting I finally figured out what happens. TL;DR: drop-downs steal focus and that's a pain on "export selected" module. Where ? lighttable, right panel, module "export selected" How to reproduce : * open lighttable, move mouse to right panel, expand "export selected" * click on export path textbox (between "target storage" and "on conflict"). * type some characters, they appear * move mouse pointer away * type some more characters Expected : more characters appear Observed : as soon as the pointer is moved away, textbox is no longer focused, no characters are inserted On closer analysis it appears that this happens only when the move is moved up or down, not when it leaves the textbox sideways. It appears that the real cause is not the mouse pointer exiting the textbox, but entering the drop-downs above and below. It's not that the mouse leave the textbox, it's that entering a dropdown steals focus. This explains why it does not happen on other modules, like "collect images", "metadata editor", "tagging", "geotagging" : they have no drop-downs above or below. Nevertheless, IHMO focus is not expected to be stolen away from textbox when move is moved away. Question: Why do drop-downs steal focus? Do they have a good reason? Would a "click to focus" be enough? -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Reconcile between library and xmp files (Re: [darktable-user] Question regarding sidecar files)
Le 2018-10-10 à 15:08, Willy Williams a écrit : I have three laptops on which Darktable is installed; two Windows 10 and one Ubuntu Linux. I generally sync the two Windows computers' photos folders, including JPEGs, RAW files and XMP sidecar files. I've begun to wonder if I'm shooting myself in the foot by doing so. The question is this - are the sidecar files closely tied to an internal Darktable database on the computer where the work was done? Am I making the dog's breakfast of things by syncing files and in doing so, inadvertently getting the sidecar files out of sync with the unique database associated with each computer? I think it should go without any problem. I would probably make sure darktable or the sync program is fully closed before running the other, just in case. What sync program do you use ? ## Closely tied ? No fear, darktable has a sane model and reconcile capabilities Darktable maintains a copy of the data in its library from the XMP files to allow finding pictures from the criteria in the XMP without re-reading all the XMP. Besides, darktable updates XMP files whenever you end an edit (switching to another image, or switching from dark room back to light table), so they are up-to-date with respect to the library which can be regarded as a cache. Still, darktable notices when XMP files are newer. I've seen darktable ask me a number of times whether to import new information from the XMP files. On virtually all occurrences, I clicked on "check all" (or similar) and confirmed because XMP were indeed newer. You may have a similar experience. I've seen no important ill-effect. Still you might be interested in a similar case, read on. ## One solution to avoid any sync issue Actually, my collection is so big that most of it is not mounted at the time I run darktable. It is split among several hard drives. And even part of it is mounted, the path to the storage change with time. For example, a disk is sometimes mounted via USB and sometimes via network, thus the mount point are different. As a result, the per-image information in darktable library is full of stale/unsynced copies from various mount points. This is actually not much of a problem. It mostly causes any view of the library to show duplicate entries and lots of skulls in lighttable. Anyway, since the per-image information in darktable library is actually useless to me, for about a year I've run darktable with --library :memory: option. This way, per-image information in darktable library is empty at each start. I can't search per album of whatever but I don't care, I just open darktable with the directory I'm interested in as argument. No duplicate, no skulls, only the directory I'm working on. This way, darktable never asks me about which version to keep (because the "memory" library is just empty so never conflicting), and things go smooth. Here is the executable script sitting in my ~/bin/darktable : #!/bin/bash exec /usr/bin/darktable --library :memory: "$@" Open to any comment, observation, similar experience or other solutions. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Sliders move on mouseover in 2.4.4
Hello. Ubuntu 18.04 here, no such problem. Can you create a new fresh account on the same machine and test darktable there ? This would help to see if machine configuration or user configuration causes this. Le 2018-10-12 à 19:10, Andreas Mueller a écrit : Hey all. Since a couple of days ago I have a really weird behavior in darkroom: Any mouseover for any slider moves the slider to the cursor. That basically makes darktable completely unusable because most modules have multiple sliders and it's basically impossible to not mouseover over multiple of them. I upgraded to 2.4.4 but that didn't help. I'm wondering if it's something that's wrong with my gnome configuration or something like that? I'm on DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS" and I don't have issues in any other applications, but I also haven't found anyone else having the same issue. Thanks for your help, Andy darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Re: Cannot read Nikon Z7 RAW Files
I sometimes experiences this on some .NEF files from a Nikon D5200 on Ubuntu 18.04 (happened on previous versions of Ubuntu, like 16.04). I'm not sure about the actual impact on processing. Cheers. -- Stéphane Le 17/10/2018 à 01.10, dba a écrit : FYI I uploaded a raw sample to https://raw.pixls.us/ and I'm running DT version 2.4.4 on RHEL workstation 7.5 On 10/16/2018 04:36 PM, dba wrote: All; I have a new Nikon Z7, I did a few test shots and opened the uploaded images (.NEF files) in darktable, I can see the image previews but when I click on an image to edit it I get this error: failed to read camera white balance information from 'DSC_001.NEF'! Any ideas on how to fix this? Thanks in advance darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] JPEG quality idea: default to use quantization table from JPEG original when applicable.
Hi everyone, # Context Recently on this mailing list a user was surprised to import JPEG in darktable then export them and see a huge difference in file weight (byte count). This violates the principle of least surprise, also known as https://en.wikipedia.org/wiki/Principle_of_least_astonishment # Idea in one sentence Applying the principle of least surprise invites me to suggest an idea: defaulting to roughly same image file weight. # Idea, with details So, how about implementing, like GIMP does, an option like this: [✔] Use quality settings from original image (when available) I rarely work on JPEG source, preferring RAW except on very specific cases, but it makes sense and indeed I would appreciate it. Here is a snippet from Gimp documentation https://docs.gimp.org/2.4/en/gimp-images-out.html#id2561830 : Use quality settings from original image If a particular quality setting (or “quantization table” ) was attached to the image when it was loaded, then this option allows you to use them instead of the standard ones. If you have only made a few changes to the image, then re-using the same quality setting will give you almost the same quality and file size as the original image. This will minimize the losses caused by the quantization step, compared to what would happen if you used different quality setting. If the quality setting found in the original file are not better than your default quality settings, then the option “Use quality settings from original image” will be available but not enabled. This ensures that you always get at least the minimum quality specified in your defaults. If you did not make major changes to the image and you want to save it using the same quality as the original, then you can do it by enabling this option. # Use the source Luke I might consider implementing it some day. I have already some other ideas for darktable that I could not find time to implement so far. # Feedback welcome **Knowing what people on this mailing-list think of such a feature is interesting.** Thank you for your feedback. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Rename XMP and fix reference inside XMP (Re: [darktable-user] Batch renaming software?)
Le 09/11/2018 à 23.49, Bernhard a écrit : Anton Aylward schrieb am 09.11.18 um 16:42: How i can rename xmp-files? with sed? You can't on the face of it. Sed is a file CONTENT editor. the best you can do is 'save-as'. It is a completely inappropriate tool for renaming. not really since if you rename a file already imported to dt you have to rename the xmp, too. Thing is that the xmp also *contains* the filename of the RAW and therefore the *content* of the xmp[1] must also be changed. The script I mentioned in another reply calls exiftool. I have also written a script that takes care of : * finding matching xmp file, * the xmp renaming to match the file it refers to, * *and* adjust inside the XMP the reference to original image file name, to match the new original file name. It also works even when called after-the-fact, when files have been mass-renamed and moved around in other directories, when xmp files have broken references. It relies on the XML file having the common part of the filename (like DSC_1234, aaa_2102, etc). If people show interest, I might clean that up and publish. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Batch renaming software?
Hello.
## Batch rename
I work with Linux and use ExifTool
<https://www.sno.phy.queensu.ca/~phil/exiftool/> (
https://www.sno.phy.queensu.ca/~phil/exiftool/ ) to rename all image
files, as in the example below :
exiftool -v -recurse '-FileName<${DateTimeOriginal}_%c_%-8f.%e' -d
%Y-%m-%d_%H.%M.%S .JPG .NEF
(Actually I've been using for years a script that renames files
according to EXIF info, and directories according to ranges of
timestamps, recursively. It's invaluable to me.)
The %c provides a way to guarantee no overwrite of any file: if
destination exists, a number is added to make file unique and not
overwrite any other file.
Alternatives are
* jhead <http://www.sentex.net/~mwandel/jhead/>
http://www.sentex.net/~mwandel/jhead/ ,
* exif <https://libexif.github.io/> https://libexif.github.io/,
* exiv2 <http://www.exiv2.org/> http://www.exiv2.org/ .
## Exposure compensation, bracketing
Can you elaborate your specific need that connects exposure-compensation
with autobracketing?
Here's an example:
exiftool -v -recurse
'-FileName<${DateTimeOriginal}_EC${ExposureCompensation}_%-c_%-8f.%e' -d
'%Y-%m-%d_%H.%M.%S' /tmp/somefile.nef
/tmp/somefile.nef
Setting new values from /tmp/somefile.nef
'/tmp/somefile.nef' --> '/tmp/2016-09-25_15.46.20_EC0__somefile.nef'
1 image files updated
Hope this helps.
Le 09/11/2018 à 02.21, August Schwerdfeger a écrit :
Can anybody recommend any good batch-renaming packages? I am
specifically looking to replace a homebrew Python script that uses
exposure-compensation metadata to identify sets of photos taken using
autobracketing (preferably with something I can invoke from within
Darktable).
--
Stéphane Gourichon
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Confusion About Nikon D850 RAW Formats
It may make sense after all. Geeqie (most certainly) and Nikon (very probably) report the definition of the JPEG file embedded in the RAW, which is the actual output of the Nikon processing algorithm. This would be similar to what I observe on the D5200, where the RAW and JPEG have different definitions (sidecar JPEG and embedded JPEG are both 6000x4000). Viewing both images and looking for possible crop and/or resize allows to actually notice the lens correction processing by Nikon. The point might have been to crop the picture so that most of the time, we have both 1:1 pixel coverage in the center while avoiding black areas on the side and corners due to lens correction. Using ufraw-batch --embedded to extract the embedded JPG from a D5200 RAW file indeed produces a 6000x4000 JPEG. Interestingly, darktable report the NEF is 6016x4016 while ufraw reports 6078x4058. This is becoming stranger. Anyway, D5200 has only one RAW definition. Perhaps the embedded JPEG size is really much smaller when using reduced RAWs, because, you know, the point is the camera user asked to save storage space and, since they have the raw file they're supposed to have means to regenerate a JPEG from that. Can you try the commands below for each raw and sidecar-jpeg files? identify mypicture.JPG ufraw-batch --embedded mypicture.NEF ; identify mypicture.embedded.jpg ufraw-batch --out-type=jpg --output=mypicture.ufrawprocessed.jpg mypicture.NEF ; identify mypicture.ufrawprocessed.jpg Le 12/01/2019 à 23.58, Bernhard a écrit : it looks like the RAW files published here https://raw.pixls.us/ show the same deviation - and the exifdata show the same values like darktable. I still do not understand why Geeqie and Nikon report other numbers ... Bernhard schrieb am 11.01.19 um 14:27: Nikon enables the use of RAW files of different sizes in the D850. According to the specifications in the manual, the formats are defined as follows: L 8256 × 5504 M 6192 × 4128 S 4128 × 2752 (these figures are also shown in the camera menu) darktable tells me: L 8288 x 5520 M 7104 x 4728 S 6216 x 4136 While the deviations for size L are still small (we had a discussion about them in the past), they are very significant for M and L - according to Nikon a file of size S 11.3MP, while darktable assumes over 25MP. Geeqie again shows the Nikon numbers. Exiftool shows the darktable numbers. A jpg or tiff file exported from darktable shows the darktable numbers in xnview. What is going on here? -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Using a cardbox with a hole to create real black Re: [darktable-user] Determining the base curve - how can I create real black?
Le 19/01/2019 à 22.21, jys a écrit : On Sat, Jan 19, 2019, at 12:55, Bernhard wrote: If I expose a bit darker (e.g. by reducing the flash output), then white becomes too dark (<255) without the lowest values moving significantly closer to black (=0). Exposing darker by dimming the flash probably isn't what you want. Maybe try stopping down the lens for the desired black point, and then increasing flash power if needed for the white? Even then, that setup may simply not be able to create the needed range. You could try pointing the camera so that one edge of the frame shows the edge of the table and a truly dark space beyond it. The best way to keep light spill off of the "black" area is for there to be nothing there for light to hit. ;) A cheap and easy way to get an a good dark region in a scene is to take an archive cardboard box with one hole. I can't find a reference now so I write here my own analysis of why it works so well. The object needed Here's a random example of a cardboard box with a hole : https://www.amazon.co.uk/32-Archive-Storage-A4-8-5-Cardboard-Archivio/dp/B079Y1RVFP The hole is simply intended to ease drawing the box out of a shelf where all boxes make a flat surface without any option to grip the box. Application to your setup Ensure that the hole is visible somewhere in the scene from the camera. The RGB data provided by the sensor on the location of the hole is a better black that most easily producible black pixels. In practice, since we want the box to be not too big, it is best if it is physically closed to the camera. Which is probably okay in you setup because you already adjust focus very close to the camera (so that the edge on the screen table is blurred). In your example you would put the box so that the hole is visible on the rightmost quarter of the image (where bright white already fades). Why it works The reason why it works is related to solid angles. Most surfaces are locally flat and so a point on a surface receives light from roughly half of all the directions, which makes a solid angle of 2 pi steradians <https://en.wikipedia.org/wiki/Steradian> (vs 4 pi steradians for the full sphere). From a point inside the box, direct light comes only from the hole. (Indirect light is negligible if the inside of the box is painted black, but even with unpainted cardboard the result is surprisingly good.) Viewed from the point inside, that hole is a light source covering up only a small solid angle. That small solid angle is a small _fraction_ of the half sphere from which the light comes when outside the box. Unless you send a light source directly to the box through the hole, that fraction directly affects the amount of light received on that point. Back to photograph's point of view, from outside the box, assuming the edge of the hole is focused enough to not blur the measurement, measured RGB values on the sensor, on the area looking at the hole, are multiplied by that small fraction. Hence, cheap, easy, good black. I'd be glad to learn how well it worked. -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Permission denied? But all seems to be working
Hello, From which shell script does this message come? Running this command may provides hints: strace -f -e trace=execve darktable Le 16/01/2019 à 09.20, Johann Spies a écrit : When I start darktable from the commandline I get /$ /usr/bin/darktable sh: 1: /home/js/.config/darktable: Permission denied/ but darktable seems to work without a problem As far as I can see everything in /.config/darktable/ is owned by the user (js) and permissions seems to be OK. From which shell script does this message come? -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Ubuntu 18.04->18.10 upgrade, NVidia?
Hello, I did a similar move. More precisely, I installed Xubuntu 18.10 alongside Xubuntu 18.04 on my PC, to keep ability to continue using current version. I have not noticed any issue with darktable itself. What I noticed, though, are X stability problems. Consequences are X session lost with all unsaved information lost, too. This can lose some work in darktable and other programs. These problems might be a consequence of using multiple monitors, a situation perhaps not as well tested as it should be, yet somehow common I guess among darktable users? For example, any time I suspend the laptop while external screens are used, when I resume without external screen plugged in, X crashes. I observed those stability problems with open-source nouveau driver as well as with closed-source nvidia driver. I'd be happy to hear about whether it works for you. @Coding Dave, what's your hardware? Mine is laptop Asus n551jk, 16GB RAM, video NVIDIA Corporation GM107M [GeForce GTX 850M] on Intel chipset (Optimus blablah hardware setup https://en.wikipedia.org/wiki/Nvidia_Optimus ). Cheers! Le 04/12/2018 à 22.49, Coding Dave a écrit : All good on my side, may it be 2.4 or current master. I dont experience any nvidia related issues. Am Di., 4. Dez. 2018 um 22:36 Uhr schrieb KOVÁCS István mailto:k...@kovacs-telekes.org>>: Hi, I'd like to ask whether those who have upgraded from Ubuntu 18.04 to 18.10 and use Nvidia cards have experienced any issues. I'm considering an update. Thanks, Kofa darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org <mailto:darktable-user%2bunsubscr...@lists.darktable.org> darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] DT on iMac with Mojave: no openCL
Le 02/12/2018 à 12.15, Volker Lenhardt a écrit : macspinne:~ volker$ /Applications/darktable.app/Contents/MacOS/darktable The output: (process:501): GLib-GObject-CRITICAL **: 11:25:06.904: g_object_set: assertion 'G_IS_OBJECT (object)' failed (darktable-bin:501): GLib-GObject-WARNING **: 11:25:07.665: invalid cast from 'GtkMenuBar' to 'GtkWindow' (darktable-bin:501): Gtk-CRITICAL **: 11:25:07.665: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed After closing DT: (darktable-bin:501): GLib-GObject-CRITICAL **: 11:26:44.700: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Are these errors relevant within the Apple environment? Probably not. I see similar errors when running other gtk apps from the command line on Ubuntu, even when they appear to work perfectly. When I start DT with the "-d opencl" option these errors are still there. But all output concerning openCL shows no errors. If requested I can post the lines. Here is a sample from my "darktable -d opencl output: 0.301195 [opencl_init] kernel loading time: 0.0895 0.301202 [opencl_init] OpenCL successfully initialized. 0.301211 [opencl_init] here are the internal numbers and names of OpenCL devices available to darktable: 0.301215 [opencl_init] 0 'GeForce GTX 850M' 0.301221 [opencl_init] FINALLY: opencl is AVAILABLE on this system. 0.301225 [opencl_init] initial status of opencl enabled flag is ON. 0.301709 [opencl_create_kernel] successfully loaded kernel `blendop_mask_Lab' (0) for device 0 0.301720 [opencl_create_kernel] successfully loaded kernel `blendop_mask_RAW' (1) for device 0 Cheers! -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] "Inconsistent Output" Message
Thanks Ulrich for this explanation. This clarifies and I see now two clearer issues: * 1 this message is unclear and conveys a more alarming message than needed. * 2 the user does not know that changing anything triggers a re-render without any bad consequence * 3 changing anything feels like a workaround. The user should have an option to just re-render. I see two ways to fix these issues : * I guess the developers have considered fixing the issue (increasing the timeout ? Retrying the computation ?) and not done it for good reasons. * A simpler way:changing the wording. Perhaps something like: "Rendering timed out. You can continue adjusting parameters or [Retry]." with [Retry] being a clickable button that just requests another render without actually changing any parameter. This way, the user is not needlessly alarmed (fixing issue 1) and know they can just continue adjusting I might be stating the obvious, or not, since choosing good words (towards a user that is not a developer) is not that obvious and sometimes overlooked. In case it's useful I'm happy to add my two cents. Cheers ! -- Stéphane Le 09/12/2018 à 19.46, Ulrich Pegelow a écrit : Am 09.12.18 um 08:59 schrieb Stéphane Gourichon: My guess is a memory corruption error in some part of darktable. Of course it would be nice if somehow could trace this. (I'm willing to, but currently not using darktable much, and quite busy with other projects.) Well, no. The error message appears when darktable is not able to synchronize the two pixelpipes in darkroom mode: the preview one for the navigation window and the "full" one for the center view. Both pixelpipes normally run asynchronously as separate processes. Some of darktable's modules require a synchronization: the full pixelpipe needs to wait at certain points until the preview pixelpipe produces the needed data. Without that missing data the module in the full pixelpipe would produce wrong results, the output of the two pixelpipes would no longer be consistent. In some cases synchronization fails, e.g. when the full pixelpipes needs to wait too long and a pre-defined timeout value is exceeded (config variable pixelpipe_synchronization_timeout). If that happens the above warning message is displayed. However, this is of no big concern. Typically with the next processing step all is good again. Any zooming in or out, panning, (de-)activating of modules or any value change is sufficient. Ulrich -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] Wish: darktable with viewing screen and control screen
Le 07/12/2018 à 17.08, Anton Aylward a écrit : IF AND ONLY IF you want more screen real estate I' do recommend a one-screen-at-a-time approach. A 27-inch screen for viewing and side 17-inch screen for controls is very nice to work with. I can do that with GIMP. I'm just sad that DT doesn't have the ability to 'tear off' the controls and move them to a side screen. Thanks Anton for sharing that idea! *Hardware setup* I have a 27-inch screen optimized for color rendition and an ordinary 15-inch laptop barely calibrated. *Observation* Part of the color-optimized screen is covered with controls. Sure I can click small (too small) triangles to collapse panels or use Tab. And sometimes I do. *Wish* The idea naturally came to dedicate the big screen to the picture, and the smaller screen to the controls. I sometimes use Gimp and to that. *Implementation* There are many ways to imagine such a separation in darktable. Toolbox windows with special properties etc may represent a significant refactoring effort, in code, in creating a new consistent and complete user experience, etc. Perhaps one approach may be much simpler: just extract the center image view of darktable to place it onto its own window, keep the rest as is (existing window without the extracted center view). What do you think? (I hope to clear time to contribute to darktable, perhaps in the coming year.) Cheers! -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Base Directory
Hi Stuart, I'm trying to change the base directory, Thank you for your message. Can you be more specific about the topic you raise? What do you call base directory? A root directory where all your photos are? The directory where darktable stores its library and settings? A directory where darktable exports? Something else? I'm trying to change the base directory, but it's not saving where I want it to What did you do exactly to change the base directory? I'm trying to change the base directory, but it's not saving where I want it to (on a different HDD within the same computer). What is the proper way to write it out? To write out where? It's difficult to answer questions when we don't know what you are talking about. The folder I want to use drag-and-drops this: file:///HDD/Photos which creates a new folder in my HOME directory. Reading your sentences I guess there is a train of thought, but as written they are too concise to make sense of them. Here is a reasonably short and to-the-point source of hints: https://www.caktusgroup.com/blog/2017/02/15/how-to-write-a-bug-report/ Also, consider starting with one or two sentences about what is unsatisfying about the default situation which supposedly would be fixed by changing the "base directory". This is to detect if we have a https://en.wikipedia.org/wiki/XY_problem here. Cheers! -- Stéphane Gourichon https://fidergo.fr/ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] "Inconsistent Output" Message
Le 07/12/2018 à 18.00, David Vincent-Jones a écrit : I occasionally get the message 'Inconsistent Output' on my screen ... most often when I am going through a screen zoom with the mouse wheel. Apparently there is no damage done. Anybody else seeing this? darktable 2.5.0+979~g22ab1bc66 I have seen such a message from time to time. I think if was on darktable shipped with Ubuntu 18.04 (2.4.2). It might also be when I zoom and unzoom a lot. Experimenting would confirm that. Sometimes no other effect was observed. Sometimes, one step of the pipeline was corrupted, like the output of a bilateral filter had correct luma but shifted chroma (for example, shifted by roughly one third of the image width). When it happened once, it tends to happen again in the same session. A workaround is to close and reopen darktable. Since the workaround is so easy, and every time it happened it was not time for me to investigate code, I did not take note of details. My guess is a memory corruption error in some part of darktable. Of course it would be nice if somehow could trace this. (I'm willing to, but currently not using darktable much, and quite busy with other projects.) My two cents! -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Strange color noise
Hi Vidar, Were the suggested solutions satisfactory in fixing your problem? Cheers, -- Stéphane Le 10/03/2019 à 19.25, Timur Irikovich Davletshin a écrit : On Sun, 2019-03-10 at 19:07 +0100, Matthieu Moy wrote: - Original Message - From: "Vidar Hoel" (Please don't post images as attachments, post a link within your message to an image hosted somewhere else) White hair, spots and whiskers seems to get a touch of red, green and blue. I tried different modules in darktable, without any success of removing this "noise(?)" This looks a lot like color artefacts due to bad demosaicing. Did you try using the amaze algorithm, or vng4? Usually amaze is the best (but slow), and VNG4 eliminates more color artefacts at the cost of a slightly softer image. That is demosaicing artifacts. Try VNG4 or, if you're not happy with softer results, change "match greens" in demosaicing module settings to "local average". Amaze probably will do better job, but it depends. Timur. darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] Restore color balance on old paper photos
Hello everyone, Has anyone experience about restoring faded color photographs from positive print, using darktable? There is high-expertise information here: https://photo.stackexchange.com/a/22727/34215 ... which also implies lot of work and manual adjustments. Knowing that prints are based on subtractive color synthesis, it seems natural to model the problem as if some of the inks were linearly (or even non-linearly) faded. But RGB being additive, common "multiply" operation (e.g. "channel mixer" module) doesn't fit this model. With an "add" technically it would do, but it would be practically too awkward to adjust both "multiply" and "add" sliders on each change (see below for what I've found). What does darktable provide as options? I have tried the following darktable modules : * Color balance (interesting how a negative "lift" answer the "multiply" + "add" issue mentioned above, see effect on histogram). * Color correction (cf. https://www.darktable.org/2012/03/color-correction/). I tried it and it is IMHO unsuitable. * Color zones (unsuitable IMHO). * Color mapping. The best result I had so far involves approximate manual steps to get to a point where the "color mapping" module can pick up and nicely do the bulk of the work. Method * In dartkable open the faded image. * Open "levels" module, click "auto" then adjust the black point to avoid too black shadows. * In "color balance" perform manual approximate correction, mostly using negative lift sometimes combined with gamma. * The important criteria of the previous two steps are (1) get an overall correct luminance (2) correct the strongest aspects of the color bias, even if the result is not fully satisfying. For example, get skin tones that mostly look like skin, sky that mostly looks blue, etc. Show image side-by-side with a modern photograph to get a comparison point. * The important step: follow https://www.darktable.org/2013/04/color-mapping/ using as source a modern photograph with good color balance that features the same elements (in my case: blue sky, wood, skin, foliage). Worry that it won't work. Adjust "color dominance" and suddenly get a decent (possibly good) result. Results This method worked rather well, with moderate manual work and produces results resembling the modern photograph used as color reference (which is the point of the "color mapping" module). Obviously it's not the intended use case for the "color mapping" module. Interestingly, the "color dominance" parameter appears to have some "threshold effects": from 0 to 100%, result starts awful (color casts applied to wrong areas), does not change at all for some ranges, and suddenly changes to something rather nice, then back to something unacceptable and dramatically different near 100%, staying at that when reaching 100%. Based on https://www.darktable.org/2013/04/color-mapping/ I would expect monotonous change and the more relevant results happening with low values. Perhaps this behavior comes from a too approximate use of the "color balance" module and would theoretically disappear if that step was done "perfectly"? Limits The limits of the approach are that it has some "apply whatever color" (from modern photograph) rather than "restore original image colors" flavor. Also, many faded photos have areas less faded. Most of them near the edges, sometimes spots anywhere in the picture. These remain visible on end result as blobs of strong color change. Others directions to explore? Yes, doing once, applying on many. It may be interesting to use the original vs processed image to calibrate a simple (non-linear but monotone) model of ink fade. Results may be expressed as parameters for a "tone curve" module, or even as 3 instances of "base curve" operating on R G and B (as shown fully manually on https://www.youtube.com/watch?v=RQXbmC_v2d4 , you should probably mute the sound). The resulting module parameters could be applied to other photos from the same batch and get decent rather good color correction without more work. Obviously it would get as biased as the color difference between the photograph used for calibration and the modern source photograph used as color reference, which may or not be a problem, depending on the goal. In the meantime, I could get some correct results by performing the method on one photo and copy-pasting the "color mapping" module on other photos with mostly the same subject. On others photos, it still kind of works on some images. At least it can be tried to instantly get something on n photos at the cost of one copy-paste, letting me disabling it only on those photographs where it is not
Re: [darktable-user] Leaving a module to conplete an operation?
Most modules get their effect applied continuously as you set the parameters, they don't need you to leave them. Can you provide examples of modules that actually need you to leave them to finalize the operation ? Regarding "crop and rotate", to finalize a crop I double-click inside the cropped area. "Folding" the module by clicking on its name in the right panel also works. It kind of makes sense to consider a crop has to be confirmed, although since that was coded, darktable gained "undo" ability with ctrl-z. From https://www.darktable.org/usermanual/en/modules.html : > When you are done and want to execute the crop, just give focus to another module or double-click into the image base. -- Stéphane Gourichon Le 08/12/2020 à 23.36, Terry Pinfold a écrit : Hi Doug, I know from the crop module that if you click at the top of the module near the name the crop event is finalised. I presume other modules will work the same. On Wed, 9 Dec 2020 at 09:16, DougC <mailto:d...@moosemail.net>> wrote: I am puzzled why the act of leaving a module is used as an event to activate or finalize the operation of the module. This seems like a strange user interface practice. Can someone enlighten me as to how and why it was adopted in darktable? darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org <mailto:darktable-user%2bunsubscr...@lists.darktable.org> -- Dr Terry Pinfold Cytometry & Histology Lab Manager Lecturer in Flow Cytometry University of Tasmania 17 Liverpool St, Hobart, 7000 Ph 6226 4846 or 0408 699053 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Scanning and EXIF information
Hi Greig, You basically want to replace some EXIF information present in the raw file. A number of people (including me) would strongly avoid ever modifying a raw file. These are full of dragons. First I would make a backup of the raw files for fear or any change triggering some wrong checksum somewhere and making other software (or the camera itself) refuse to do anything with it, claiming corruption. If any software claims to be able to perform changes, I would open a binary comparison of before/after to check what is the actual change. And keep the original raw files in a backup, indefinitely. The situation is somehow similar to a more common one : camera clock was off and you need right times in EXIF after the facts. The typical case being: at some events (wedding, etc) several cameras were used, clock mismatch as always by minutes hours or days, making a mess of timeline order. Fortunately the case of adjusting time is somehow covered by darktable, which copies EXIF DateTimeOriginal to the XMP sidecar, as XML attribute of rdf:Description XML element like this : exif:DateTimeOriginal="2020:11:11 09:54:44" . Changing this line in the XMP while darktable is not running was enough for me to get correct datetime in Darktable and exported EXIF data, yay! I checked the source code (current git master), and alas this is specific to DateTimeOriginal, darktable current code does not consider overriding EXIF metadata from the XMP file, other than DateTimeOriginal. Would your need happen to me, I would either just ignore the problem and live with it, or modify darktable source code to save that data to XMP and read it back, then offer a Pull Request to the darktable team. It may be possible to manually edit EXIF values in the database, but I'm not sure this can even work, and furthermore the current design of the database is fragile with respect to the locations of raw files. More concretely, whenever the raw file is moved, or happen to be stored on an external drive that is mounted at a different place, you would probably lose your customization. With the XMP sidecar, darktable would load it again in those cases. Addendum: to handle comfortably the "several cameras with random time offsets take pictures of same events over a time range" case, I wrote a year ago a script to automatically adjust batches of pictures. It saved the day several times for me and I am considering publishing it as open-source. Anyone who reads this (even years after) please consider telling me if you're interested. -- Stéphane Le 15/11/2020 à 02.55, Andrew Greig a écrit : Hi All, I shot and developed a roll of B+W film, and I will scan it using my Canon EOS 5D iv with the EF 100mm f2.8 Macro lens. As I was shooting the roll of film I maintained a notebook where I wrote down the settings, what is the best way to substitute the info in the resulting .CR2 files with the info from my notes? I am really looking forward to loading these into Darktable/Negadoctor. Thanks Andrew Greig darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] changing directory
ng lines : update film_rolls SET folder = replace( folder, 'new_unwnated_path_to_the_files', 'old_expected_path_to_the_files'); Be aware to replace the values between single quotes by the actual ones ! 5- execute the code But I still think acting directly on the drive letter is better and safer. Rgrds, J.-Luc darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org <mailto:darktable-user%2bunsubscr...@lists.darktable.org> darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org -- Stéphane Gourichon darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
