Re: [darktable-dev] Visibility of stars
Great, thanks On Tue, Dec 17, 2019 at 1:29 PM Nicolas Auffray wrote: > The whole UI has been changed on 3.0 and visibility of stars is better. > Anyway, they come in a widget for thumbnails star so can't be changed by > CSS. > > > Le 17/12/2019 à 16:45, Julian Rickards a écrit : > > Is the visibility (colour) of the stars controlled in CSS in 3.0? > Currently, in 2.6.3, I find them a bit faint. > > If not, not a deal breaker, then just a request for 3.01. > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Visibility of stars
Is the visibility (colour) of the stars controlled in CSS in 3.0? Currently, in 2.6.3, I find them a bit faint. If not, not a deal breaker, then just a request for 3.01. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Export settings, not storing "on conflict" setting
Hi: I'm running 2.6.3, I haven't tried any of the dev versions so can someone check this for me please? When I create/edit an Export preset and set the "on conflict" to "overwrite", it doesn't save this setting but reverts to "create unique filename". Is this "reluctance" to save the "on conflict" to "overwrite" intentional? If it is a bug, can someone check 3.0 and see if it has been fixed? Sorry, just noticed this. Not critical, can be left for 3.0.1. Thanks, Jules ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] basic adjustments
My apologies On Mon, Nov 18, 2019 at 10:58 AM Aurélien Pierre wrote: > Forget about segfaults and crashes, our first priority is now to make > every native English speaker feel respected in his difference and identity, > offering fully differentiated support of every English dialect : en_GB, > en_AU, en_US, en_ZA, en_CA, en_NZ, en_FJ… > > Meanwhile, people speaking languages for which darktable is partially or > even not translated can die screaming, we are too busy fixing gr(e|a)ys. > Come back later (or preferably never). > > Next top-priority project : translating dt in signs language. The > chief-translator position is open, send your resumes now. > > Obligatory mention : > > "We are a dynamic team of motivated people trying to change the world one > step at a time. Join us to expand your horizons in an exciting opportunity > to face new challenges and give a new start to your carreer." > Le 18/11/2019 à 16:30, Richard Hobday a écrit : > > -- Tongue firmly in cheek -- > en-GB or en-US ? > That is the real question. > They are two very different languages, at present darktable seems to > assume they are the same! > > R. > > On 18/11/2019 14:36, Julian Rickards wrote: > > grAy is the American spelling and there's nothing wrong with that > (despite being a Canadian and using British spelling, LoL) but Timur is > correct, there should be consistency and, in addition to sticking to the > same spelling of gray/grey, I think that that the English version of the > documentation (and GUI) should be either all British or all American > English spelling, not just American for some and British for others. > > On Mon, Nov 18, 2019 at 8:29 AM Timur Irikovich Davletshin > mailto:timur.davlets...@gmail.com> > > wrote: > > Actually I agree. Darktable lacks of terminology unification across > modules. E.g. AFAIR there are around 6 different names for 18% gray. > In > some places it is "grey" but in others it is "gray". > > Timur. > > On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote: > > On 15.11.19 12:02, parafin wrote: > > > I think these numbers don't have units, so why do expect them to > > > mean > > > the same thing in different modules, even if we ignore the pipe > > > order? > > > > Because that's the most basic requirement of usability. That things > > named the same way act the same way and mean the same thing across > a > > single app – at the very least. > > > > > It's not promised anywhere in the documentation as far as I can > > > see. > > > > > > I went through the Photoshop & Lightroom docs and I can't find any > > promise in the entirety of them that slider ranges of things > sharing > > a > > name will match in range & effect. > > Yet they do. > > Go figure ... > > > > > > Beers, > > > > .mm > > > _ > > __ > > darktable developer mailing list > > to unsubscribe send a mail to > > darktable-dev+unsubscr...@lists.darktable.org > <mailto:darktable-dev%2bunsubscr...@lists.darktable.org> > > > > > > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > <mailto:darktable-dev%2bunsubscr...@lists.darktable.org> > > > > ___ > > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > > -- > http://lukecarville.jalbum.net > https://facebook.com/rlc.hobday > ___ > > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] import folder → file count
Perhaps: 200 RAW (200 JPG, ignored) On Mon, Nov 18, 2019 at 9:41 AM Timur Irikovich Davletshin < timur.davlets...@gmail.com> wrote: > Well, I agree it's not a big deal. But if one shoots (just as example) > raw+jpeg and then tries to import only raw files... — he will get > message of importing, let's say, not 200 raw files but 400. At least > once I was a bit confused — did I forget to click "ignore JPEGs"? So I > canceled import. But it turned out that I was correct. It was dt > reporting wrong number of raw files. > > Timur. > > On Mon, 2019-11-18 at 15:33 +0100, Christian wrote: > > Timur, > > > > I tested this and can't see an issue. > > > > DT is showing "Importing .. images" during Import and afterwards this > > message disappears, so depending on the number of files it's hardly > > to notice at all. > > > > So, first DT is importing the images and afterwards the duplicate > > filter is applied. > > > > christian > > > > > > > > Am 18.11.2019 um 10:59 schrieb Timur Irikovich Davletshin: > > > Another small issue I noticed. This time in folder import. > > > > > > Steps to reproduce: > > > > > > 1. Create folder with, let's say, DSC_.RAW and DSC_.JPG > > > 2. Choose import → folder... and select ignore JPG files in import > > > settings, press import button. > > > > > > Problem: > > > > > > Import status in left bottom corner shows 2 files but imports only > > > one. > > > If JPGs are not ignored, file count is correct. Looks like the part > > > of > > > code which counts files ignores import dialog settings. > > > > > _ > > __ > > darktable developer mailing list > > to unsubscribe send a mail to > > darktable-dev+unsubscr...@lists.darktable.org > > > > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] basic adjustments
grAy is the American spelling and there's nothing wrong with that (despite being a Canadian and using British spelling, LoL) but Timur is correct, there should be consistency and, in addition to sticking to the same spelling of gray/grey, I think that that the English version of the documentation (and GUI) should be either all British or all American English spelling, not just American for some and British for others. On Mon, Nov 18, 2019 at 8:29 AM Timur Irikovich Davletshin < timur.davlets...@gmail.com> wrote: > Actually I agree. Darktable lacks of terminology unification across > modules. E.g. AFAIR there are around 6 different names for 18% gray. In > some places it is "grey" but in others it is "gray". > > Timur. > > On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote: > > On 15.11.19 12:02, parafin wrote: > > > I think these numbers don't have units, so why do expect them to > > > mean > > > the same thing in different modules, even if we ignore the pipe > > > order? > > > > Because that's the most basic requirement of usability. That things > > named the same way act the same way and mean the same thing across a > > single app – at the very least. > > > > > It's not promised anywhere in the documentation as far as I can > > > see. > > > > > > I went through the Photoshop & Lightroom docs and I can't find any > > promise in the entirety of them that slider ranges of things sharing > > a > > name will match in range & effect. > > Yet they do. > > Go figure ... > > > > > > Beers, > > > > .mm > > _ > > __ > > darktable developer mailing list > > to unsubscribe send a mail to > > darktable-dev+unsubscr...@lists.darktable.org > > > > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Q: Store GPS location in RAW instead of XMP?
Yup, that'll explain my confusion. Thanks On Fri, Nov 15, 2019 at 5:28 PM jys wrote: > > > On Fri, Nov 15, 2019, at 12:35, Julian Rickards wrote: > > Does that suggest then that the GPS data is stored in the associated > > JPG? What if the user doesn't shoot JPG? What about other EXIF data, > > where is that stored? > > I think you're confusing two different things here. The original > question/answer was about geotagging *added within darktable*, not added by > the camera. For cameras which allow geotagging, that information will be in > the RAW file (but if you use darktable to change the geotagging in the > database, the RAW file will still have the old geotags, because > darktable_does_not_touch_RAW_files_ever). > > -- > jys > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Q: Store GPS location in RAW instead of XMP?
Does that suggest then that the GPS data is stored in the associated JPG? What if the user doesn't shoot JPG? What about other EXIF data, where is that stored? Just curious. On Fri, Nov 15, 2019 at 3:32 PM Aurélien Pierre wrote: > Hi, > > we never touch the raw files to avoid any risk of data corruption. There > exist precedents of exif edits permanently damaging raw files on saving, > possibly in DigiKam (you would have to ask Roman Lebedev about that, I > don't remember the specifics). > > Aurélien. > Le 15/11/2019 à 21:26, Christian a écrit : > > When a picture is geo-located (in the map view) the position is > stored in the XMP but not in the RAW file. > > Is there a reason for this behavior? > > The only way to get the RAW updated is an external > script which reads the xmp and calls exiftool > to set the gps tags in the raw file? > > christian > > ___ > > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] darktable 3.0.0rc0 released
Not quite sure how to interpret "entertaining". I was approaching this from a different point of view, one that we take here at my workplace. When a new model of a camera is released (OMD E-M5 Mk III for example), the manufacturer generally doesn't continue to produce any of the previous versions (the original or Mk 1 model or the Mk II model). Denoise is offered in 3 forms (not #1, #2 and #3) because they work differently, more differently than simply adding a drop down within one copy of this module and for that reason, the names of the denoise modules do not end in 1, 2 or 3 but with a descriptive word or two. The Tone Curve now offers RGB, Lab and XYZ as drop downs because they are similar enough to bundle together but if filmic2 operates much differently than filmic, this might be an argument to keep both "versions". However, if the intent of the developers is to have users use filmic2 instead of filmic, don't give them the option, just offer filmic2 as the only filmic. Another consideration might be: if it is unlikely that a user might want to use both filmic and filmic2, then again, don't give them the option. Just my 2¢, that's all. On Wed, Nov 6, 2019 at 12:19 PM Moritz Moeller wrote: > On 6.11.19 14:35, Julian Rickards wrote: > > From my perspective, filmic2 isn't appropriate. I work in the > > publication services section of an Ontario (Canada) government ministry > > and when we assign "2" to a publication, "1" is gone and no longer > > available. > > That's the most entertaining reasoning for naming something I've ever > read on a software mailing list. :D > > > If the original filmic is gone from this version, then I would just name > > the new one filmic. If the original filmic will also be available, just > > like the various denoise modules, this new filmic should have an > > additional descriptor such as filmic rgb. > > How about naming the old module 'filmic (deprecated)' in the UI and the > new one just 'filmic'. > Behind the scenes (XMP etc.) they can be called 'filmic' and 'filmic2'. > > > Beers, > > .mm > > > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] darktable 3.0.0rc0 released
>From my perspective, filmic2 isn't appropriate. I work in the publication services section of an Ontario (Canada) government ministry and when we assign "2" to a publication, "1" is gone and no longer available. If the original filmic is gone from this version, then I would just name the new one filmic. If the original filmic will also be available, just like the various denoise modules, this new filmic should have an additional descriptor such as filmic rgb. On Tue, Nov 5, 2019 at 6:21 PM Heiko Bauke wrote: > Hi, > > Am 05.11.19 um 23:59 schrieb jys: > > I think that would cause *endless* confusion... probably better to > > call the new one 'filmic2' or something. > > agree, "filmic2" is not bad. > > > Heiko > > -- > -- Number Crunch Blog @ https://www.numbercrunch.de > -- Cluster Computing @ https://www.clustercomputing.de > -- Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Drag-and-drop to change module order
Agreed On Fri, Nov 1, 2019 at 3:15 PM jys wrote: > > > On Fri, Nov 1, 2019, at 10:33, Julian Rickards wrote: > > My wishes and comments are GUI-only and related only to the Favourites > tab. > > > > There is another conversation tied into this one about re-ordering the > > modules in the PP list (the Active tab I suspect because it lists the > > modules used, and their PP order). > > > > I suppose that the two conversations should be split. > > Yes, these are completely different things, and it's important that they > don't become confused in the minds of users. Hopefully the OP was aware of > what they were doing, since they referenced a video where it was shown. > > -- > jys > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Drag-and-drop to change module order
My wishes and comments are GUI-only and related only to the Favourites tab. There is another conversation tied into this one about re-ordering the modules in the PP list (the Active tab I suspect because it lists the modules used, and their PP order). I suppose that the two conversations should be split. Mine (re-ordering in Favourites) is a feature request that happened after the closing of the features (I only proposed it because that is when I thought of it) and perhaps discussion about re-ordering Favourites modules should be shelved until 3.0 is out and feature requests can be considered again. On Fri, Nov 1, 2019 at 1:12 PM Bernhard wrote: > Until now I did not feel the need to change pp since the explanation > given seemed valid to me and I was happy with the results. > When I occasionally saw discussion about GUI improvement and module > order I always thought this is GUI only - which indeed would be a big > improvement for me. > Now everything seems to be different? > In my view there is a risk that the normal user deteriotes the result > more than it would help him - just a thought. > > -- > > regards > Bernhard > > https://www.bilddateien.de > > > > Julian Rickards schrieb am 01.11.19 um 16:11: > > In my opinion, re-ordering the modules in the favourites shouldn't be > > a problem with the pp order. In the same way that you may have written > > down, on paper, the modules you want to use, in the order you want to > > use them, re-ordering favourites in this way shouldn't be any > > different. However, I had recently proposed this as a feature request > > (but after the closure of the feature requests so I didn't expect it > > to be acted upon for 3.0) and it turns out that a couple of others had > > requested this before me (how long before me? I don't know). > > > > I don't want to make a big deal of this or start throwing flames back > > and forth, I just thought this might be useful. > > > > On Fri, Nov 1, 2019 at 11:03 AM David Vincent-Jones > > mailto:david...@gmail.com>> wrote: > > > > I think that I am relieved maybe ... hopefully I did not > > disturb the pp now I am confused ... I simply wanted to put > > the favorites in my logical processing order. > > > > David > > > > On 01.11.19 14:18, Patrick Shanahan wrote: > >> * Pascal Obry <mailto:pas...@obry.net> > [11-01-19 08:01]: > >>> David, > >>> > >>>> Shurely changing the order of the modules located in the > >>>> 'favorites' tab does not change the individual modules position in > >>>> the pixel-pipeline? that would be unthinkable! > >>> Of course it does! Re-ordering the iop is not for fun, it really > does > >>> change the pixel-pipe order. > >> then cryptomilk's reference should be corrected: > >>See > >> > https://www.darktable.org/usermanual/en/darkroom_concepts.html#pixelpipe > >> > >> as it indicated a static pixelpipe, and really allows unknowing > users > >> ample opportunity to "shoot themselves in their collective feet". > >> > >> also once changed there doesn't appear any option ot restore the > original > >> order to the pixelpipe. ??? > >> > >> tks, > > > > > > > ___ > > darktable developer mailing list to unsubscribe send a mail to > > darktable-dev+unsubscr...@lists.darktable.org > > <mailto:darktable-dev%2bunsubscr...@lists.darktable.org> > > > > > > > ___ > > darktable developer mailing list to unsubscribe send a mail to > > darktable-dev+unsubscr...@lists.darktable.org > > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Drag-and-drop to change module order
In my opinion, re-ordering the modules in the favourites shouldn't be a problem with the pp order. In the same way that you may have written down, on paper, the modules you want to use, in the order you want to use them, re-ordering favourites in this way shouldn't be any different. However, I had recently proposed this as a feature request (but after the closure of the feature requests so I didn't expect it to be acted upon for 3.0) and it turns out that a couple of others had requested this before me (how long before me? I don't know). I don't want to make a big deal of this or start throwing flames back and forth, I just thought this might be useful. On Fri, Nov 1, 2019 at 11:03 AM David Vincent-Jones wrote: > I think that I am relieved maybe ... hopefully I did not disturb the > pp now I am confused ... I simply wanted to put the favorites in my > logical processing order. > > David > > On 01.11.19 14:18, Patrick Shanahan wrote: > > * Pascal Obry [11-01-19 08:01]: > > David, > > > Shurely changing the order of the modules located in the > 'favorites' tab does not change the individual modules position in > the pixel-pipeline? that would be unthinkable! > > Of course it does! Re-ordering the iop is not for fun, it really does > change the pixel-pipe order. > > then cryptomilk's reference should be corrected: > See > https://www.darktable.org/usermanual/en/darkroom_concepts.html#pixelpipe > > as it indicated a static pixelpipe, and really allows unknowing users > ample opportunity to "shoot themselves in their collective feet". > > also once changed there doesn't appear any option ot restore the original > order to the pixelpipe. ??? > > tks, > > > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Drag-and-drop to change module order
I agree with David, re-ordering the modules in the Favourites tab should *not* affect the pixel-pipe order but I wonder if David and Pascal are thinking differently. As I understand it, Aurlien was re-ordering the modules in the "Pixel-pipe" tab, which of course affected the pp order. However, some of us have been talking about asking that the modules in the Favourites tab be able to be re-ordered and this should be designed so as to not affect the pp order, in the same way that the order in which you apply the modules (i.e., History) does not affect the pp order. On Fri, Nov 1, 2019 at 7:56 AM Pascal Obry wrote: > David, > > > Shurely changing the order of the modules located in the > > 'favorites' tab does not change the individual modules position in > > the pixel-pipeline? that would be unthinkable! > > Of course it does! Re-ordering the iop is not for fun, it really does > change the pixel-pipe order. > > -- > 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 developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] (Future) Feature Request - Re-order Favourites Modules
Great, thanks! On Tue, Oct 29, 2019 at 9:57 AM Maurizio Paglia wrote: > Hi Jules, > I am asking for this feature since more or less a couple of years. > So I can simply support your request. > > Thanks, > Maurizio > > Il giorno mar 29 ott 2019 alle ore 14:15 Julian Rickards < > julian.ricka...@gmail.com> ha scritto: > >> Hi: >> >> I've just thought of this (too late to be considered for 3.0, LoL). >> >> Some people use the Favourites list of modules a lot and it might be nice >> to be able to order the favourite modules in the order in which you'd like >> to use them. It is not intended to affect the pixel pipe order. >> >> Jules >> >> ___ >> darktable developer mailing list to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] (Future) Feature Request - Re-order Favourites Modules
Hi: I've just thought of this (too late to be considered for 3.0, LoL). Some people use the Favourites list of modules a lot and it might be nice to be able to order the favourite modules in the order in which you'd like to use them. It is not intended to affect the pixel pipe order. Jules ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: Fwd: [darktable-dev] Standardization of the writing of mouse interactions in the user manual
I know you can flip the right and left mouse button, I didn't know you could reverse the scroll direction, cool. However, either way, the scrolling direction has to be indicated and if you've customized button location or scroll direction, it's up to you to interpret the instructions in the manual to your system. On Wed, Oct 2, 2019 at 8:44 AM Sturm Flut wrote: > Hi, > > Am 02.10.19 um 14:31 schrieb Julian Rickards: > > This is not clear to me because the mouse wheel can be rolled towards > > the user or away from the user. Perhaps Ctrl+(scroll wheel away) and > > Ctrl+(scroll wheel towards). > > Different environments have different defaults. In some "away from the > user" defaults to "up", in some it defaults to "down". Also most > enviroments allow the user to flip the directions. > > (I for example always change the default scroll direction in GNOME.) > > cheers, > Simon > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: Fwd: [darktable-dev] Standardization of the writing of mouse interactions in the user manual
Regarding:
Ctrl+(mouse wheel) or (scroll wheel)
This is not clear to me because the mouse wheel can be rolled towards the
user or away from the user. Perhaps Ctrl+(scroll wheel away) and
Ctrl+(scroll wheel towards).
Although this is rather wordy, you need to differentiate between "away" and
"towards". Furthermore, I believe that you should include "wheel" as in
"scroll wheel" because if you use "scroll away", it might not be clear that
the wheel is to be used and might be interpreted as "move away". I think it
might be unnecessary to include "mouse" because I don't think that there
are any other wheels.
On Wed, Oct 2, 2019 at 8:03 AM Maurizio Paglia wrote:
> Hi all!
> personally I prefere the concise form too, with capitalized button command
> and '+' to clearly communicate it is a combo of buttons.
> ctrl-click (NO)
> Ctrl+click (YES)
>
> Shift should be translated in native languages ('Maiusc' for Italian)
>
> As regards mouse buttons...
> Ctrl+click
> Ctrl+(right click)
> Ctrl+(mouse wheel) or (scroll wheel)
>
> That's my opinion.
> Have a nice day!
> Maurizio
>
> Il giorno lun 30 set 2019 alle ore 23:58 jys
> ha scritto:
>
>> On Mon, Sep 30, 2019, at 12:42, Isabelle Hurbain-Palatin wrote:
>> > >
>> > > I think for consistency's sake, the idea of a group of commands
>> looking like this
>> > > *
>> > *
>> > > *Ctrl+A*
>> > > *Shift+L*
>> > > *Ctrl+(right click)*
>> > > *Alt+(scroll wheel)*
>> > >
>> > > makes more sense than
>> > >
>> > > *Ctrl+A*
>> > > *Shift+L*
>> > > *press/hold the Ctrl key and right click*
>> > > press/hold the Alt key and scroll the mouse wheel
>> >
>> > I agree with that, and I have some more arguments in favor on top of
>> > consistency :)
>> > ...
>> > Admittedly, I do not know how this reads for people who do not
>> > have a certain amount of "computer fluency", which would be my concern
>> > (and which probably is Microsoft's).
>>
>> I also have a personal preference for the more concise form, and I
>> *believe* this type of description to be well understood *by the intended
>> audience*... which, if true, seems like a valid reason for departing from
>> the MS style guide. If there's a general consensus, maybe someone could put
>> together a simple "quick guide" to use as a reference rather than the MS
>> one.
>>
>> > * From a "documentation writing" perspective, it does feel harder to me
>> > a priori to go for the sentence without having things getting
>> > cumbersome, especially if the sentence is already convoluted (which
>> > shouldn't happen, but, well, nobody's perfect :) ).
>>
>> I find it happens all too easily when trying to describe this type of
>> thing. Producing something with good readability is a skill completely
>> dintinct from having a good understanding a topic... some have even
>> suggested that there's an inverse correlation. ;-) Concerning the new
>> not-yet-documented features, I would say that it's probably easier for
>> someone on the "understanding" side to quickly check a highly readable
>> document for correctness than to work in the opposite direction, for
>> whatever that's worth.
>>
>> > And "rotate the wheel", in particular, feels very unnatural to me. This
>> is however a
>> > gut feeling issue, and from a non-native speaker as well, so it may not
>> > be shared.
>>
>> I completely agree with this (and am a native speaker). In general, my
>> gut feeling is to avoid overly-specific descriptions of physical actions as
>> much as possible. How this impacts readability among different segments of
>> the audience is something I can only speculate about, but there's another
>> issue: it makes more sense to describe, as much as possible, *the input
>> that darktable expects to see in order to trigger an action*, while making
>> the fewest possible assumptions about the input device the user is using.
>> While *most* people may be using a mouse, there are also trackpads,
>> trackballs, pen tablets, touch screens, etc... not to mention all kinds of
>> alternative keyboard mappings. For this reason, I would say "Scroll" should
>> be preferred to "Scroll Wheel", for instance.
>>
>> Anyway, that's my "two cents". As an additional aside, I get the
>> impression that non-native speakers are overly insecure about their overall
>> grasp of how to structure information in English. As a native speaker, I
>> find it very difficult to avoid the constant tendency to use idiomatic
>> forms that feel natural to me, but don't actually parse as good, simple
>> English which would be most easily understood (and translated) by
>> non-native speakers. I suspect non-native speakers are much better at this,
>> and it's an easy matter for a native speaker to then make any small
>> adjustments to grammar and syntax (since native English is well known to
>> not follow any sane set of rules in this regard). Keep in mind that most
>> native English speakers are exposed to a *wide* variation in the use of the
>> language, and are probably less critical abo
[darktable-dev] Move mask modes
dt 2.6.2 on Linux Mint 19.1 I wanted to create a mask but exclude an area within it. I couldn't figure it out but got some help, it was the "mode difference" that I needed. Perfect except, why are these modes in the Mask Manager and not part of the mask creation functions in whatever modules allow you to create masks? I know that feature requests are closed for 3.0 but perhaps for the next version, the modes could be moved to where masks are created. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Documentation
I'd like to help with documentation but I'm not a very experienced user. Might there be something I could do such as proofing or technical editing (testing)? I presume that I'd have to have 2.7 installed (which I would do but I haven't done so yet). Would I have to keep with nightly builds? ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] 64-stroke limit in "spot removal" module?
dt crashed on me a couple of times while creating many line masks but none of the masks were lost and I was able to continue until all 34 were complete. It happened while creating the masks but not afterwards when I was doing other things and the exports went fine. However, there may also be a limit to these too. The crash is likely related to having 4gb non-upgradeable RAM on the small laptop I take to the cottage so I wouldn't worry about that. On Thu, Aug 29, 2019 at 2:29 AM Jean-Luc Coulon (f5ibh) < jean.luc.cou...@gmail.com> wrote: > Hi, > I also experienced this. > The workaround is to open a second instance of the module. > > Regards > > Jean-Luc > > Le jeu. 29 août 2019 à 06:44, August Schwerdfeger < > aug...@schwerdfeger.name> a écrit : > >> Recently when editing a dusty film scan I tried to use the "spot removal" >> module to take care of the dust. After adding 64 strokes, I discovered that >> any further strokes were no-ops, producing no visible change to the image >> when added. I then created a second instance of the module; strokes added >> there worked as expected. >> >> Is there an implicit limit of 64 strokes in the "spot removal" module? >> >> -- >> August Schwerdfeger >> aug...@schwerdfeger.name >> >> ___ >> darktable developer mailing list to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Simple Text Watermark Editor
I know that there's been a message about halting new features for the next release in December but I'd like to post this for, if nothing else, future consideration. It is my understanding that the Simple Text watermark content must be in SVG format. However, the documentation is not very clear on how to do this. I do have Inkscape on my Linux Mint system which I've used to create a graphical watermark but for another purpose, I'd like to use some of the features (variable strings) available to the Simple Text watermark option to create a dynamic watermark. First of all, whether or not I use Inkscape, instructions on how do use, for example, $(IMAGE.FILENAME), are not to be found in the documentation. Secondly, if the content of a Simple Text can only be text (plus text styling such as font, colour, etc), then perhaps a future version of dt could include an editor that allows the user to use/pick variable strings and type text (such as "This photo was taken on $(EXIF.DATE)" but at the same time, shield the user from the complexity of SVG/XML. Thanks for listening, Jules ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] tagging module improvements
That sounds reasonable to me. On Tue, Aug 6, 2019 at 2:47 PM Sturm Flut wrote: > Hi, > > I don't think there currently is a way to automatically apply a style to > a tag, and if it was there might be conflicting tags with conflicting > associated default styles etc. > > At least in 2.7.x you can filter images by tag in the "collect images" > module and then apply a style to all filtered images. > > kind regards, > Simon > > > > Am 06.08.19 um 16:33 schrieb Julian Rickards: > > Not sure if this might be of interest. > > > > When I see a composition that appears suitable for B&W, I switch my > > (Olympus E-M5) camera to Monochrome mode and when I import the image, I > > tag it "B&W". In Lighttable mode, the image shows up as B&W because of > > the embedded image in the RAW file but as soon as I load it into > > Darkroom mode, the image is shown in colour. It would be nice for me to > > be able to tag an image with B&W and have a style or preset > > automatically applied based on the tag. There may be other uses too. > > > > On Fri, Aug 2, 2019 at 10:15 AM > <mailto:philippe.weyl...@libertysurf.fr>> wrote: > > > > Hi, > > I've added some features to tagging module as hierarchical amd list > > views, and rename command (merged in 2.7). > > I've let the former suggestion window but it doesn't give more than > > the tags list ordered by usage. > > The improvements I can think about are : > > - suggestion view based on the tags already attached on selected > > images. Then, when you attach a tag, the view suggests the most > > commonly used in association with it. > > - add synonyms to tags (with the corresponding import / export) > > - mark a tag as private (not exported with images) > > - category or helper to classify the tags mainly at the first level > > (hierarchical tags) > > > > What are your thoughts ? Suggestions ? > > > > If somebody could tell me I would like to know why the tags table is > > not in the library.db but alone in data.db. > > Then in tags table there are some unused fields. Is there any plan > > to make use of them ? > > > > Thanks > > Philippe > > > ___ > > darktable developer mailing list > > to unsubscribe send a mail to > > darktable-dev+unsubscr...@lists.darktable.org > > <mailto:darktable-dev%2bunsubscr...@lists.darktable.org> > > > > > > > ___ > > darktable developer mailing list to unsubscribe send a mail to > > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] tagging module improvements
Not sure if this might be of interest. When I see a composition that appears suitable for B&W, I switch my (Olympus E-M5) camera to Monochrome mode and when I import the image, I tag it "B&W". In Lighttable mode, the image shows up as B&W because of the embedded image in the RAW file but as soon as I load it into Darkroom mode, the image is shown in colour. It would be nice for me to be able to tag an image with B&W and have a style or preset automatically applied based on the tag. There may be other uses too. On Fri, Aug 2, 2019 at 10:15 AM wrote: > Hi, > I've added some features to tagging module as hierarchical amd list views, > and rename command (merged in 2.7). > I've let the former suggestion window but it doesn't give more than the > tags list ordered by usage. > The improvements I can think about are : > - suggestion view based on the tags already attached on selected images. > Then, when you attach a tag, the view suggests the most commonly used in > association with it. > - add synonyms to tags (with the corresponding import / export) > - mark a tag as private (not exported with images) > - category or helper to classify the tags mainly at the first level > (hierarchical tags) > > What are your thoughts ? Suggestions ? > > If somebody could tell me I would like to know why the tags table is not > in the library.db but alone in data.db. > Then in tags table there are some unused fields. Is there any plan to make > use of them ? > > Thanks > Philippe > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Error message
I will, good suggestion. I've since learned that my laptop (as I said, 13yrs old) is upgradeable to 8GB so I'll contact a local store and arrange for that. On Fri, Aug 2, 2019 at 2:19 AM KOVÁCS István wrote: > On Fri, 2 Aug 2019, 03:44 Julian Rickards, > wrote: > >> My laptop has non-expandable 4GB RAM >> I'll just deal with the error message as it comes up >> > > Why risk image corruption? I also use darktable with 4GB of RAM. If I were > you, I'd try the instructions for 32-bit systems (even though you're > running a 64-bit build): > > https://darktable.gitlab.io/doc/en/special_topics_chapter.html#darktable_and_memory_32bit > > Kofa > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Error message
Ah, thanks. My laptop has non-expandable 4GB RAM (actually, the System Info app states 3.8GB) so perhaps this is why. I'll just deal with the error message as it comes up (this evening, it hasn't shown up at all). On Thu, Aug 1, 2019 at 4:16 PM KOVÁCS István wrote: > On Thu, 1 Aug 2019, 20:56 Julian Rickards, > wrote: > >> I've been getting the following error >> >> 'tiling failed for module "atrous", image may be garbled' >> > > I think this belongs to the user list, but anyway: read the manual, and > look for tiling. More specifically: > > https://darktable.gitlab.io/doc/en/special_topics_chapter.html#darktable_and_memory > > host memory limit (in MB) for tiling > and > minimum amount of memory (in MB) for a single buffer in tiling > > Kofa > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Error message
When exporting to PNG from dt 2.6.2 (fullsized image, no cropping, 16bit png, compression 5, sRGB/Perceptual, Linux Mint 19.1), I've been getting the following error 'tiling failed for module "atrous", image may be garbled' However, the export does proceed and completes and I can't see any "garbling". ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Blending options on their own
OK, thanks, I'll go to another source for help on this as help with using darktable is not suited to this list. On Fri, Jun 21, 2019 at 11:55 AM Patrick Shanahan wrote: > * Julian Rickards [06-21-19 11:26]: > > Sometimes, when I want a dramatic B&W, I'll convert using the Color > > Channel, then open a second instance to apply nothing more than the > > Softlight overlay. (I wish there was a way to apply both in the same > > instance of a module but the colours return when I use both the BW preset > > and a blending option). > > > > I'm wondering if there might be interest in having the blending options, > in > > addition to within modules, as a stand-alone module for purposes such as > > I'm doing (rather than open a second instance of a module). > > consider just using the channel mixer or color contrast or color balance > module and forego blending altogether. > > > -- > (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri > http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri > Registered Linux User #207535@ http://linuxcounter.net > Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Blending options on their own
Sometimes, when I want a dramatic B&W, I'll convert using the Color Channel, then open a second instance to apply nothing more than the Softlight overlay. (I wish there was a way to apply both in the same instance of a module but the colours return when I use both the BW preset and a blending option). I'm wondering if there might be interest in having the blending options, in addition to within modules, as a stand-alone module for purposes such as I'm doing (rather than open a second instance of a module). ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] implementation question: remove all unused modules
OK, thanks, that answers that question. On Thu, Jun 13, 2019 at 12:00 PM William Ferguson wrote: > I modify demosiac on a fairly regular basis. I use PPG as the default, > but on noisy files I use AMAZE. I've created several denoise styles that > include demosiac changes. > > On Thu, Jun 13, 2019 at 11:55 AM Julian Rickards < > julian.ricka...@gmail.com> wrote: > >> Do people modify demosaic, input and output on a regular basis? If not, >>> could the options for each be moved to "Settings" so they aren't listed as >>> a module but modifiable when needed? >>> >>> >> ___ >> darktable developer mailing list to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] implementation question: remove all unused modules
> > Do people modify demosaic, input and output on a regular basis? If not, > could the options for each be moved to "Settings" so they aren't listed as > a module but modifiable when needed? > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] implementation question: remove all unused modules
Not to throw gas on the fire but it seems to me that some of this is already done. In Lighttable, when you wish to copy the history from one image to another, there are some modules missing (input and output) and also, the "off" modules aren't included in the possible modules to copy over. On Thu, Jun 13, 2019 at 5:30 AM wrote: > Aurélien Pierre (2019-Jun-13, excerpt): > > There is no image if the white balance has been disabled, just random > > bits for debugging purposes. The input color profile expects > > D50-balanced input, and this one is always on. Same with the highlight > > clipping module, most software have it built in the input profile and > > don't expose it. Disable these 2 and you mess up your whole module stack. > > > > So, again, what is the purpose of disabling these 2 modules, except for > > debugging, and why can they be disabled at all but are still > > auto-applied at opening ? > > It might well be a crap idea to do this, but it's possible, so someone > will do it. > > I see two possible outcomes to the current situation: > > 1. Some modules must not be disabled. > > Then the possibility to disable them is a bug that must be > resolved. > > This will "break" all existing XMPs that disable one of these > modules. > > 2. All modules can be disabled. > > Then they all must be reported to the history stack, and > compression must not modify their topmost recorded state. > > This will "break" all existing XMPs that lack a mentioning of > these modules in their stack. > > Either way, it's a messy situation that needs to be resolved. > > > The stack of exceptions handling in the SQL instructions smells bad. > > I agree. My first implementation was just like that. > > > Things should stay general. > > General would mean: No exception for "white balance" and others. > Later modules should simply refuse to work if no appropriate input is > available (message: “need white-balanced image”). To implement this, > something like the 'type' of an image could be propagated upwards > along the stack of IOPs (is this really not happening right now?). > Just as an oversimplified example, "white balance" might require 'RAW' > and provide 'D50-balanced', while "color profile" would require > 'D50-balanced'. This would allow to implement other modules providing > 'D50-balanced' without technical debt hindering their adoption later > on. > > Regarding the length of this thread, I assume that it will take quite > some time to reach consensus here. > > Clearly the current situation (having two different implementations of > "compress history", one more complete but changing images in > pathological cases) is unsatisfactory. > > So where do you want to go? > > Why I started this: I wanted to learn DTs internal data structures, in > order to implement better snapshots and history. The idea is to > replace the history stack with a rooted DAG, with the RAW at the root, > and all leaves snapshots (but not necessarily all snapshots at > leaves). Current histories would be straight lists. Creating a > snapshot, going back in history, and then doing a different edit, > would create a tree. This would pave the way to (in the future) > create IOPs that use more than one input, including a means to combine > multiple RAWs. This approach would clearly benefit from a 'typing' > system outlined above. > > > -- > http://stefan-klinger.deo/X > I prefer receiving plain text messages, not exceeding 32kB. /\/ > \ > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] implementation question: remove all unused modules
I must say that I've never used the Compress History option in the Lighttable, just in the Darkroom. Are there any differences? On Tue, Jun 11, 2019 at 1:01 PM jys wrote: > On Tue, Jun 11, 2019, at 07:47, thokster wrote: > > > Is the "compress history" button in lighttable view doing anything else? > > If you use this button you can clean up all selected pictures with one > > click (incurrent master). > > I probably totally misunderstood what you were up to. > > The current implementation of "compress history" only removes duplicate > entries per each module. The idea here is to also remove single instances > of modules which are set to "(off)". I think it would be good to get some > broader feedback about how to best implement this, since this is an area > where workflows might vary greatly, and sometimes it's hard to think > outside your own. Personally, I can think of times when an operation to > remove these would be useful, but maybe not always in conjunction with > "normal" history comression. They seem like two slightly different cleanup > operations to me, for whatever that's worth. > > -- > jys > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] implementation question: remove all unused modules
I'm not a programmer of any sort so take what I say with a grain of salt. When I compress the history, I like it to be clean so sometimes, there is/are module(s) with "(off)" in the compressed history. So what do I do? I enable them, then turn them off again so that they appear at the top of the list (visibly) with "(off)", then I click on the top module that doesn't have "(off)", compress the history again and the "(off)" modules disappear from the compressed history. It sounds like, from above: para...@paraf.in (2019-Jun-10, excerpt): > I think we still have default-on modules not recorded in history > stack (highlight reconstruction and white balance), so removing all > “off” steps might modify the image. that what I've done might modify the image. I haven't noticed any changes and really, there shouldn't be any changes: if a module has been used, modified and then turned off, any effect the module might apply with the modifications made within it, no effects should happen when it is off. Isn't that what we do to see if we like what the changes we've made to a module will do to an image, turn it on and off and if we don't like it, we either modify it or just keep it turned off? Surely, we can't turn off a module yet have some residual effect on the image? What I'm saying is that if a module appears in the compressed history with "(off)", this "flag" should be all that's required to remove it. Jules On Mon, Jun 10, 2019 at 11:30 AM wrote: > para...@paraf.in (2019-Jun-10, excerpt): > > I think we still have default-on modules not recorded in history > > stack (highlight reconstruction and white balance), so removing all > > “off” steps might modify the image. > > Hmmm. So if I understand you correctly, the problem is that removing > all unused modules would be a problem for some "special" modules which > are not recorded on the stack but are on by default, and have then > been disabled by the user. I observe this with "white balance": > > * disable "white balance" > > * compress history stack with removing unused modules > > * => white balance is automagically enabled again, changing the > image. > > Correct? I do not see any other problem. > > I could easily work around that by simply changing the query to > something like (yes, ugly) > > DELETE FROM main.history > WHERE imgid = ?1 > AND enabled == 0 > AND module != > AND module != > AND module != > AND module != > > But that would add technological debt in order to get around a funny > design choice (or: Why are these modules not recorded on the stack?) > > > Best approach would be to record all applied iops to history, but > > it’s a little tricky due to backwards compatibility > > I agree. > > Basically I see the question as this: Are these modules special (then > I must work around them, or they must not have the ability to be > disabled) or they are not (then they must be recorded to the history). > > For the backwards compatibility: I have not checked, but I hope that > there is versioning informaton in the XMPs. If so, new stacks should > have white balance added, and old stacks could be recognised and > migrated by adding the default white balance to their stacks. > > > -- > http://stefan-klinger.deo/X > I prefer receiving plain text messages, not exceeding 32kB. /\/ > \ > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] implementation question: remove all unused modules
Don't have much experience with styles so that point eluded me. Then it makes sense to have a checkbox to in/exclude the "off" modules. On Mon, Jun 10, 2019 at 9:21 AM wrote: > Julian Rickards (2019-Jun-10, excerpt): > > I have always wondered why "off" modules were included in the compressed > > history stack so I'm in favour of having them removed. When you compress > > the history stack, you lose the details of the history that took you to > the > > final stage so losing the "off" modules should be a no-brainer. > > I guess (!) one reason to keep them is in order to build styles, > which, when applied to an image (i.e., appended to an existing stack), > have the ability to switch off previously enabled modules. > > > -- > http://stefan-klinger.deo/X > I prefer receiving plain text messages, not exceeding 32kB. /\/ > \ > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] implementation question: remove all unused modules
I have always wondered why "off" modules were included in the compressed history stack so I'm in favour of having them removed. When you compress the history stack, you lose the details of the history that took you to the final stage so losing the "off" modules should be a no-brainer. On Mon, Jun 10, 2019 at 9:05 AM wrote: > Hi, > > I've drafted [1] an implementation to make "compress history stack" to > also remove all unused modules, i.e., the ones switched off. But > there are some questions: > > 1. This was so easy to do, maybe it's a bad idea to do this at all? > > 2. I have derived the SQL from looking at other statements in the > source. I have no deep knowledge about DT's architecture, so > someone needs to verify that the query does not mess with other > stuff. > > 3. I think deleting unused modules should be optional. How should I > implement that? > >* There could be a checkbox "remove unused moduls" next to the > "compress history stack" button. I think this is the most > simple option. > >* Maybe "remove unused moduls" and "compress history stack" > should be entirely separate operations? I'm not sure about > the exact semantics though: What, precisely, should the > former do without the latter? Maybe delete all mentions of a > module below and up to the one where it's switched off? > >* Maybe the (currently unused) "presets" menu of darktable's > "history" module should be used to host these operations? > > Cheers, > Stefan > > > [1] > https://github.com/darktable-org/darktable/compare/master...s5k6:compressHistory > > > > -- > http://stefan-klinger.deo/X > I prefer receiving plain text messages, not exceeding 32kB. /\/ > \ > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Magnification of modules in Darkroom
I use an older laptop with limited screen real estate and some modules are quite large (height is the issue on my laptop) and any means of improving this would be appreciated. I don't know if it would be part of the consideration but sometimes (recognize that I'm not an expert at dt or photography) I'd like to collapse the histogram to have more room. In my experience, the histogram is not always necessary for all steps in the editing process so the ability to collapse or open it as needed would help with screen real estate. On Thu, May 30, 2019 at 4:51 AM Florian W wrote: > Hi Giuseppe, > > I also found myself thinking the same in some cases (for the histogram, > for modules involving curves and nodes, for the fine tuning of a parametric > mask...). > > I added this to my bucket list of features I would like to implement, I > see I'm not the only one who miss it. > > Le mer. 29 mai 2019 18:08, Maurizio Paglia a écrit : > >> Ciao Giuseppe, >> I have the same difficulty. >> Please try to look the new dt GUI design because I think it could solve >> this problem. >> You can test it compiling dt 2.7 from source. >> >> Thank you, >> Maurizio >> >> Il giorno mer 29 mag 2019 alle ore 17:30 giuseppe.in...@gmail.com < >> giuseppe.in...@gmail.com> ha scritto: >> >>> Hello, >>> I think it could be useful to have a feature that allows you to view a >>> development module in a separate window with larger dimensions than the one >>> currently planned. There are in fact some modules, such as the color zone >>> (there may be other modules), with which it is not easy to interact >>> precisely because of the limited size of the window on which to operate. >>> Perhaps a button on the module's header is sufficient to display the module >>> in a larger window. >>> >>> What do you think about this? >>> >>> Regards, >>> Giuseppe. >>> >>> ___ >>> darktable developer mailing list to unsubscribe send a mail to >>> darktable-dev+unsubscr...@lists.darktable.org >>> >> >> ___ >> darktable developer mailing list to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Naming Module Instances
Thanks for the support. Jules On Sat, May 25, 2019 at 5:25 PM Bruce Williams wrote: > But Pascal, when you rename a module instance in 2.6.2, you can't remove > the original name of the module. > You can only append something meaningful to the existing module name. > I agree with the original request. The ability to replace the module's > original name would be much more useful (and screen-real-estate friendly). > > Cheers, > Bruce Williams. > > -- Forwarded message - > From: Pascal Obry > Date: Sun., 26 May 2019, 02:14 > Subject: Re: [darktable-dev] Naming Module Instances > To: Julian Rickards , < > darktable-dev@lists.darktable.org> > > > Hello Julian, > > > I'm using 2.4.4 so take this with a grain of salt. > > Yes, please update to 2.6.2... > > > I appreciate that when a new instance of a module has been created, > > that it be named "module #" but I'd like to be able to name the instance > > ... which makes this possible. > > Best, > > -- > 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 developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Naming Module Instances
Ah, thanks. On Sat, May 25, 2019 at 12:13 PM Pascal Obry wrote: > Hello Julian, > > > I'm using 2.4.4 so take this with a grain of salt. > > Yes, please update to 2.6.2... > > > I appreciate that when a new instance of a module has been created, > > that it be named "module #" but I'd like to be able to name the instance > > ... which makes this possible. > > Best, > > -- > 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 developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Naming Module Instances
I'm using 2.4.4 so take this with a grain of salt. I appreciate that when a new instance of a module has been created, that it be named "module #" but I'd like to be able to name the instance so that I know what I did with it. On a somewhat related note, when choosing a preset, I'd like the module to take on that name such as "channel mixer-B/W" and if the preset name is too long, parts of it won't be displayed but enough of it will likely be visible to recognize it. When we create a preset, it would be on us to ensure that our preset names are succinct. Combining both of these ideas: consider the "contrast brightness saturation" module name, it is long so if a preset name is added to it, it is likely that not all of the preset name will be displayed. However, if we can rename it, the option to change the name. For example, to desaturate the image where the lightness is in the top or bottom 25% of the scale, I've created at "contrast brightness saturation" preset called "desaturate high low 25%" so combining the two, I'd get "contrast brightness saturation-desaturate high low 25%" which perhaps I could rename to "CBS-Desat hi lo 25%". Thanks, Jules ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Options shouldn't be tied to Filmstrip
In the top message in this thread, I did propose some options. Here they are again. - over/underexposure and raw overexposure with the histogram (I think Adobe Lightroom has the over/underexposure right within the histogram) - style picker removed and the Style module moved from the Lightroom mode to Darkroom mode - soft proof might be better to be within the Lightroom mode (but I'll admit that I've never used it) - gamut check might be better within the Input Color Profile module as it appears to be the module that can address any issues: the Perspective module has the option of identifying vertical and horizontal lines before you decide to apply a correction, the gamut check could work the same way in the Input Color Profile module I've never used the Presets quick picker and for the life of me, I can't remember what the 6th option is. On Fri, Apr 26, 2019 at 1:08 PM Patrick Shanahan wrote: > * Julian Rickards [04-26-19 10:42]: > > Ah, yes, that is a better description. > > > > However, I still maintain that they are not relevant to the film strip > > which (obviously) is part of the bottom panel but more relevant to other > > components of the interface. > > > > Thanks for the correction. > > > > On Fri, Apr 26, 2019 at 9:38 AM Patrick Shanahan > wrote: > > > > > * Julian Rickards [04-26-19 08:54]: > > > > Hi: > > > > > > > > There are 6 options that appear below the main view window in > Darkroom > > > > mode: soft proof, over/underexposure, raw overexposed warning, > presets, > > > > access to styles and one other that I can't determine here. Access to > > > these > > > > options are tied to the visibility of the film strip which I think is > > > wrong. > > > > > > > > I believe that the over/underexposure and raw overexposed warning > buttons > > > > should be placed below or at the side of the histogram, it makes more > > > sense. > > > > > > > > I believe that the Styles module in the Lightable mode should be > moved to > > > > the Darkroom mode and therefore the quick access to the styles > button on > > > > the film strip can be removed altogether. > > > > > > > > I believe that the Soft Proof button would make more sense in the > > > Lightroom > > > > module or perhaps below the preview window at the top left. > > > > > > > > I don't recall using the quick access to presets so I can't comment > on > > > that. > > > > > > > > And the last button, I'm not sure what it is. > > > > > > > > However, the main thrust of this suggestion is that visibility and > access > > > > to these options are tied to the visibility of the filmstrip which > makes > > > no > > > > sense to me. > > > > > > no, not the film strip but to the bottom panel. visibility of the > options > > > do not depend on the film strip being visible. > > > > > > bottom panel = > > > > > > -- > > > (paka)Patrick Shanahan Plainfield, Indiana, USA > @ptilopteri > > > http://en.opensuse.orgopenSUSE Community Member > facebook/ptilopteri > > > Registered Linux User #207535@ > http://linuxcounter.net > > > Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet > freenode > > > > ___ > > > darktable developer mailing list > > > to unsubscribe send a mail to > > > darktable-dev+unsubscr...@lists.darktable.org > > > > > > > > yes, they are not relevant to the "film strip" and are not tied to it. > but they both exist within the bottom panel. if you believe they would > be better located, why, instead of just saying it is wrong, don't you > suggest "that better location"? > > instead of saying something would be better in a different manner, suggest > the better manner so your suggestions can be followed. > > -- > (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri > http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri > Registered Linux User #207535@ http://linuxcounter.net > Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Options shouldn't be tied to Filmstrip
Ah, yes, that is a better description. However, I still maintain that they are not relevant to the film strip which (obviously) is part of the bottom panel but more relevant to other components of the interface. Thanks for the correction. On Fri, Apr 26, 2019 at 9:38 AM Patrick Shanahan wrote: > * Julian Rickards [04-26-19 08:54]: > > Hi: > > > > There are 6 options that appear below the main view window in Darkroom > > mode: soft proof, over/underexposure, raw overexposed warning, presets, > > access to styles and one other that I can't determine here. Access to > these > > options are tied to the visibility of the film strip which I think is > wrong. > > > > I believe that the over/underexposure and raw overexposed warning buttons > > should be placed below or at the side of the histogram, it makes more > sense. > > > > I believe that the Styles module in the Lightable mode should be moved to > > the Darkroom mode and therefore the quick access to the styles button on > > the film strip can be removed altogether. > > > > I believe that the Soft Proof button would make more sense in the > Lightroom > > module or perhaps below the preview window at the top left. > > > > I don't recall using the quick access to presets so I can't comment on > that. > > > > And the last button, I'm not sure what it is. > > > > However, the main thrust of this suggestion is that visibility and access > > to these options are tied to the visibility of the filmstrip which makes > no > > sense to me. > > no, not the film strip but to the bottom panel. visibility of the options > do not depend on the film strip being visible. > > bottom panel = > > -- > (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri > http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri > Registered Linux User #207535@ http://linuxcounter.net > Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode > ___ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Options shouldn't be tied to Filmstrip
Hi: There are 6 options that appear below the main view window in Darkroom mode: soft proof, over/underexposure, raw overexposed warning, presets, access to styles and one other that I can't determine here. Access to these options are tied to the visibility of the film strip which I think is wrong. I believe that the over/underexposure and raw overexposed warning buttons should be placed below or at the side of the histogram, it makes more sense. I believe that the Styles module in the Lightable mode should be moved to the Darkroom mode and therefore the quick access to the styles button on the film strip can be removed altogether. I believe that the Soft Proof button would make more sense in the Lightroom module or perhaps below the preview window at the top left. I don't recall using the quick access to presets so I can't comment on that. And the last button, I'm not sure what it is. However, the main thrust of this suggestion is that visibility and access to these options are tied to the visibility of the filmstrip which makes no sense to me. Thanks, Jules ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Feature request: History read-only in snapshot module
Hi: Maybe it's just me but I have to be careful when using the Snapshot module to compare two different stages of history because I've occasionally left myself in the earlier stage, then perform an edit thereby erasing the history afterwards. I agree with the Snapshot module being based on different stages of the history but I would like the history list to showup in the snapshot module, being read-only by the module so that you can pick 2 different stages but it doesn't affect your actual position in the history: to do that you would have to go to the History module. Thanks, Jules ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
