Re: [darktable-user] darktable-chart and missing colorin "standard color matrix"
On Fri, Jan 3, 2020, at 06:19, Patrick Shanahan wrote: > * Niccolo Rigacci [01-03-20 07:00]: > > > First of all I wonder why the dtstyle created by darktable-chart > > includes the module "input color profile". Shouldn't rather the > > input profile be added by me, if required? Probably to make sure the input profile being used with the applied style is the same one that was used to create the style in the first place, otherwise the results won't be valid. Did you create the style using a camera RAW file and its associated "standard" color matrix? If so, that's what you should be using the style on, and there should still be a "standard" matrix available at colorin. If not, then you need to alter the style so that the input profile being used is the same one as when creating the style (if it was a profile embedded in your input image, just remove the input color profile part of the style, and only use it with same type of files). > your problem may stem from version as many new features were introduced > and dt is now at 3.0 with development on 3.1+ ...or at least update to 2.6.3 patch level if you don't want to go 3.0 yet. -- jys darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] Pentax-D FA 24-70mm f/2.8 ED SDM WR not recognized using Ubuntu 19.10
From /var/lib/lensfun-updates/version_2/slr-pentax.xml Pentax HD Pentax-D FA 24-70mm f/2.8 ED SDM WR Pentax KAF3 1 I had this lens with Ubuntu 18.04 working already with a file in /.local/share/lensfun The old file doesn't work in Ubuntu 19.10 anymore, I mean it is not recognized automatically. It works when I assign the lens manually. The lens is shown 2 times in darktable. (HD Pentax vs. HD PENTAX and f2.8 vs f/2.8. In earlier discussion I've been told, that this shouldn't matter. I am very unsure, if this is true with Ubuntu-versions, because I got some lenses working with 18.04 adding a 2nd name with things like "/", With a Ricoh fixed lens (GR III), it was said, that the "mount" has to begin with a lowercase letter, which isn't the case here. My version is at /.local/share/lensfun Pentax HD PENTAX-D FA 24-70mm F2.8 ED SDM WR Pentax KAF3 1 [MakerNotes]0x0001 Lens Type : HD PENTAX-D FA 24-70mm F2.8 ED SDM WR exiv2 doesn't recognize the lens with Ubuntu 19.10, but I do not understand while it worked already with 18.04 Al darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] Export of a folder with the command line
How can I export a folder of images with dng / xmp files? So I mean all the image files of a folder and not only 1 image. Can this be done with a 1 line command? The files should be written in another directory. Quality 98 The size should be as it is, except it is a small image from an old camera or a lot cropped. The *minimal* size should be für 3:2 3840 (width) and 2560 (height) for landscape photos and in portrait mode, it should be 2:3 = 1707 (width) and 2560 (height). If the image is slower it should be upscaled, but larger images should *not* be downscaled. It should be not smaller. Since the crop is not done exactly 3:2 by dt when it is drawn with the mouse, I use 3843 x 2562 for upscaling in landscape mode and 1709 for portraits to be sure, that I do not have to upscale a 2nd time, when I need an exact value. For me a few pixles more are better than less. Al darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Migration of old XMP sidecar files to current dt version
Hi Manuel, I've come a long way since darktable 1.4 but never had such an issue changing from older to newer versions. Going the other way round will corrupt many things - a warning is issued with the release notes every time. That said - in spite of that compatiblity I often rework older images since I'm not happy what I had done years ago now ... So my only clue is that this is a temporary problem with 3.1 as this is unstable. -- regards Bernhard https://www.bilddateien.de Manuel Presnitz schrieb am 03.01.20 um 18:34: Hello altogether, I'm using darktable for some month now and I'm really impressed by its capabilities and I also like its interface. So, first of all thanks a lot for you years-long efforts! What I'm currently wondering is how should I handle different module versions in different darktable versions when archiving my editing history in xmp sidecar files?! To give an example where I stumbled upon this problem(?) recently: I edited some pictures with the current stable version (3.0.0), including the "basic adjustment" module. As I'm always curious to test new things, I also built the current dev version (3.1.0+289~gf788bfff3) and imported a copy of the dt-3.0-edited photos together with their 3.0-sidecar files. Upon doing that I get the message: "module 'basicadj' version mismatch: 2 != 1" on various pictures. So far I understand the message, as dt 3.0 wrote modversion="1" into the sidecar file and dt 3.1 has modversion="2" of the (redesigned) basic adjustment module. But I don't understand how I can work around that issue. The imported pictures simply lack the editing step of the basic adjustment module, which effectively altered the result. Is this only a dev version problem and final stable versions get conversion routines for older module versions? (Some modules have modversion as high a 6, so this phenomenon should've occured already multiple times) Or how do you archive your editing history? Just using old sidecar files with new dt versions seem not to guarantee the same (or at least a similar, neglecting implementation differences) final image. Do I have to document which dt version I used for which photos and keep that version as long as possible if I want to make changes to older pictures? Sorry if that's a frequent and/or silly question, but I could neither find a clue on the mailing list archive, nor the FAQ. However, I'm pretty sure I'm not the first one who is wondering about that point, so I's really appreciate your opinions or if you can give me a clue where to find information about migration of xmp files from older dt versions. Thanks a lot & best regards, Manuel. Just for completeness my current machine configuration: Arch Linux Intel Xeon E3-1535M v5 Nvidia Quadro M2000M, Driver 440.44 darktable 3.1.0+289~gf788bfff3 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
[darktable-user] Migration of old XMP sidecar files to current dt version
Hello altogether, I'm using darktable for some month now and I'm really impressed by its capabilities and I also like its interface. So, first of all thanks a lot for you years-long efforts! What I'm currently wondering is how should I handle different module versions in different darktable versions when archiving my editing history in xmp sidecar files?! To give an example where I stumbled upon this problem(?) recently: I edited some pictures with the current stable version (3.0.0), including the "basic adjustment" module. As I'm always curious to test new things, I also built the current dev version (3.1.0+289~gf788bfff3) and imported a copy of the dt-3.0-edited photos together with their 3.0-sidecar files. Upon doing that I get the message: "module 'basicadj' version mismatch: 2 != 1" on various pictures. So far I understand the message, as dt 3.0 wrote modversion="1" into the sidecar file and dt 3.1 has modversion="2" of the (redesigned) basic adjustment module. But I don't understand how I can work around that issue. The imported pictures simply lack the editing step of the basic adjustment module, which effectively altered the result. Is this only a dev version problem and final stable versions get conversion routines for older module versions? (Some modules have modversion as high a 6, so this phenomenon should've occured already multiple times) Or how do you archive your editing history? Just using old sidecar files with new dt versions seem not to guarantee the same (or at least a similar, neglecting implementation differences) final image. Do I have to document which dt version I used for which photos and keep that version as long as possible if I want to make changes to older pictures? Sorry if that's a frequent and/or silly question, but I could neither find a clue on the mailing list archive, nor the FAQ. However, I'm pretty sure I'm not the first one who is wondering about that point, so I's really appreciate your opinions or if you can give me a clue where to find information about migration of xmp files from older dt versions. Thanks a lot & best regards, Manuel. Just for completeness my current machine configuration: Arch Linux Intel Xeon E3-1535M v5 Nvidia Quadro M2000M, Driver 440.44 darktable 3.1.0+289~gf788bfff3 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] darktable-chart and missing colorin "standard color matrix"
* Niccolo Rigacci [01-03-20 07:00]: > Hello Darktable users! > > I'm playing with a ColorChecker and the darktable-chart program > to produce a good Darktable style to apply in my workflow. > > First of all I wonder why the dtstyle created by darktable-chart > includes the module "input color profile". Shouldn't rather the > input profile be added by me, if required? > > The second question is about that input color profile: it seems > invalid because whenever I apply the style I get the following > error message in the text console: > > [colorin] could not find requested profile `standard color matrix'! > > then I find that the sRGB colorin profile is applied indeed, > modifying badly the photo (too washed out!), so that I have to > remove it. > > Do I have a bug on my Darktable installation? What is that > "standard color matrix" profile? My environment is: > > * Darktable 2.6.0 > * GNU/Linux Debian 10.2 Buster your problem may stem from version as many new features were introduced and dt is now at 3.0 with development on 3.1+ -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Bug with mask opacity?
> Can you test https://github.com/darktable-org/darktable/pull/3969 Hi Pascal, I confirm that it works fine. Thanks for fixing it so quickly. Have a nice new year. Giulio darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] darktable-chart and missing colorin "standard color matrix"
Hello Darktable users! I'm playing with a ColorChecker and the darktable-chart program to produce a good Darktable style to apply in my workflow. First of all I wonder why the dtstyle created by darktable-chart includes the module "input color profile". Shouldn't rather the input profile be added by me, if required? The second question is about that input color profile: it seems invalid because whenever I apply the style I get the following error message in the text console: [colorin] could not find requested profile `standard color matrix'! then I find that the sRGB colorin profile is applied indeed, modifying badly the photo (too washed out!), so that I have to remove it. Do I have a bug on my Darktable installation? What is that "standard color matrix" profile? My environment is: * Darktable 2.6.0 * GNU/Linux Debian 10.2 Buster -- Niccolo Rigacci - http://www.rigacci.net/ Campi Bisenzio - Firenze - Italy Tel. Mobile: +39-327-5619352 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] Trouble with Retouch module
Hi I installed DT from a ppa yesterday and was over the moon, but today I needed the retouch module, and the selected tools, brush, circle and ellipse all appeared at a very large size and would not submit to attempts to resize.Any suggestionsGratefullyAndrew GreigSent from Samsung tablet. darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.or
[darktable-user] removing broken storage and zoomable lighttable
Please see: https://github.com/darktable-org/darktable/issues/4008 And feel free to comment. Thanks, -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Weird artifacts with color zones module in V3
I confirm that the color zones module easily produces artifacts. This happens especially on changes of the lightness curve. And obviously with "process mode = strong" you may get artifacts almost immediately. As far as I can see 2.6 has not been much different. In the old version everything has been processed as if "process mode = smooth" had been selected but even then you would usually see artifacts on close inspection. I think this needs some more care in the module. The root cause seems to be the granular properties of the intermediate mask in that module. Not uncommon if you select by hue which tends to have marked variations from pixel to pixel. And it's also logical that a change to the lightness curve triggers more problems. Lightness artifacts are easily seen, much more than small color inconsistencies. A possible solution could be to offer a blurring option for the mask (probably best done with a bilateral filter). That's something to consider for 3.2. Currently I suggest to use "process mode = smooth" in any case where you want to adjust lightness. Another suggestion is to not make a too narrow selection in the lightness curve (on hue basis). The new module version together with the range selecting color picker invites you to produce very narrow, specific peaks in the curves. But then you end up with a very granular mask. If you make the peak broader (as you probably did in 2.6) much of the artifacts are gone. Am 30.12.19 um 23:28 schrieb Giulio Roman: Hi, since upgrade to v3 I am struggling using the color zones module. With 2.6 I had to really push it to see artifacts. Now it seems much easier. I have a basic landscape picture with light blue sky and subtle clouds. I'm trying to increase the blues and darken them. If I use the defaults of the color zones module I see artifacts as soon as I move slightly downwards the lighness curve in the blues (after increasing saturation around the same hue values). If, instead, I choose the preset "black and white film", then move the whole saturation curve back to 0 (keeping the points scattered around the hue axis), and increase the saturation in the blues, I can then drop the lightness much more and get a better result. It basically seems that having more points scattered around the hue axis helps in not getting artifacts on the clouds. Has there been changes also in the module's inner functionality, or just in the UI? Or am I totally missing something? I don't remember if the "process mode = strong" was already present in 2.6, however changing it to "smooth" helps a little bit but does not solve the problem. It just blands the effect. I'm usually a person who welcomes changes, and even though I initially find something new difficult, I try until I succeed before judging negatively. But this time i'm having serious issues in using a module which was one of my default gotos before... Please someone shine a light on this :-) Thanks in advance Giulio darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
