Re: [darktable-dev] Feature request: Change modules order in UI

[Aurélien Pierre]

darktable modules are not merely GUI widgets, they are pixels filters, 
or adjustment layers if you come from Adobe.


Do you go in Photoshop or in Gimp moving layers on the stack because you 
prefer to have them sorted in alphabetic order ?


sob., 12 gru 2020 o 11:07 Wiktor Nowak > napisał(a):


I personally don't need this but also don't see a problem to make an
option to reorder modules only in UI not affecting the pipeline.
If some
users would find this helpful then why not?

W dniu 12.12.2020 o 10:57, Martin Straeten pisze:
> This doesn’t make sense since the order represents the order the
modules are applied in the pixel pipe. The output of the lower
module is the input of the upper. This is important to understand,
whats happening in the modules.
> You’re able to change the displayed order by ctrl+shift+drag but
this also changes the order of the module instance in the pipe.
> If it’s not relevant to take care of the moduleorder in the
pixel pipe, then you don’t really need darktable - and you
certainly don’t belong to the target group for which darktable was
developed.
>
>> Am 12.12.2020 um 10:20 schrieb Wiktor Nowak mailto:wik...@gmail.com>>:
>>
>> Hello
>>
>> Under one of my polish darktable tutorial video someone asked
about an
>> option to change order of modules in UI to order them
accordingly to
>> order of actions preferred by the user. I find this as a quite
simple to
>> develop and potentially useful functionality.
>>
>> best regards
>> Wiktor.
>>
___
>> 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




--
Pozdrawiam,
Hubert Kowalski

___ 
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] Feature request: Change modules order in UI

[Hubert Kowalski]

UI represents underlying concepts and shows them visually. If we made a
disconection between that it would cause more problems than it's worth,
because - what if you wanted to sort some modules in a way to not affect
the pipe and move some in a way that affects the pipe? Now you have 2
competing sorting representations, one which is meaningful and one which is
meaningless. In terms of KISS principle, we simply don't have meaningless
sort to deal with ;)

Also - users may find new flexible groups to be beneficial - that way they
won't have to deal with more modules than they are comfortable with and can
have multiple grouping presets etc:
https://darktable-org.github.io/dtdocs/module-reference/utility-modules/darkroom/manage-module-layouts/



sob., 12 gru 2020 o 11:07 Wiktor Nowak  napisał(a):

> I personally don't need this but also don't see a problem to make an
> option to reorder modules only in UI not affecting the pipeline. If some
> users would find this helpful then why not?
>
> W dniu 12.12.2020 o 10:57, Martin Straeten pisze:
> > This doesn’t make sense since the order represents the order the modules
> are applied in the pixel pipe. The output of the lower module is the input
> of the upper. This is important to understand, whats happening in the
> modules.
> > You’re able to change the displayed order by ctrl+shift+drag but this
> also changes the order of the module instance in the pipe.
> > If it’s not relevant to take care of the moduleorder in the pixel pipe,
> then you don’t really need darktable - and you certainly don’t belong to
> the target group for which darktable was developed.
> >
> >> Am 12.12.2020 um 10:20 schrieb Wiktor Nowak :
> >>
> >> Hello
> >>
> >> Under one of my polish darktable tutorial video someone asked about an
> >> option to change order of modules in UI to order them accordingly to
> >> order of actions preferred by the user. I find this as a quite simple to
> >> develop and potentially useful functionality.
> >>
> >> best regards
> >> Wiktor.
> >>
> ___
> >> 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
>
>

-- 
Pozdrawiam,
Hubert Kowalski

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

Re: [darktable-dev] Feature request: Change modules order in UI

[Wiktor Nowak]

I personally don't need this but also don't see a problem to make an
option to reorder modules only in UI not affecting the pipeline. If some
users would find this helpful then why not?

W dniu 12.12.2020 o 10:57, Martin Straeten pisze:
> This doesn’t make sense since the order represents the order the modules are 
> applied in the pixel pipe. The output of the lower module is the input of the 
> upper. This is important to understand, whats happening in the modules.
> You’re able to change the displayed order by ctrl+shift+drag but this also 
> changes the order of the module instance in the pipe.
> If it’s not relevant to take care of the moduleorder in the pixel pipe, then 
> you don’t really need darktable - and you certainly don’t belong to the 
> target group for which darktable was developed.
> 
>> Am 12.12.2020 um 10:20 schrieb Wiktor Nowak :
>>
>> Hello
>>
>> Under one of my polish darktable tutorial video someone asked about an
>> option to change order of modules in UI to order them accordingly to
>> order of actions preferred by the user. I find this as a quite simple to
>> develop and potentially useful functionality.
>>
>> best regards
>> Wiktor.
>> ___
>> 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] Feature request: Change modules order in UI

[Martin Straeten]

This doesn’t make sense since the order represents the order the modules are 
applied in the pixel pipe. The output of the lower module is the input of the 
upper. This is important to understand, whats happening in the modules.
You’re able to change the displayed order by ctrl+shift+drag but this also 
changes the order of the module instance in the pipe.
If it’s not relevant to take care of the moduleorder in the pixel pipe, then 
you don’t really need darktable - and you certainly don’t belong to the target 
group for which darktable was developed.

> Am 12.12.2020 um 10:20 schrieb Wiktor Nowak :
> 
> Hello
> 
> Under one of my polish darktable tutorial video someone asked about an
> option to change order of modules in UI to order them accordingly to
> order of actions preferred by the user. I find this as a quite simple to
> develop and potentially useful functionality.
> 
> best regards
> Wiktor.
> ___
> 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] Feature request: Change modules order in UI

[Hubert Kowalski]

It is present in darktable. Drag module with Ctrl+shift. It changes order
of operations in pipeline, not just how it looks in gui so user has to be
careful.

sob., 12 gru 2020, 10:19 użytkownik Wiktor Nowak  napisał:

> Hello
>
> Under one of my polish darktable tutorial video someone asked about an
> option to change order of modules in UI to order them accordingly to
> order of actions preferred by the user. I find this as a quite simple to
> develop and potentially useful functionality.
>
> best regards
> Wiktor.
> ___
> 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] Feature request: Star icon on module headers

[Nicolas Auffray]

Hi Bruce, and all,

I think is not a good idea. This will add one more icon so reduce space 
size on the line. And with some languages like french who use some 
longer words, space used is space less for image. I would also add that 
favorite icon is mostly used one time to set all favorites and most of 
the time is not more use, and only after first set when a new module or 
some change appear on user workflow. So not so often used like actual icons.


Best regards,

Nicolas Auffray


Le 05/01/2020 à 06:05, Bruce Williams a écrit :

Hi all,
Just wanted to throw an idea out there.
With the introduction of the search bar in dt 3, I find that I often 
will search for a module which I don't have marked as a 'favourite'.
My FR is that if ANY text has been entered into the search box, an 
additional icon (a star) be placed on the module headers alongside the 
'multiple instances', 'reset' and 'preset' buttons.

This would allow adding a module immediately to the favourites list.
Anyone else feel as though this might be useful?
Cheers,
Bruce Williams
--

audio2u.com 
brucewilliamsphotography.com 
shuttersincpodcast.com 
sinelanguagepodcast.com 

e-mail  | Twitter 
 | LinkedIn 
 | Facebook 
 | Soundcloud 
 | Quora 


--



___ 
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] feature request

[David Vincent-Jones]

Use the tone curve eye-dropper  select 'area' dropdown on the color 
picker  draw a rectangle on the cobble-stones and the area will be 
colored on the tone-curve.


David

On 2019-03-16 9:32 a.m., David LaCivita wrote:

Hi,

When using the "levels" or "tone curve" modules the histogram is shown 
in the module. I often use drawn and parametric masks with these 
modules. Would it be possible to have the histogram reflect the 
selected area?
For example, If I had an image with a cobble stone road and some 
buildings I would use the path tool to select the cobble stone road. I 
would like to see the histogram in the module reflect the selected 
area. Then, I would create a new instance of the module and use the 
path tool to select a building. The histogram would be different in 
each instance.

I've seen this implemented in Ps tutorials but I can't remember where.

Thank you,
Dave LaCivita
https://www.instagram.com/_digital_dave_/
https://www.instagram.com/_analog_dave_/
Independent Optavia Health Coach
617-501-5982




___ 
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] Feature request

[Terry Duell]

Hello Bill,

On Fri, 14 Dec 2018 03:15:33 +1100, William Ferguson  
 wrote:



Terry,

If you go to https://redmine.darktable.org/projects/darktable/issues and
submit a new issue for a feature request, I'll code up the solution and  
do a pull request.  In the meantime, when I submit the PR the code will  
be

available in a branch on my github and I'll let you know where it is so
that you can compile it and use it.


I'll delay adding the feature request for the moment, as I think I have  
finally sorted a bash scripting method that may satisfy.
I have yet to test this approach with a largish number of folders and dirs  
so not sure yet how much of a task this will be.


Thanks for your efforts, much appreciated.

Cheers,
--
Regards,
Terry Duell
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Feature request

[William Ferguson]

Terry,

If you go to https://redmine.darktable.org/projects/darktable/issues and
submit a new issue for a feature request, I'll code up the solution and do
a pull request.  In the meantime, when I submit the PR the code will be
available in a branch on my github and I'll let you know where it is so
that you can compile it and use it.

Bill

On Thu, Dec 13, 2018 at 1:56 AM William Ferguson 
wrote:

> In darktable, the gui version, I cropped an image, then turned crop off.
> I went back to lighttable and created a style, croff, from the crop off
> history item.
>
> I modified darktable-cli to initialize the data library, take the style
> argument and --append which says append the style to the history stack
> versus replace the history stack (which would wipe out all the edits).
>
> The first 4 arguments are to darktable-cli, the --core is to pass the
> remaining arguments to the darktable instance that gets started from
> darktable-cli.  The argument --configdir /home/bill/.config/dttest, tells
> darktable where to find the data.db that has the croff style.
>
> I tested the crop off style and a noise reduction style and both worked,
> so I would think that just about any style that can be constructed would
> work.
>
>
> On Wed, Dec 12, 2018 at 11:32 PM Terry Duell  wrote:
>
>> Hello Bill,
>>
>> On Thu, 13 Dec 2018 14:58:36 +1100, William Ferguson
>>  wrote:
>>
>> > /opt/dttest/bin/darktable-cli _7D_0651.CR2  _7D_0651.jpg --style "croff"
>> > --append --core --configdir /home/bill/.config/dttest works for me.
>> >
>> > Oops, that's the version I just hacked together...   :-D
>> >
>>
>> I take it from the above that you have a local modified version of
>> darktable-cli which takes a --style "croff" switch, but not sure what
>> the
>> following is all about.
>> I've been beavering away here trying to figure out elegant ways of
>> setting
>> the clipping in the xmp files to "0", and then restoring after export,
>> but
>> if your feature is robust it would be a better solution.
>>
>> > Should I submit a PR?
>>
>> I'm not ofay with how these things are done, best see what the experts
>> have to say.
>>
>> Cheers,
>> --
>> Regards,
>> Terry Duell
>>
>> ___
>> 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] Feature request

[William Ferguson]

In darktable, the gui version, I cropped an image, then turned crop off.  I
went back to lighttable and created a style, croff, from the crop off
history item.

I modified darktable-cli to initialize the data library, take the style
argument and --append which says append the style to the history stack
versus replace the history stack (which would wipe out all the edits).

The first 4 arguments are to darktable-cli, the --core is to pass the
remaining arguments to the darktable instance that gets started from
darktable-cli.  The argument --configdir /home/bill/.config/dttest, tells
darktable where to find the data.db that has the croff style.

I tested the crop off style and a noise reduction style and both worked, so
I would think that just about any style that can be constructed would work.


On Wed, Dec 12, 2018 at 11:32 PM Terry Duell  wrote:

> Hello Bill,
>
> On Thu, 13 Dec 2018 14:58:36 +1100, William Ferguson
>  wrote:
>
> > /opt/dttest/bin/darktable-cli _7D_0651.CR2  _7D_0651.jpg --style "croff"
> > --append --core --configdir /home/bill/.config/dttest works for me.
> >
> > Oops, that's the version I just hacked together...   :-D
> >
>
> I take it from the above that you have a local modified version of
> darktable-cli which takes a --style "croff" switch, but not sure what the
> following is all about.
> I've been beavering away here trying to figure out elegant ways of
> setting
> the clipping in the xmp files to "0", and then restoring after export,
> but
> if your feature is robust it would be a better solution.
>
> > Should I submit a PR?
>
> I'm not ofay with how these things are done, best see what the experts
> have to say.
>
> Cheers,
> --
> Regards,
> Terry Duell
> ___
> 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] Feature request

[Terry Duell]

Hello Bill,

On Thu, 13 Dec 2018 14:58:36 +1100, William Ferguson  
 wrote:



/opt/dttest/bin/darktable-cli _7D_0651.CR2  _7D_0651.jpg --style "croff"
--append --core --configdir /home/bill/.config/dttest works for me.

Oops, that's the version I just hacked together...   :-D



I take it from the above that you have a local modified version of  
darktable-cli which takes a --style "croff" switch, but not sure what the  
following is all about.
I've been beavering away here trying to figure out elegant ways of setting  
the clipping in the xmp files to "0", and then restoring after export, but  
if your feature is robust it would be a better solution.



Should I submit a PR?


I'm not ofay with how these things are done, best see what the experts  
have to say.


Cheers,
--
Regards,
Terry Duell
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Feature request

[William Ferguson]

/opt/dttest/bin/darktable-cli _7D_0651.CR2  _7D_0651.jpg --style "croff"
--append --core --configdir /home/bill/.config/dttest works for me.

Oops, that's the version I just hacked together...   :-D

Should I submit a PR?


Bill

On Wed, Dec 12, 2018 at 12:40 PM Mark Feit  wrote:

> On 12/12/18 11:32 AM, William Ferguson wrote:
> > Just tried applying a style with crop turned off during export and it
> > worked fine.
> Now do it with the CLI.
>
> --Mark
>
>
> ___
> 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] Feature request

[Mark Feit]

On 12/12/18 4:28 PM, Terry Duell wrote:


This is pretty much the solution that Patrick proposed.


Unless I missed something (not ruling that out; it's been known to 
happen), the first reply I saw was Pascal Obry's, which was GUI-centric.


The impression I got from your reply was that you were looking to do 
this through the CLI.  That piques my interest because my workflow is 
very batch-centric and all of the final final generation of images is 
done by shell scripts.  The only time I use the GUI for exporting is 
when I need to dump one image or something special like exporting a 
calibration card to build a camera color profile.



I did a test with one file where I set enabled to 0 for clipping and 
it didn't have any effect, and the prospect of attempting using sed or 
similar to edit the xmp to remove all clipping instructions was beyond 
my abilities.
I'll have to look at that again, as there may have been another 
clipping command later in that xmp.


I've created a tarball with my experiment that you can download from 
http://www.feitography.com/hole/nocrop.tar.gz. Unpack it, run 'make 
diff' to see the difference between the cropped and uncropped versions 
of the XMP, then run 'make' to produce JPEGs of versions of the image 
with the CLI.



If you attempt this please let me know how you get on and pass on your 
scripts if you are prepared to do so.


I'll see if I can knock it out in the next few days and will post the 
results here.  Shouldn't take long.  I need to learn how to use 
XMLStarlet, but that should be quick since I'm after two pretty simple 
operations.



--Mark


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

Re: [darktable-dev] Feature request

[Terry Duell]

Hello Mark,

On Thu, 13 Dec 2018 00:43:17 +1100, Mark Feit  wrote:


On 12/11/18 10:07 PM, Terry Duell wrote:


The requirement for uncropped images seriously complicates the task if  
using darktable-cli.
The request is to have a 'crop=0' switch (or similar) for  
darktable-cli...if that is possible, and reasonable.


That would start a trend of having to propagate a lot of switches out to  
darktable-cli, which wouldn't end well.  Everything needed to bend  
darktable to your will is already in the sidecar (XMP) file that goes  
with each image.  What's missing is an alternate sidecar with the  
cropping turned off that could be handed to darktable-cli.


I did the following manually for a single image and it produced the  
right thing:


1.  Make a copy of the image's sidecar file (cp image.nef.xmp  
image.nef.xmp-nocrop).


2.  Edit the copy (vi image.nef.xmp-nocrop), locate all of the rdf:li  
items where darktable:operation is "clipping" and change  
darktable:enabled to "0".  This process can be automated with xsltproc  
or XMLStarlet.  The latter is available on all three of the platforms  
where darktable is supported.  (You could probably get away with some  
sneaky sed-based tricks, but I don't recommend that because the  
arrangement of the XML shouldn't be considered stable.  Use the right  
tool for the job.)




This is pretty much the solution that Patrick proposed.
I did a test with one file where I set enabled to 0 for clipping and it  
didn't have any effect, and the prospect of attempting using sed or  
similar to edit the xmp to remove all clipping instructions was beyond my  
abilities.
I'll have to look at that again, as there may have been another clipping  
command later in that xmp.


3.  Run darktable-cli against the image and edited XMP to produce an  
uncropped version of the image (darktable-cli image.nef  
image.nef.xmp-nocrop image-uncropped.jpg).


4.  Harvest the uncropped image for distribution and remove it and the  
edited sidecar if you don't want to keep them around.



Turning it into a shell script that can operate against any set of files  
you choose should be an easy exercise.  (It's an interesting enough  
problem that I might do it myself.)


If you attempt this please let me know how you get on and pass on your  
scripts if you are prepared to do so.


Thanks for your contribution.
At least there two other users that see the problem is a bit more than  
simply trying apply an export style.


Cheers,
--
Regards,
Terry Duell
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Feature request

[Mark Feit]

On 12/12/18 11:32 AM, William Ferguson wrote:
Just tried applying a style with crop turned off during export and it 
worked fine.

Now do it with the CLI.

--Mark


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

Re: [darktable-dev] Feature request

[William Ferguson]

Just tried applying a style with crop turned off during export and it
worked fine.

On Wed, Dec 12, 2018 at 10:34 AM Patrick Shanahan  wrote:

> * Mark Feit  [12-12-18 09:36]:
> > On 12/11/18 10:07 PM, Terry Duell wrote:
> > >
> > > The requirement for uncropped images seriously complicates the task if
> > > using darktable-cli.
> > > The request is to have a 'crop=0' switch (or similar) for
> > > darktable-cli...if that is possible, and reasonable.
> >
> > That would start a trend of having to propagate a lot of switches out to
> > darktable-cli, which wouldn't end well.  Everything needed to bend
> darktable
> > to your will is already in the sidecar (XMP) file that goes with each
> > image.  What's missing is an alternate sidecar with the cropping turned
> off
> > that could be handed to darktable-cli.
> >
> > I did the following manually for a single image and it produced the right
> > thing:
> >
> > 1.  Make a copy of the image's sidecar file (cp image.nef.xmp
> > image.nef.xmp-nocrop).
> >
> > 2.  Edit the copy (vi image.nef.xmp-nocrop), locate all of the rdf:li
> items
> > where darktable:operation is "clipping" and change darktable:enabled to
> > "0".  This process can be automated with xsltproc or XMLStarlet.  The
> latter
> > is available on all three of the platforms where darktable is supported.
> > (You could probably get away with some sneaky sed-based tricks, but I
> don't
> > recommend that because the arrangement of the XML shouldn't be considered
> > stable.  Use the right tool for the job.)
> >
> > 3.  Run darktable-cli against the image and edited XMP to produce an
> > uncropped version of the image (darktable-cli image.nef
> image.nef.xmp-nocrop
> > image-uncropped.jpg).
> >
> > 4.  Harvest the uncropped image for distribution and remove it and the
> > edited sidecar if you don't want to keep them around.
> >
> >
> > Turning it into a shell script that can operate against any set of files
> you
> > choose should be an easy exercise.  (It's an interesting enough problem
> that
> > I might do it myself.)
>
> and I believe that was more or less the first suggestion given.
>
> --
> (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] Feature request

[Patrick Shanahan]

* Mark Feit  [12-12-18 09:36]:
> On 12/11/18 10:07 PM, Terry Duell wrote:
> > 
> > The requirement for uncropped images seriously complicates the task if
> > using darktable-cli.
> > The request is to have a 'crop=0' switch (or similar) for
> > darktable-cli...if that is possible, and reasonable.
> 
> That would start a trend of having to propagate a lot of switches out to
> darktable-cli, which wouldn't end well.  Everything needed to bend darktable
> to your will is already in the sidecar (XMP) file that goes with each
> image.  What's missing is an alternate sidecar with the cropping turned off
> that could be handed to darktable-cli.
> 
> I did the following manually for a single image and it produced the right
> thing:
> 
> 1.  Make a copy of the image's sidecar file (cp image.nef.xmp
> image.nef.xmp-nocrop).
> 
> 2.  Edit the copy (vi image.nef.xmp-nocrop), locate all of the rdf:li items
> where darktable:operation is "clipping" and change darktable:enabled to
> "0".  This process can be automated with xsltproc or XMLStarlet.  The latter
> is available on all three of the platforms where darktable is supported. 
> (You could probably get away with some sneaky sed-based tricks, but I don't
> recommend that because the arrangement of the XML shouldn't be considered
> stable.  Use the right tool for the job.)
> 
> 3.  Run darktable-cli against the image and edited XMP to produce an
> uncropped version of the image (darktable-cli image.nef image.nef.xmp-nocrop
> image-uncropped.jpg).
> 
> 4.  Harvest the uncropped image for distribution and remove it and the
> edited sidecar if you don't want to keep them around.
> 
> 
> Turning it into a shell script that can operate against any set of files you
> choose should be an easy exercise.  (It's an interesting enough problem that
> I might do it myself.)

and I believe that was more or less the first suggestion given.

-- 
(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

Re: [darktable-dev] Feature request

[Mark Feit]

On 12/11/18 10:07 PM, Terry Duell wrote:


The requirement for uncropped images seriously complicates the task if 
using darktable-cli.
The request is to have a 'crop=0' switch (or similar) for 
darktable-cli...if that is possible, and reasonable.


That would start a trend of having to propagate a lot of switches out to 
darktable-cli, which wouldn't end well.  Everything needed to bend 
darktable to your will is already in the sidecar (XMP) file that goes 
with each image.  What's missing is an alternate sidecar with the 
cropping turned off that could be handed to darktable-cli.


I did the following manually for a single image and it produced the 
right thing:


1.  Make a copy of the image's sidecar file (cp image.nef.xmp 
image.nef.xmp-nocrop).


2.  Edit the copy (vi image.nef.xmp-nocrop), locate all of the rdf:li 
items where darktable:operation is "clipping" and change 
darktable:enabled to "0".  This process can be automated with xsltproc 
or XMLStarlet.  The latter is available on all three of the platforms 
where darktable is supported.  (You could probably get away with some 
sneaky sed-based tricks, but I don't recommend that because the 
arrangement of the XML shouldn't be considered stable.  Use the right 
tool for the job.)


3.  Run darktable-cli against the image and edited XMP to produce an 
uncropped version of the image (darktable-cli image.nef 
image.nef.xmp-nocrop image-uncropped.jpg).


4.  Harvest the uncropped image for distribution and remove it and the 
edited sidecar if you don't want to keep them around.



Turning it into a shell script that can operate against any set of files 
you choose should be an easy exercise.  (It's an interesting enough 
problem that I might do it myself.)


HTH.

--Mark



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

Re: [darktable-dev] Feature request

[Matthieu Moy]

- Original Message -
> From: "Terry Duell" 

> Thanks for your response, but I have considered that, and the task of
> going into every folder and manually selecting all the images for export
> seems an onerous approach.

You have the "collect images" module to perform more or less any kind of 
filtering, and once this is done selecting all and exporting is just a matter 
of typing control-a control-e.

Note that you don't have to apply the style to images: there's a "style" 
dropdown in the "export selected" module.

-- 
Matthieu Moy
https://matthieu-moy.fr/
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Feature request

[Pascal Obry]

Hello Terry,

Thanks for your response, but I have considered that, and the task of
> going into every folder and manually selecting all the images for export
> seems an onerous approach. Note that I have a few thousand images.
> I wouldn't hesitate to use a style if I only had a small number of images
> to export.
>

??? You want to export your pictures so you have to select them, no?

Then why using a style in the export dialog is so difficult? I may be
missing something.

Cheers,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://photos.obry.net
  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

Re: [darktable-dev] Feature request

[Terry Duell]

Hello Pascal,

On Wed, 12 Dec 2018 17:13:48 +1100, Pascal Obry  wrote:


Le mercredi 12 décembre 2018 à 14:07 +1100, Terry Duell a écrit :

Hello All,
I have been struggling to find a relatively simple method of exporting
large numbers of images with all post processing intact except for
cropping.


Create a style with all module disabled and use it during export.
Should work.



Thanks for your response, but I have considered that, and the task of  
going into every folder and manually selecting all the images for export  
seems an onerous approach. Note that I have a few thousand images.
I wouldn't hesitate to use a style if I only had a small number of images  
to export.
If it could be done via darktable-cli, lists of images can be simply  
created in a file (ls *.DNG *.xmp) and the filelists fed to scripts to  
call darktable-cli. At this stage, this seems to me to be a much more  
readily managed process.
If my feature request is difficult to implement that is another matter,  
but if not it does seem to me to be a nice feature to add to the export  
capabilities of darktable.


Cheers,
--
Regards,
Terry Duell
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Feature request

[Pascal Obry]

Le mercredi 12 décembre 2018 à 14:07 +1100, Terry Duell a écrit :
> Hello All,
> I have been struggling to find a relatively simple method of exporting  
> large numbers of images with all post processing intact except for  
> cropping.

Create a style with all module disabled and use it during export.
Should work.

-- 
  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

Re: [darktable-dev] Feature request: Warning for keyboard shortcut collisions

[Patrick Shanahan]

* Hobbes Pirakitti  [11-23-18 17:49]:
> Hi! I am a new darktable user, and I'm exploring how darktable can fit into
> my raw processing workflow.  I like the ability to set up shortcuts.  One
> feature request I have regarding shortcuts is that I would like darktable
> to pop up a warning if the shortcut I am trying to assign is already
> taken.  Is this is right place to make this request?

  https://redmine.darktable.org/projects/darktable/issues/new

is where the dev's track.
-- 
(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

Re: [darktable-dev] Feature request (Cropping module GUI)

[Christian]

Ok, just saw, that there is a FORMAT option, so all good now
as is.

Chris :-)


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

Re: [darktable-dev] Feature request (Cropping module GUI)

[Alan Lundin]

* Pascal Obry (pas...@obry.net) [181117 00:40]:
* Subject: Re: [darktable-dev] Feature request (Cropping module GUI):
> Le vendredi 16 novembre 2018 ?? 15:25 -0700, Alan Lundin a ??crit :
> > Is there some reason the aspect ratio can't be specified with two
> > input boxes:  x : y ?
> 
> That's already possible : x / y
> 
> See the manual.

How cool is that?  I can't believe I missed it.

Thanks.

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

Re: [darktable-dev] Feature request (Cropping module GUI)

[Christian]

Hi,
idea: "snap" to common values during drawing of the rectangle:

- original ratio
- 16:9
- 3:2
- 1:1
etc.

Chris


Am 16.11.2018 um 21:50 schrieb Jan Ingwer Baer:
Of course DT should not round, but it should show the Ratio with an 
integer for the small-side. For me showing 8.2/5 or 3.28/2 (with the 
pixel-ratio of the OP) is much more meaningful then 1.62/1. I think it 
should be possible to select a usable integer numerator/denominator 
based on the fractional ratio.


If the user wants to create a crop with one of the common aspect ratios 
showing it as simple float makes it very challenging to find the right 
values. For example : The user wants to create a crop with 16/9. 
Displaying the aspect ratio as 1.77/1 is not a big help.


The challenge is to find the right integer. My idea is to define ratio 
ranges for selection :


1.2 - 1.4 : set denominator to 3 gives  3.6/3 -  4.2/3 ( ~4/3)
1.4 - 1.6 : set denominator to 2 gives  2.8/2 -  3.2/2 ( ~3/2)
1.6 - 1.9 : set denominator to 9 gives 14.4/9 - 17.1/9 (~16/9)


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

Re: [darktable-dev] Feature request (Cropping module GUI)

[Pascal Obry]

Le vendredi 16 novembre 2018 à 15:25 -0700, Alan Lundin a écrit :
> Is there some reason the aspect ratio can't be specified with two
> input boxes:  x : y ?

That's already possible : x / y

See the manual.

-- 
  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

Re: [darktable-dev] Feature request (Cropping module GUI)

[Alan Lundin]

Is there some reason the aspect ratio can't be specified with two
input boxes:  x : y ?

Then the person could imput 16 : 9   or   1. : 1   or  8 : 4.5
-- however they preferred.  [ And if they wanted it rotated, then
9 : 16 .]

Personally, I'd prefer the flexibility over the convenience.

--alan

* August Schwerdfeger (aug...@schwerdfeger.name) [181116 14:22]:
* Subject: Re: [darktable-dev] Feature request (Cropping module GUI):
> The problem with selecting these integers based on commonly-used aspect
> ratios, is that the only real use for this feature would be in "freehand"
> mode when cropping to an *unusual* aspect ratio; the common ones like 16:9
> are represented in the "aspect" combo box and it is much easier to select
> the "16:9, HDTV" option to constrain the ratio.
> 
> --
> August Schwerdfeger
> aug...@schwerdfeger.name
> 
> On Fri, Nov 16, 2018 at 2:51 PM Jan Ingwer Baer  wrote:
> 
> > On 16-Nov-18 18:26, Heiko Bauke wrote:
> > > Hi,
> > >
> > > Am Freitag, 16. November 2018 schrieb Jan Ingwer Baer:
> > >> If DT shows the aspect ratio it should try to find the nearest integral
> > >> fraction (of course with values below 30) like 3:2, 16:9, ...
> > >>
> > >>
> > >> For your exampel it should show 8.2:5, or it should use one of the
> > >> common denominators x:2, x:3, x:4, x:9 ...
> > >
> > > I don't think that this is a good idea, as the user can not know how
> > close the actual aspect ratio is to the approximate value that is indicated
> > in the UI.
> > >
> > > Heiko
> > >
> > Of course DT should not round, but it should show the Ratio with an
> > integer for the small-side. For me showing 8.2/5 or 3.28/2 (with the
> > pixel-ratio of the OP) is much more meaningful then 1.62/1. I think it
> > should be possible to select a usable integer numerator/denominator
> > based on the fractional ratio.
> >
> > If the user wants to create a crop with one of the common aspect ratios
> > showing it as simple float makes it very challenging to find the right
> > values. For example : The user wants to create a crop with 16/9.
> > Displaying the aspect ratio as 1.77/1 is not a big help.
> >
> > The challenge is to find the right integer. My idea is to define ratio
> > ranges for selection :
> >
> > 1.2 - 1.4 : set denominator to 3 gives  3.6/3 -  4.2/3 ( ~4/3)
> > 1.4 - 1.6 : set denominator to 2 gives  2.8/2 -  3.2/2 ( ~3/2)
> > 1.6 - 1.9 : set denominator to 9 gives 14.4/9 - 17.1/9 (~16/9)
> >
> >
> > ___
> > 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] Feature request (Cropping module GUI)

[August Schwerdfeger]

The problem with selecting these integers based on commonly-used aspect
ratios, is that the only real use for this feature would be in "freehand"
mode when cropping to an *unusual* aspect ratio; the common ones like 16:9
are represented in the "aspect" combo box and it is much easier to select
the "16:9, HDTV" option to constrain the ratio.

--
August Schwerdfeger
aug...@schwerdfeger.name

On Fri, Nov 16, 2018 at 2:51 PM Jan Ingwer Baer  wrote:

> On 16-Nov-18 18:26, Heiko Bauke wrote:
> > Hi,
> >
> > Am Freitag, 16. November 2018 schrieb Jan Ingwer Baer:
> >> If DT shows the aspect ratio it should try to find the nearest integral
> >> fraction (of course with values below 30) like 3:2, 16:9, ...
> >>
> >>
> >> For your exampel it should show 8.2:5, or it should use one of the
> >> common denominators x:2, x:3, x:4, x:9 ...
> >
> > I don't think that this is a good idea, as the user can not know how
> close the actual aspect ratio is to the approximate value that is indicated
> in the UI.
> >
> > Heiko
> >
> Of course DT should not round, but it should show the Ratio with an
> integer for the small-side. For me showing 8.2/5 or 3.28/2 (with the
> pixel-ratio of the OP) is much more meaningful then 1.62/1. I think it
> should be possible to select a usable integer numerator/denominator
> based on the fractional ratio.
>
> If the user wants to create a crop with one of the common aspect ratios
> showing it as simple float makes it very challenging to find the right
> values. For example : The user wants to create a crop with 16/9.
> Displaying the aspect ratio as 1.77/1 is not a big help.
>
> The challenge is to find the right integer. My idea is to define ratio
> ranges for selection :
>
> 1.2 - 1.4 : set denominator to 3 gives  3.6/3 -  4.2/3 ( ~4/3)
> 1.4 - 1.6 : set denominator to 2 gives  2.8/2 -  3.2/2 ( ~3/2)
> 1.6 - 1.9 : set denominator to 9 gives 14.4/9 - 17.1/9 (~16/9)
>
>
> ___
> 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] Feature request (Cropping module GUI)

[Jan Ingwer Baer]

On 16-Nov-18 18:26, Heiko Bauke wrote:

Hi,

Am Freitag, 16. November 2018 schrieb Jan Ingwer Baer:

If DT shows the aspect ratio it should try to find the nearest integral
fraction (of course with values below 30) like 3:2, 16:9, ...


For your exampel it should show 8.2:5, or it should use one of the
common denominators x:2, x:3, x:4, x:9 ...


I don't think that this is a good idea, as the user can not know how close the 
actual aspect ratio is to the approximate value that is indicated in the UI.

Heiko

Of course DT should not round, but it should show the Ratio with an 
integer for the small-side. For me showing 8.2/5 or 3.28/2 (with the 
pixel-ratio of the OP) is much more meaningful then 1.62/1. I think it 
should be possible to select a usable integer numerator/denominator 
based on the fractional ratio.


If the user wants to create a crop with one of the common aspect ratios 
showing it as simple float makes it very challenging to find the right 
values. For example : The user wants to create a crop with 16/9. 
Displaying the aspect ratio as 1.77/1 is not a big help.


The challenge is to find the right integer. My idea is to define ratio 
ranges for selection :


1.2 - 1.4 : set denominator to 3 gives  3.6/3 -  4.2/3 ( ~4/3)
1.4 - 1.6 : set denominator to 2 gives  2.8/2 -  3.2/2 ( ~3/2)
1.6 - 1.9 : set denominator to 9 gives 14.4/9 - 17.1/9 (~16/9)


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

Re: [darktable-dev] Feature request (Cropping module GUI)

[Heiko Bauke]

Hi,

Am Freitag, 16. November 2018 schrieb Jan Ingwer Baer:
> If DT shows the aspect ratio it should try to find the nearest integral 
> fraction (of course with values below 30) like 3:2, 16:9, ...
> 
> 
> For your exampel it should show 8.2:5, or it should use one of the 
> common denominators x:2, x:3, x:4, x:9 ...

I don't think that this is a good idea, as the user can not know how close the 
actual aspect ratio is to the approximate value that is indicated in the UI.

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.or

Re: [darktable-dev] Feature request (Cropping module GUI)

[Jan Ingwer Baer]

If DT shows the aspect ratio it should try to find the nearest integral 
fraction (of course with values below 30) like 3:2, 16:9, ...



For your exampel it should show 8.2:5, or it should use one of the 
common denominators x:2, x:3, x:4, x:9 ...


It's not easy to find the best...

On 16-Nov-18 14:22, Christian wrote:

Hi,
could the aspect ratio added to the cropping display
(module: Zuschneiden und Drehen)?

So instead of (4203 x 2564) show (4203 x 2564 / 1:1.64).

Chris


___
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] feature request - image panning and accurate scaling/fitting at cropping

[Alexander Rabtchevich]

Tobias Ellinghaus wrote:


In development builds you can pan the image with the arrow keys and zoom with
ctrl-- and ctrl-+. The panning steps can be made smaller/bigger with alt/shit
keys. I suppose we could add that to zooming, too, and maybe also to the
scroll wheel zoom.


Thanks. Panning with Alt and arrow keys works fine.

Downscaling with keyboard sometimes works, sometimes not. Upscaling 
doesn't work for me. Mint 18.3 Mate edition.


Need to say these alternative scaling and panning operations require 
leaving mouse and going to the keyboard. So if mouse wheel is 
complimented with Alt, it will be wonderful addition. And panning with 
mouse could be very convenient too.



With respect,
Alexander Rabtchevich

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

Re: [darktable-dev] feature request - image panning and accurate scaling/fitting at cropping

[Tobias Ellinghaus]

Am Samstag, 27. Januar 2018, 09:11:50 CET schrieb Alexander Rabtchevich:
> Hello
> 
> While cropping, especially portrait oriented images, it is hard to get
> maximum useful space for the crop within the monitor. The step of
> scaling is too big to achieve some appropriate size of the frame for
> cropping. Also there is no way to pan the image (not the cropping area)
> within the monitor. Panning through changing cursor position during
> scaling is not accurate enough and requires iterative actions.
> 
> Is there the way to:
>  1. decrease the step of scaling for the mouse wheel, maybe with
> keyboard modifier or through settings.

In development builds you can pan the image with the arrow keys and zoom with 
ctrl-- and ctrl-+. The panning steps can be made smaller/bigger with alt/shit 
keys. I suppose we could add that to zooming, too, and maybe also to the 
scroll wheel zoom.

>  2. implement panning of the image, not the cropping frame, if the
> cursor is outside the cropping frame?
> 
> 
> With respect,
> Alexander Rabtchevich
> ___
> darktable developer mailing list
> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Feature request: Clipboard for darkroom settings (styles)

[Maurizio Paglia]

Ciao Johannes,
I cannot understand very well your question.
If you copy the history stack of a shot you can then paste it on more shots.
Select the already developed image, copy the history stack, select one or
more destination images, paste the history stack.

If you desire to copy history stack from a slot you can have different
history on each image contained in the slot itself...

Maurizio

2017-10-06 11:11 GMT+02:00 Johannes Enevoldsen :

> Hi,
>
> I believe a system for handeling multiple, temporary, settings/styles
> could be very useful. I often find that i want to apply nearly the same
> settings to multiple photos from the same shoot (I could do this by
> grouping the photos, but i like to edit my photos in chronological order).
>
> I suggest a system like the existing copy-paste (ctrl-C, ctrl-V) but with
> slots for multiple settings. E.g. ctrl+shift+1 to copy settings to slot 1
> and then ctrl+1 to paste them.
>
> Johannes
>
> ___
> 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] Feature request: Styles organized in subfoders

[Tobias Ellinghaus]

Am Donnerstag, 31. August 2017, 11:46:33 CEST schrieb Vlad Kuzba:
> Hello,

Hi.

> ​I now have about a hundred different styles both collected and created
> myself and finding the one I want to use is getting harder and harder. I
> believe, I'm not alone in this :-). Would it be possible to have the styles
> organised in user defined folders, something like RawTherapy uses for its
> styles and HaldCLUT files? For example:
> 
> ~/.config/darktable/styles/
> ~/.config/darktable/styles/colour/
> ~/.config/darktable/styles/colour/agfa/
> ~/.config/darktable/styles/colour/kodak/
> ~/.config/darktable/styles/colour/wedding/
> ~/.config/darktable/styles/colour/landscapes/
> ~/.config/darktable/styles/bw/
> ~/.config/darktable/styles/bw/ilford
> ~/.config/darktable/styles/bw/fuji
> ...
> 
> ​Then, both in Lightroom and Darkroom we could pick the style we want by
> going a series of sub-menus referring to those folders. That would IMHO
> make finding the appropriate style much easier.

In general I think that would be a good idea.

Please note however that the files stored in ~/.config/darkable/styles/ are 
just 
a backup. darktable never reads them or cares if you edit, rename or delete 
them. But that's just a detail.

> Vladimír Kuzba

Tobias

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Feature request: Styles organized in subfoders

[Maurizio Paglia]

Ciao Vladimir,
I think this feature will help a lot of people (me too!).
Now the only option you have is to use a structured style name so they are
listed in the combo box as you need but I understand this is a difficult
task.

Maurizio

2017-08-31 11:46 GMT+02:00 Vlad Kuzba :

> Hello,
>
> ​I now have about a hundred different styles both collected and created
> myself and finding the one I want to use is getting harder and harder. I
> believe, I'm not alone in this :-). Would it be possible to have the styles
> organised in user defined folders, something like RawTherapy uses for its
> styles and HaldCLUT files? For example:
>
> ~/.config/darktable/styles/
> ~/.config/darktable/styles/colour/
> ~/.config/darktable/styles/colour/agfa/
> ~/.config/darktable/styles/colour/kodak/
> ~/.config/darktable/styles/colour/wedding/
> ~/.config/darktable/styles/colour/landscapes/
> ~/.config/darktable/styles/bw/
> ~/.config/darktable/styles/bw/ilford
> ~/.config/darktable/styles/bw/fuji
> ...
>
> ​Then, both in Lightroom and Darkroom we could pick the style we want by
> going a series of sub-menus referring to those folders. That would IMHO
> make finding the appropriate style much easier.
>
>
> Vladimír Kuzba
>
>
> ___
> 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] Feature request: add the exported photo to DT view

[David Vincent-Jones]

OK ... I see the problem. Error message:

<>

Will have to be patient and wait 'till things catch up. thanks ...

darktable 2.1.pre+git2000.f63e5ce-1.1

David


*
*


On 10/21/2016 09:11 AM, William Ferguson wrote:
That should be enough to get it running.  Go to the export selected 
module on the right in lighttable view, drop down the target storage 
list and you should see file to collection as a choice.  If you select 
an image, then choose the export format, then choose export, it will 
show up in the collection grouped with the original image.



Regards,

Bill

On Fri, Oct 21, 2016 at 11:43 AM, David Vincent-Jones 
mailto:david...@gmail.com>> wrote:


I have inserted a copy of the script into the
.config/darktable/lua folder and added a require line into the
luarc file . what further do I need to get this running? All
rather new to me!!

David


On 10/19/2016 11:13 AM, William Ferguson wrote:

I created contrib/export2collection.lua that adds a new exporter,
file to collection. The selected images are exported, then
imported back into the collection and grouped with the original
images.  All tags, except the darktable ones, are copied over as
well as any ratings.  The pull request has been submitted to get
it into the script repository.  In the meantime you can get it
from

https://github.com/wpferguson/lua-scripts/blob/export2collection/contrib/export2collection.lua



Regards,

Bill

On Wed, Oct 19, 2016 at 5:11 AM, Roman Lebedev
mailto:lebedev...@gmail.com>> wrote:

On Wed, Oct 19, 2016 at 12:05 PM, Javier
mailto:micorreoanon...@gmail.com>> wrote:
> Hi,
>
> I've noted that when I exported a photo the exported file
exists on the
> directory but it cannot be seen in DT (you have to reload
the entire folder
> to see it).
There is no reload. It's called re-import.
Feel free to google the differences.

> I commented this behaviour in the mailing list and I was
told that this is
> the way DT deals with exported photos. I don`t know the
reason but perhaps
> it would be useful that DT shows all the pictures in the
selected directory,
> both exported as original ones, because the file is there.
Until/unless the image is imported into the darktable's
library, darktable
does not know anything about it. If you want to see such an
image,
you need to import it.

How?
Lua can add export formats. I'm sure it is possible to adapt
one of the existing
scripts at https://github.com/darktable-org/lua-scripts
 to re-import
after export.
(basically by running  $ darktable   if there
is dbus,
it will iimport
the image in the current darktable instance.)

> Thank you very much,
> Javier
Roman.

>

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


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




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




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






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

Re: [darktable-dev] Feature request: add the exported photo to DT view

[William Ferguson]

That should be enough to get it running.  Go to the export selected module
on the right in lighttable view, drop down the target storage list and you
should see file to collection as a choice.  If you select an image, then
choose the export format, then choose export, it will show up in the
collection grouped with the original image.


Regards,

Bill

On Fri, Oct 21, 2016 at 11:43 AM, David Vincent-Jones 
wrote:

> I have inserted a copy of the script into the .config/darktable/lua folder
> and added a require line into the luarc file . what further do I need
> to get this running? All rather new to me!!
>
> David
>
> On 10/19/2016 11:13 AM, William Ferguson wrote:
>
> I created contrib/export2collection.lua that adds a new exporter, file to
> collection.  The selected images are exported, then imported back into the
> collection and grouped with the original images.  All tags, except the
> darktable ones, are copied over as well as any ratings.  The pull request
> has been submitted to get it into the script repository.  In the meantime
> you can get it from https://github.com/wpferguson/lua-scripts/blob/
> export2collection/contrib/export2collection.lua
>
> Regards,
>
> Bill
>
> On Wed, Oct 19, 2016 at 5:11 AM, Roman Lebedev 
> wrote:
>
>> On Wed, Oct 19, 2016 at 12:05 PM, Javier 
>> wrote:
>> > Hi,
>> >
>> > I've noted that when I exported a photo the exported file exists on the
>> > directory but it cannot be seen in DT (you have to reload the entire
>> folder
>> > to see it).
>> There is no reload. It's called re-import.
>> Feel free to google the differences.
>>
>> > I commented this behaviour in the mailing list and I was told that this
>> is
>> > the way DT deals with exported photos. I don`t know the reason but
>> perhaps
>> > it would be useful that DT shows all the pictures in the selected
>> directory,
>> > both exported as original ones, because the file is there.
>> Until/unless the image is imported into the darktable's library, darktable
>> does not know anything about it. If you want to see such an image,
>> you need to import it.
>>
>> How?
>> Lua can add export formats. I'm sure it is possible to adapt one of the
>> existing
>> scripts at https://github.com/darktable-org/lua-scripts to re-import
>> after export.
>> (basically by running  $ darktable   if there is dbus,
>> it will iimport
>> the image in the current darktable instance.)
>>
>> > Thank you very much,
>> > Javier
>> Roman.
>>
>> > 
>> ___
>> > 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+unsubscribe@list
>> s.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] Feature request: add the exported photo to DT view

[David Vincent-Jones]

I have inserted a copy of the script into the .config/darktable/lua 
folder and added a require line into the luarc file . what further 
do I need to get this running? All rather new to me!!


David


On 10/19/2016 11:13 AM, William Ferguson wrote:
I created contrib/export2collection.lua that adds a new exporter, file 
to collection.  The selected images are exported, then imported back 
into the collection and grouped with the original images.  All tags, 
except the darktable ones, are copied over as well as any ratings.  
The pull request has been submitted to get it into the script 
repository.  In the meantime you can get it from 
https://github.com/wpferguson/lua-scripts/blob/export2collection/contrib/export2collection.lua


Regards,

Bill

On Wed, Oct 19, 2016 at 5:11 AM, Roman Lebedev > wrote:


On Wed, Oct 19, 2016 at 12:05 PM, Javier
mailto:micorreoanon...@gmail.com>> wrote:
> Hi,
>
> I've noted that when I exported a photo the exported file exists
on the
> directory but it cannot be seen in DT (you have to reload the
entire folder
> to see it).
There is no reload. It's called re-import.
Feel free to google the differences.

> I commented this behaviour in the mailing list and I was told
that this is
> the way DT deals with exported photos. I don`t know the reason
but perhaps
> it would be useful that DT shows all the pictures in the
selected directory,
> both exported as original ones, because the file is there.
Until/unless the image is imported into the darktable's library,
darktable
does not know anything about it. If you want to see such an image,
you need to import it.

How?
Lua can add export formats. I'm sure it is possible to adapt one
of the existing
scripts at https://github.com/darktable-org/lua-scripts
 to re-import
after export.
(basically by running  $ darktable   if there is dbus,
it will iimport
the image in the current darktable instance.)

> Thank you very much,
> Javier
Roman.

>
___
> 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] Feature request: add the exported photo to DT view

[Javier]

Thank you Roman, William, André and David for you comments and help.

I think th behaviour of DT depends of the particular needs of every people
and their particular workflow. I see your reasons, but for me it would be
very useful to automatically re-import the exported file basically because
the file is there and I want to see all the pictures in the directory (in
that way I can confirm the export is what I intended, I didn`t change
something by error, etc) without using an external viewer.

I'll follow the guidelines you mentioned and try the scripts you provide.

Thank you very much.
Javier

2016-10-20 8:41 GMT+02:00 David Vincent-Jones :

> The option of storing exported materials to the parent folder is IMO a
> very useful addition to the current file handling system. Thank you William.
>
> David
>
> On 10/19/2016 11:13 AM, William Ferguson wrote:
>
> I created contrib/export2collection.lua that adds a new exporter, file to
> collection.  The selected images are exported, then imported back into the
> collection and grouped with the original images.  All tags, except the
> darktable ones, are copied over as well as any ratings.  The pull request
> has been submitted to get it into the script repository.  In the meantime
> you can get it from https://github.com/wpferguson/lua-scripts/blob/
> export2collection/contrib/export2collection.lua
>
> Regards,
>
> Bill
>
> On Wed, Oct 19, 2016 at 5:11 AM, Roman Lebedev 
> wrote:
>
>> On Wed, Oct 19, 2016 at 12:05 PM, Javier 
>> wrote:
>> > Hi,
>> >
>> > I've noted that when I exported a photo the exported file exists on the
>> > directory but it cannot be seen in DT (you have to reload the entire
>> folder
>> > to see it).
>> There is no reload. It's called re-import.
>> Feel free to google the differences.
>>
>> > I commented this behaviour in the mailing list and I was told that this
>> is
>> > the way DT deals with exported photos. I don`t know the reason but
>> perhaps
>> > it would be useful that DT shows all the pictures in the selected
>> directory,
>> > both exported as original ones, because the file is there.
>> Until/unless the image is imported into the darktable's library, darktable
>> does not know anything about it. If you want to see such an image,
>> you need to import it.
>>
>> How?
>> Lua can add export formats. I'm sure it is possible to adapt one of the
>> existing
>> scripts at https://github.com/darktable-org/lua-scripts to re-import
>> after export.
>> (basically by running  $ darktable   if there is dbus,
>> it will iimport
>> the image in the current darktable instance.)
>>
>> > Thank you very much,
>> > Javier
>> Roman.
>>
>> > 
>> ___
>> > 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+unsubscribe@list
>> s.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] Feature request: add the exported photo to DT view

[David Vincent-Jones]

The option of storing exported materials to the parent folder is IMO a 
very useful addition to the current file handling system. Thank you William.


David


On 10/19/2016 11:13 AM, William Ferguson wrote:
I created contrib/export2collection.lua that adds a new exporter, file 
to collection.  The selected images are exported, then imported back 
into the collection and grouped with the original images.  All tags, 
except the darktable ones, are copied over as well as any ratings.  
The pull request has been submitted to get it into the script 
repository.  In the meantime you can get it from 
https://github.com/wpferguson/lua-scripts/blob/export2collection/contrib/export2collection.lua


Regards,

Bill

On Wed, Oct 19, 2016 at 5:11 AM, Roman Lebedev > wrote:


On Wed, Oct 19, 2016 at 12:05 PM, Javier
mailto:micorreoanon...@gmail.com>> wrote:
> Hi,
>
> I've noted that when I exported a photo the exported file exists
on the
> directory but it cannot be seen in DT (you have to reload the
entire folder
> to see it).
There is no reload. It's called re-import.
Feel free to google the differences.

> I commented this behaviour in the mailing list and I was told
that this is
> the way DT deals with exported photos. I don`t know the reason
but perhaps
> it would be useful that DT shows all the pictures in the
selected directory,
> both exported as original ones, because the file is there.
Until/unless the image is imported into the darktable's library,
darktable
does not know anything about it. If you want to see such an image,
you need to import it.

How?
Lua can add export formats. I'm sure it is possible to adapt one
of the existing
scripts at https://github.com/darktable-org/lua-scripts
 to re-import
after export.
(basically by running  $ darktable   if there is dbus,
it will iimport
the image in the current darktable instance.)

> Thank you very much,
> Javier
Roman.

>
___
> 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] Feature request: add the exported photo to DT view

[André Felipe Carvalho]

What I understand is that dt is used to work on an image: You have the
original image, raw or jpeg, and want to process it somehow. After you
finish your work, you export it, generating the final image. So, its final.
You can you any image viewer to see the result. I use the Gnome Image
Viewer  to view them, and am very comfortable with it.

If you re-import it, dt will create sidecar files for them, even if you
wont re-process them. In fact, if something went wrong and you need to
re-process it, you'll normally do it on the original file. Maybe
duplicating the sidecar, so you can save both versions, if it's the case.

So I, as a dt user, don't see reason to re-import an exported image.

My two cents ;-))(I love this phrase ;-))

Best regards,
André Felipe


2016-10-19 16:13 GMT-02:00 William Ferguson :

> I created contrib/export2collection.lua that adds a new exporter, file to
> collection.  The selected images are exported, then imported back into the
> collection and grouped with the original images.  All tags, except the
> darktable ones, are copied over as well as any ratings.  The pull request
> has been submitted to get it into the script repository.  In the meantime
> you can get it from https://github.com/wpferguson/lua-scripts/blob/
> export2collection/contrib/export2collection.lua
>
> Regards,
>
> Bill
>
> On Wed, Oct 19, 2016 at 5:11 AM, Roman Lebedev 
> wrote:
>
>> On Wed, Oct 19, 2016 at 12:05 PM, Javier 
>> wrote:
>> > Hi,
>> >
>> > I've noted that when I exported a photo the exported file exists on the
>> > directory but it cannot be seen in DT (you have to reload the entire
>> folder
>> > to see it).
>> There is no reload. It's called re-import.
>> Feel free to google the differences.
>>
>> > I commented this behaviour in the mailing list and I was told that this
>> is
>> > the way DT deals with exported photos. I don`t know the reason but
>> perhaps
>> > it would be useful that DT shows all the pictures in the selected
>> directory,
>> > both exported as original ones, because the file is there.
>> Until/unless the image is imported into the darktable's library, darktable
>> does not know anything about it. If you want to see such an image,
>> you need to import it.
>>
>> How?
>> Lua can add export formats. I'm sure it is possible to adapt one of the
>> existing
>> scripts at https://github.com/darktable-org/lua-scripts to re-import
>> after export.
>> (basically by running  $ darktable   if there is dbus,
>> it will iimport
>> the image in the current darktable instance.)
>>
>> > Thank you very much,
>> > Javier
>> Roman.
>>
>> > 
>> ___
>> > 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+unsubscribe@list
>> s.darktable.org
>>
>>
>
> ___
> darktable developer mailing list to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>



-- 
André Felipe

https://www.flickr.com/photos/andrefelipecarvalho/

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

Re: [darktable-dev] Feature request: add the exported photo to DT view

[William Ferguson]

I created contrib/export2collection.lua that adds a new exporter, file to
collection.  The selected images are exported, then imported back into the
collection and grouped with the original images.  All tags, except the
darktable ones, are copied over as well as any ratings.  The pull request
has been submitted to get it into the script repository.  In the meantime
you can get it from
https://github.com/wpferguson/lua-scripts/blob/export2collection/contrib/export2collection.lua

Regards,

Bill

On Wed, Oct 19, 2016 at 5:11 AM, Roman Lebedev  wrote:

> On Wed, Oct 19, 2016 at 12:05 PM, Javier 
> wrote:
> > Hi,
> >
> > I've noted that when I exported a photo the exported file exists on the
> > directory but it cannot be seen in DT (you have to reload the entire
> folder
> > to see it).
> There is no reload. It's called re-import.
> Feel free to google the differences.
>
> > I commented this behaviour in the mailing list and I was told that this
> is
> > the way DT deals with exported photos. I don`t know the reason but
> perhaps
> > it would be useful that DT shows all the pictures in the selected
> directory,
> > both exported as original ones, because the file is there.
> Until/unless the image is imported into the darktable's library, darktable
> does not know anything about it. If you want to see such an image,
> you need to import it.
>
> How?
> Lua can add export formats. I'm sure it is possible to adapt one of the
> existing
> scripts at https://github.com/darktable-org/lua-scripts to re-import
> after export.
> (basically by running  $ darktable   if there is dbus,
> it will iimport
> the image in the current darktable instance.)
>
> > Thank you very much,
> > Javier
> Roman.
>
> > 
> ___
> > 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+unsubscribe@
> lists.darktable.org
>
>

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

Re: [darktable-dev] Feature request: add the exported photo to DT view

[Roman Lebedev]

On Wed, Oct 19, 2016 at 12:05 PM, Javier  wrote:
> Hi,
>
> I've noted that when I exported a photo the exported file exists on the
> directory but it cannot be seen in DT (you have to reload the entire folder
> to see it).
There is no reload. It's called re-import.
Feel free to google the differences.

> I commented this behaviour in the mailing list and I was told that this is
> the way DT deals with exported photos. I don`t know the reason but perhaps
> it would be useful that DT shows all the pictures in the selected directory,
> both exported as original ones, because the file is there.
Until/unless the image is imported into the darktable's library, darktable
does not know anything about it. If you want to see such an image,
you need to import it.

How?
Lua can add export formats. I'm sure it is possible to adapt one of the existing
scripts at https://github.com/darktable-org/lua-scripts to re-import
after export.
(basically by running  $ darktable   if there is dbus,
it will iimport
the image in the current darktable instance.)

> Thank you very much,
> Javier
Roman.

> ___
> 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] Feature Request

[Roman Lebedev]

On Tue, Oct 18, 2016 at 10:01 PM, Tim Rolph  wrote:
> Hi All, would it be possible to add an option for auto raw white point
> calculation?
No. Because that would be selfish.
If it really is an issue, you need to report it:
https://redmine.darktable.org/projects/darktable/issues/new
And do attach one raw per every iso level.
That way it could be fixed for everyone :)

> At the moment the raw white point for CRW files is set at 4000, I
> believe this is because of Adobe DNG creator reports this! I find that the
> required white point can vary between 1000 and 9000 depending on the
> individual image!

> I also have just checked how Rawtherapee handles highlight reconstruction and
> it seem at least on the few images I have checked to produce better
> results.:-(
That statement is too generic.
Which darktable version, which highlight reconstruction mode?
Which rt's highlight reconstruction mode?

But i can tell you that dt's highlight reconstruction mode LCh got much better
in git master compared to 2.0.x

> Regards,
>
> Tim
Roman.

> ___
> 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] feature request: new iop: apply 3D LUT from file

[Tobias Ellinghaus]

Am Montag, 17. Oktober 2016, 10:30:55 CEST schrieb Seweryn Niemiec:
> On 13.10.2016 16:03, Tobias Ellinghaus wrote:
> > Well, there are several places where a LUT can be applied. Once in the
> > beginning, to get you recorded video data to a known state (kind of
> > replaces input color profile), then there are final looks LUTs that are
> > to be applied in the very end (to make the linear pixels look ok, adding
> > a gamma curve and maybe some film emulation, so basically the final
> > grading). And then there are intermediate ones like you ask for.
> 
> That's true. If we want Darktable to process video footage (which happens to
> me from time to time), then that would be the perfect way. There is usually
> LUT converting from given camera's colour space characteristics to some
> common space, like Cineon or rec709, then artistic grading or film
> emulation LUT, then LUTs converting to colour spaces of distribution
> mediums, like film print. For photography, since there are no LUTs (at
> least known to me) that are designed to work with, for example, CR2 raw
> files, then LUT module in the middle of the pipeline would be enough
> (that's for me).

The output one might still be useful, I am not sure about that though. We will 
see about that.

> > We discussed that a few times internally and while I would like to support
> > that, there is the problem of WHERE to have such a module in the pipe. Or
> > if we should add LUT support in a single new module plus the the
> > input/output color profile modules? So many options ... If you have more
> > insight I would like to hear about it.
> 
> Could color profile modules be extended to do what they do now plus LUT
> transformation? This and new module in the middle (after some basic luma and
> colour correction modules, because LUTs are usually picky on what they get
> on input) could be solution which does not increase UI entropy too much.

As Johannes already wrote, there is the new LUT module very early in the pipe 
after input color profile already. Once we have a more robust way of converting 
regular LUT files (.cube, HaldCLUT, ...) for use in that module we might 
already be fine. It might be worth a try at least.

> > I wouldn't like to add that dependency as it's a rather big one and
> > somewhat opposed to the ICC based workflow we use. But we don't need it
> > anyway, I already have written some test code that reads cube files and
> > applies them.
> Great! :)

Tobias

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] feature request: new iop: apply 3D LUT from file

[Seweryn Niemiec]

On 13.10.2016 16:03, Tobias Ellinghaus wrote:

Well, there are several places where a LUT can be applied. Once in the
beginning, to get you recorded video data to a known state (kind of replaces
input color profile), then there are final looks LUTs that are to be applied in
the very end (to make the linear pixels look ok, adding a gamma curve and
maybe some film emulation, so basically the final grading). And then there are
intermediate ones like you ask for.


That's true. If we want Darktable to process video footage (which happens to me 
from time to time), then that would be the perfect way. There is usually LUT 
converting from given camera's colour space characteristics to some common 
space, like Cineon or rec709, then artistic grading or film emulation LUT, then 
LUTs converting to colour spaces of distribution mediums, like film print. For 
photography, since there are no LUTs (at least known to me) that are designed to 
work with, for example, CR2 raw files, then LUT module in the middle of the 
pipeline would be enough (that's for me).



We discussed that a few times internally and while I would like to support
that, there is the problem of WHERE to have such a module in the pipe. Or if
we should add LUT support in a single new module plus the the input/output
color profile modules? So many options ... If you have more insight I would
like to hear about it.


Could color profile modules be extended to do what they do now plus LUT 
transformation? This and new module in the middle (after some basic luma and 
colour correction modules, because LUTs are usually picky on what they get on 
input) could be solution which does not increase UI entropy too much.



I wouldn't like to add that dependency as it's a rather big one and somewhat
opposed to the ICC based workflow we use. But we don't need it anyway, I
already have written some test code that reads cube files and applies them.


Great! :)

--
Best regards,
Seweryn Niemiec

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

Re: [darktable-dev] feature request: new iop: apply 3D LUT from file

[johannes hanika]

fwiw people have already found ways to ingest 3d luts into our colour
look up table module:

https://www.youtube.com/watch?v=m_cLCL5PJk4

-jo

On Fri, Oct 14, 2016 at 3:03 AM, Tobias Ellinghaus  wrote:
> Am Donnerstag, 13. Oktober 2016, 12:53:12 CEST schrieb Seweryn Niemiec:
>> Hi
>>
>> Colour transformations using 3D LUTs (Look Up Table) are popular in
>> cinematography but no so in photography (probably one of the causes is a
>> lack of support for it in software). I use them a lot and I usually drop
>> using Darktable for those cases and switch to Natron, but this solution is
>> far from perfect (I love Darktable for many reasons).
>>
>> LUT transformation have to applied in pipeline after basic exposure and
>> colour correction and before some other luma and colour corrections.
>
> Well, there are several places where a LUT can be applied. Once in the
> beginning, to get you recorded video data to a known state (kind of replaces
> input color profile), then there are final looks LUTs that are to be applied 
> in
> the very end (to make the linear pixels look ok, adding a gamma curve and
> maybe some film emulation, so basically the final grading). And then there are
> intermediate ones like you ask for.
>
> We discussed that a few times internally and while I would like to support
> that, there is the problem of WHERE to have such a module in the pipe. Or if
> we should add LUT support in a single new module plus the the input/output
> color profile modules? So many options ... If you have more insight I would
> like to hear about it.
>
>> AFAIK, ready to use implementation of this transformation is provided by
>> OpenColorIO library via LookTransform function. It is used in most
>> compositing programs (like Natron, Fusion, Nuke) and reads all popular file
>> formats (3dl, cube, csp...)
>
> I wouldn't like to add that dependency as it's a rather big one and somewhat
> opposed to the ICC based workflow we use. But we don't need it anyway, I
> already have written some test code that reads cube files and applies them.
>
>> A have created issue for this https://redmine.darktable.org/issues/11217
>>
>> Was there in the past any discussion about such iop?
>
> Tobias
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] feature request: new iop: apply 3D LUT from file

[Tobias Ellinghaus]

Am Donnerstag, 13. Oktober 2016, 12:53:12 CEST schrieb Seweryn Niemiec:
> Hi
> 
> Colour transformations using 3D LUTs (Look Up Table) are popular in
> cinematography but no so in photography (probably one of the causes is a
> lack of support for it in software). I use them a lot and I usually drop
> using Darktable for those cases and switch to Natron, but this solution is
> far from perfect (I love Darktable for many reasons).
> 
> LUT transformation have to applied in pipeline after basic exposure and
> colour correction and before some other luma and colour corrections.

Well, there are several places where a LUT can be applied. Once in the 
beginning, to get you recorded video data to a known state (kind of replaces 
input color profile), then there are final looks LUTs that are to be applied in 
the very end (to make the linear pixels look ok, adding a gamma curve and 
maybe some film emulation, so basically the final grading). And then there are 
intermediate ones like you ask for.

We discussed that a few times internally and while I would like to support 
that, there is the problem of WHERE to have such a module in the pipe. Or if 
we should add LUT support in a single new module plus the the input/output 
color profile modules? So many options ... If you have more insight I would 
like to hear about it.

> AFAIK, ready to use implementation of this transformation is provided by
> OpenColorIO library via LookTransform function. It is used in most
> compositing programs (like Natron, Fusion, Nuke) and reads all popular file
> formats (3dl, cube, csp...)

I wouldn't like to add that dependency as it's a rather big one and somewhat 
opposed to the ICC based workflow we use. But we don't need it anyway, I 
already have written some test code that reads cube files and applies them.

> A have created issue for this https://redmine.darktable.org/issues/11217
> 
> Was there in the past any discussion about such iop?

Tobias

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] [feature request] overlay of multiple pictures

[jeremy rosen]

I implemented such a module quite some time ago, it's not very hard

more like an "advanced tutorial" for coding your own module.
The idea was to create a module that would replace the pixels from your
current image with pixels from another pipeline and then exploit
multi-instance and parametric masks to do some crazy things

problem, as usual, is in the details. You need to deal with cycles, image
management etc... and I'm already doing all the lua stuf...

I still think this is overall a good idea and like to see it coming
it's a very "DT" way of dealing with the kind of things other software do
using layers

On Fri, Apr 8, 2016 at 3:29 PM, Matthias Bodenbinder <
matth...@bodenbinder.de> wrote:

> Hi
>
> I am wondering if it would be possible to provide a module for DT that
> allows the loading of other pictures to overlay them with the active
> picture. This is basically similar to what the watermark module is doing
> but more generic.
>
> The use case would be, for example, if I want to replace a dull sky in a
> landscape picture with a blue sky from a different picture. I have seen
> examples where this scenario is accompished by "mis-using" the watermark
> modul.
>
> It would be nice if DT had a dedicated modul for that where PNG, JPG and
> TIF pictures could be loaded, re-scaled, moved and masked.
>
> Matthias
>
> ___
> 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] Feature request: Built in timelapsing

[Dave]

Hi.
Would it be possible to apply masks to your time-lapse tool?
I'm no coder but I'm seriously impressed by your video.

Regards
Dave

On Wed, 16 Dec 2015 22:19 Alexandre Jullien  wrote:

> Cool ! I'm highly interested.
>
> I've made an external tool 2 years ago (timelapse-darktable)... But not
> enough time/skills to integrate it in darktable... And maintain it.
>
> Question:
> Is the exposure compensation also compatible with new auto deflickering
> module ?
>
> Cheers
>
> Alexandre
>
> Le mer. 16 déc. 2015 20:11, Tobias Ellinghaus  a écrit :
>
>> Am Mittwoch, 16. Dezember 2015, 10:29:41 schrieb Tamas Feher:
>> > ​
>> > Hi
>> > ​​,
>>
>> Hi.
>>
>> > to process my timelapse sequences, i've coded an extension for
>> darktable.
>> >
>> > Some screenplay: https://www.youtube.com/watch?v=vUGtla-q8OE
>> >
>> > It automatically reading out exif-data and equalize differences in iso,
>> > aperture and exposure and then adjust the exposure-module for a smooth
>> > ramping.
>> >
>> > Please discuss it and tell me whether could be integrated in darktable?
>>
>> The video looks nice. Could you share the code? Maybe you would also like
>> to
>> join us in IRC (#darktable on FreeNode) for in depth discussions once we
>> had a
>> chance to see how you did it.
>>
>> > Bye,
>> > Tamás
>>
>> Tobias
>
>
> ___
> 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] Feature request: Built in timelapsing

[Alexandre Jullien]

Cool ! I'm highly interested.

I've made an external tool 2 years ago (timelapse-darktable)... But not
enough time/skills to integrate it in darktable... And maintain it.

Question:
Is the exposure compensation also compatible with new auto deflickering
module ?

Cheers

Alexandre

Le mer. 16 déc. 2015 20:11, Tobias Ellinghaus  a écrit :

> Am Mittwoch, 16. Dezember 2015, 10:29:41 schrieb Tamas Feher:
> > ​
> > Hi
> > ​​,
>
> Hi.
>
> > to process my timelapse sequences, i've coded an extension for darktable.
> >
> > Some screenplay: https://www.youtube.com/watch?v=vUGtla-q8OE
> >
> > It automatically reading out exif-data and equalize differences in iso,
> > aperture and exposure and then adjust the exposure-module for a smooth
> > ramping.
> >
> > Please discuss it and tell me whether could be integrated in darktable?
>
> The video looks nice. Could you share the code? Maybe you would also like
> to
> join us in IRC (#darktable on FreeNode) for in depth discussions once we
> had a
> chance to see how you did it.
>
> > Bye,
> > Tamás
>
> Tobias

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

Re: [darktable-dev] Feature request: Built in timelapsing

[Tobias Ellinghaus]

Am Mittwoch, 16. Dezember 2015, 10:29:41 schrieb Tamas Feher:
> ​
> Hi
> ​​,

Hi.

> to process my timelapse sequences, i've coded an extension for darktable.
> 
> Some screenplay: https://www.youtube.com/watch?v=vUGtla-q8OE
> 
> It automatically reading out exif-data and equalize differences in iso,
> aperture and exposure and then adjust the exposure-module for a smooth
> ramping.
> 
> Please discuss it and tell me whether could be integrated in darktable?

The video looks nice. Could you share the code? Maybe you would also like to 
join us in IRC (#darktable on FreeNode) for in depth discussions once we had a 
chance to see how you did it.

> Bye,
> Tamás

Tobias

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Feature request: preserve luminosity option in channel mixer

[Caio S. Souza]

The code for hue is:

hmix = CLIP(in[0] * data->red[CHANNEL_HUE]) + (in[1] * data->green[CHANNEL_HUE])
 + (in[2] * data->blue[CHANNEL_HUE]);

'in' is the input pixel array. The code basically just multiply the
red, green and blue channels by the weights in 'data' and sum them up.
As you can see, the CLIP is applied only to the red transformation. If
the green or blue calculations results are out of range (< 0 or > 1),
the final result will be out of range. It is the same for the
saturation (smix) and lightness (lmix).
Further in the code we have this line:

rmix = CLIP((out[0] * data->red[CHANNEL_RED]) + (out[1] *
data->green[CHANNEL_RED])
+ (out[2] * data->blue[CHANNEL_RED]));

Here a similar calculation is done, but this time the CLIP macro is
applied to the final result, not only to the red piece. It is the same
for the gray (graymix), green(gmix) and blue (bmix).
So was it on purpose to clip only part of the calculation?

Cheers

--
Caio S. Souza
Laboratório de Biologia Teórica e Computacional
Universidade de Brasília
www.lbtc.unb.br


2015-11-27 8:30 GMT-02:00 Tobias Ellinghaus :
> Am Donnerstag, 26. November 2015, 22:48:26 schrieb Caio S. Souza:
>> Hello!
>
> Hi.
>
>> I'm almost done implementing this feature, but I have two questions.
>> 1) I had to add one entry to the struct dt_iop_channelmixer_params_t
>> to store where the correction must be applied. Should I increment the
>> version in the DT_MODULE_INTROSPECTION macro?
>
> Yes.
>
>> 2) The final outputs of red, green, blue and gray channels are clipped
>> to avoid out of range values. But the clip is applied only partially
>> for the hue, lightness and saturation (on both CPU and opencl
>> versions). Was it on purpose or is it a bug?
>
> I haven't looked at the code, but in general we should try to avoid clipping
> wherever possible.
>
>> Cheers
>
> Tobias
>
> [...]
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Feature request: preserve luminosity option in channel mixer

[Tobias Ellinghaus]

Am Donnerstag, 26. November 2015, 22:48:26 schrieb Caio S. Souza:
> Hello!

Hi.

> I'm almost done implementing this feature, but I have two questions.
> 1) I had to add one entry to the struct dt_iop_channelmixer_params_t
> to store where the correction must be applied. Should I increment the
> version in the DT_MODULE_INTROSPECTION macro?

Yes.

> 2) The final outputs of red, green, blue and gray channels are clipped
> to avoid out of range values. But the clip is applied only partially
> for the hue, lightness and saturation (on both CPU and opencl
> versions). Was it on purpose or is it a bug?

I haven't looked at the code, but in general we should try to avoid clipping 
wherever possible.

> Cheers

Tobias

[...]

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Feature request: preserve luminosity option in channel mixer

[Caio S. Souza]

Hello!
I'm almost done implementing this feature, but I have two questions.
1) I had to add one entry to the struct dt_iop_channelmixer_params_t
to store where the correction must be applied. Should I increment the
version in the DT_MODULE_INTROSPECTION macro?
2) The final outputs of red, green, blue and gray channels are clipped
to avoid out of range values. But the clip is applied only partially
for the hue, lightness and saturation (on both CPU and opencl
versions). Was it on purpose or is it a bug?

Cheers
--
Caio S. Souza
Laboratório de Biologia Teórica e Computacional
Universidade de Brasília
www.lbtc.unb.br


2015-11-23 17:38 GMT-02:00 Caio S. Souza :
> Sorry for the HTML!
> The problem is on how to change the value of the module's slider
> before doing the computation. The effect still have to be applied to
> the pixels, replacing the old ones. The "preserve lightness" option
> would only rescale the chosen values in a way that preserve the
> overall lightness. I played a little with the blending operator and it
> seems it's not the same (am I doing something wrong?). It helps to
> scale down the lightness when the module's output is set to any kind
> of color information. But it doesn't help on a grayscale conversion.
> Furthermore it becomes difficult to know exactly what value to apply
> to the blending opacity in order to keep the original lightness.
> For a better explanation of this feature, see the topics "Preserve
> Luminosity" and mainly the "In Monochrome mode" from
> https://docs.gimp.org/en/plug-in-colors-channel-mixer.html.
> Please, let me know if there is another way to achieve this effect.
>
> Cheers
> --
> Caio S. Souza
> Laboratório de Biologia Teórica e Computacional
> Universidade de Brasília
> www.lbtc.unb.br
>
>
> 2015-11-23 6:12 GMT-02:00 Roman Lebedev :
>> On Mon, Nov 23, 2015 at 1:44 AM, Caio S. Souza  wrote:
>>> Hello,
>>> To preserve luminosity when using the Channel Mixer module one must be
>>> careful in choosing values for the red, green and blue sliders such that
>>> their sum equals 1. If we need to change the sliders values a lot (e.g. when
>>> experimenting with their importance on a black and white conversion), it
>>> becomes very slow and painfull to drag all others sliders appropriately to
>>> keep the overall luminosity. Mainly when you use differents values for
>>> different parts of a single image. It would be much faster and easier to
>>> have an option to keep the image luminosity, like in Gimp's channel mixer
>>> (https://docs.gimp.org/en/plug-in-colors-channel-mixer.html). This is
>>> relatively easy to implement: we just need to divide the computed value by
>>> the sum of the three chosen weights.
>>> I took a look at this module's source code and identified the pieces that
>>> must be changed (including the opencl kernel). If you agree this feature is
>>> a good idea, I may help implementing it. What do you think?
>>>
>>
>> 0. html mail is bad :)
>> 1. some blending operator is the solution here, i believe.
>> have you tried, e.g. color/Lab color/HSV color ?
>>
>>> Cheers
>>> --
>>> Caio S. Souza
>> Roman.
>>
>>> Laboratório de Biologia Teórica e Computacional
>>> Universidade de Brasília
>>> www.lbtc.unb.br
>>>
>>> ___
>>> 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] Feature request: camera model in export module

[Šarūnas Burdulis]

On 11/20/2015 04:33 PM, Pedro Côrte-Real wrote:
> On Fri, Nov 20, 2015 at 8:54 PM, Šarūnas Burdulis
>  wrote:
>> would someone care to take a look at the attached patch? It ads
>> $(EXIF_MODEL) to recognized variables in the export to files on disk
>> file naming field. I used darktable-org/darktable master branch to start
>> with.
> 
> Is exif_model actually what you want? Here's what's in the img struct:
> 
> exif_make: the camera make exactly as reported in EXIF (cameras from
> the same manufacturer will have slightly different values)
> exif_model: the model exactly as reported in EXIF (often the maker is
> also in the model)
> camera_make: the camera make cleaned up (no needlessly long names, all
> cameras will report the same)
> camera_model: the camera model cleaned up (no needlessly long names,
> if there are aliases the base name is used so "EOS REBEL SL1" becomes
> "EOS 100D")
> camera_alias: same as before but the alias is used (so "EOS REBEL SL1"
> stays that way)
> [...]

I just made a pull request on GitHub to add MAKER and MODEL using
img->camera_maker and img->camera_model. It's a minor patch.

Thanks for considering it.

-- 
Šarūnas Burdulis
http://math.dartmouth.edu/~sarunas
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Feature request: camera model in export module

[Tobias Ellinghaus]

Am Freitag, 20. November 2015, 23:40:47 schrieb Pedro Côrte-Real:

[...]

> As for submitting the patch ideally you'd do a pull request on github.
> It's easier to review there and that way you actually get credited in
> the commit history. If that's too inconvenient a patch attached to
> email as you've already done also works.

As long as patches are created using "git format-patch" the credits are not a 
problem.

> Cheers,
> 
> Pedro

Tobias

signature.asc
Description: This is a digitally signed message part.

Re: [darktable-dev] Feature request: preserve luminosity option in channel mixer

[Caio S. Souza]

Sorry for the HTML!
The problem is on how to change the value of the module's slider
before doing the computation. The effect still have to be applied to
the pixels, replacing the old ones. The "preserve lightness" option
would only rescale the chosen values in a way that preserve the
overall lightness. I played a little with the blending operator and it
seems it's not the same (am I doing something wrong?). It helps to
scale down the lightness when the module's output is set to any kind
of color information. But it doesn't help on a grayscale conversion.
Furthermore it becomes difficult to know exactly what value to apply
to the blending opacity in order to keep the original lightness.
For a better explanation of this feature, see the topics "Preserve
Luminosity" and mainly the "In Monochrome mode" from
https://docs.gimp.org/en/plug-in-colors-channel-mixer.html.
Please, let me know if there is another way to achieve this effect.

Cheers
--
Caio S. Souza
Laboratório de Biologia Teórica e Computacional
Universidade de Brasília
www.lbtc.unb.br


2015-11-23 6:12 GMT-02:00 Roman Lebedev :
> On Mon, Nov 23, 2015 at 1:44 AM, Caio S. Souza  wrote:
>> Hello,
>> To preserve luminosity when using the Channel Mixer module one must be
>> careful in choosing values for the red, green and blue sliders such that
>> their sum equals 1. If we need to change the sliders values a lot (e.g. when
>> experimenting with their importance on a black and white conversion), it
>> becomes very slow and painfull to drag all others sliders appropriately to
>> keep the overall luminosity. Mainly when you use differents values for
>> different parts of a single image. It would be much faster and easier to
>> have an option to keep the image luminosity, like in Gimp's channel mixer
>> (https://docs.gimp.org/en/plug-in-colors-channel-mixer.html). This is
>> relatively easy to implement: we just need to divide the computed value by
>> the sum of the three chosen weights.
>> I took a look at this module's source code and identified the pieces that
>> must be changed (including the opencl kernel). If you agree this feature is
>> a good idea, I may help implementing it. What do you think?
>>
>
> 0. html mail is bad :)
> 1. some blending operator is the solution here, i believe.
> have you tried, e.g. color/Lab color/HSV color ?
>
>> Cheers
>> --
>> Caio S. Souza
> Roman.
>
>> Laboratório de Biologia Teórica e Computacional
>> Universidade de Brasília
>> www.lbtc.unb.br
>>
>> ___
>> 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] Feature request: preserve luminosity option in channel mixer

[Roman Lebedev]

On Mon, Nov 23, 2015 at 1:44 AM, Caio S. Souza  wrote:
> Hello,
> To preserve luminosity when using the Channel Mixer module one must be
> careful in choosing values for the red, green and blue sliders such that
> their sum equals 1. If we need to change the sliders values a lot (e.g. when
> experimenting with their importance on a black and white conversion), it
> becomes very slow and painfull to drag all others sliders appropriately to
> keep the overall luminosity. Mainly when you use differents values for
> different parts of a single image. It would be much faster and easier to
> have an option to keep the image luminosity, like in Gimp's channel mixer
> (https://docs.gimp.org/en/plug-in-colors-channel-mixer.html). This is
> relatively easy to implement: we just need to divide the computed value by
> the sum of the three chosen weights.
> I took a look at this module's source code and identified the pieces that
> must be changed (including the opencl kernel). If you agree this feature is
> a good idea, I may help implementing it. What do you think?
>

0. html mail is bad :)
1. some blending operator is the solution here, i believe.
have you tried, e.g. color/Lab color/HSV color ?

> Cheers
> --
> Caio S. Souza
Roman.

> Laboratório de Biologia Teórica e Computacional
> Universidade de Brasília
> www.lbtc.unb.br
>
> ___
> 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] Feature request: preserve luminosity option in channel mixer

[Moritz Moeller]

On 22/11/15 23:44, Caio S. Souza wrote:

I took a look at this module's source code and identified the pieces
that must be changed (including the opencl kernel). If you agree this
feature is a good idea, I may help implementing it. What do you think?


+1

.mm

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

Re: [darktable-dev] Feature request: camera model in export module

[Pedro Côrte-Real]

On Fri, Nov 20, 2015 at 10:29 PM, Šarūnas Burdulis
 wrote:
> Frankly, I didn't even think about what else might be available in img
> struct. So yes, let's use whichever element looks best for showing the
> camera model in most of the cases (I only tested with files from Olympus
> E-M5 and Moto X cameraphone).

Those are probably saner than most. Depending on manufacturer the exif
model will include or not include the manufacturer name so the exif
names are not ideal for most user-facing purposes.

> Is the patch itself OK, i.e. is it the way this option should be added?
> Do you want me to resend a patch with 'camera_make'?

I only had a very quick look but it seemed fine to me. I'd say the we
should either use camera_makermodel (which has camera_maker+"
"+camera_model) or do camera_maker+" "+camera_alias as that's the
commercial name for the specific camera. Calling that
$(CAMERA_MAKERMODEL) or even just $(CAMERA) makes more sense than
using EXIF_ as these are not really the values straight from the exif.

As for submitting the patch ideally you'd do a pull request on github.
It's easier to review there and that way you actually get credited in
the commit history. If that's too inconvenient a patch attached to
email as you've already done also works.

Cheers,

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

Re: [darktable-dev] Feature request: camera model in export module

[Šarūnas Burdulis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/20/2015 05:29 PM, Šarūnas Burdulis wrote:
> On 11/20/2015 04:33 PM, Pedro Côrte-Real wrote:
>> On Fri, Nov 20, 2015 at 8:54 PM, Šarūnas Burdulis
>>  wrote:
>>> would someone care to take a look at the attached patch? It ads
>>> $(EXIF_MODEL) to recognized variables in the export to files on disk
>>> file naming field. I used darktable-org/darktable master branch to start
>>> with.
> 
>> Is exif_model actually what you want? Here's what's in the img struct:
> 
>> exif_make: the camera make exactly as reported in EXIF (cameras from
>> the same manufacturer will have slightly different values)
>> exif_model: the model exactly as reported in EXIF (often the maker is
>> also in the model)
>> camera_make: the camera make cleaned up (no needlessly long names, all
>> cameras will report the same)
>> camera_model: the camera model cleaned up (no needlessly long names,
>> if there are aliases the base name is used so "EOS REBEL SL1" becomes
>> "EOS 100D")
>> camera_alias: same as before but the alias is used (so "EOS REBEL SL1"
>> stays that way)
> 
>> Depending on what you want to do some are better than others. I
>> suspect camera_make and camera_alias are actually better for most
>> purposes and is what we show in the interface.
> 
> Pedro, thanks for a quick reply.
> 
> Frankly, I didn't even think about what else might be available in img
> struct. So yes, let's use whichever element looks best for showing the
> camera model in most of the cases (I only tested with files from Olympus
> E-M5 and Moto X cameraphone).
> 
> Is the patch itself OK, i.e. is it the way this option should be added?
> Do you want me to resend a patch with 'camera_make'?

Sorry, I meant 'camera_model'.

Šarūnas


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZPnzMACgkQVVkpJ1MUn+b/uQCdGNRbFw58yZPyj/K5ORMZ2g3G
K4UAnjJp1O7iA2ITrkMJCFGKi7HoPkS7
=KkxM
-END PGP SIGNATURE-
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Feature request: camera model in export module

[Šarūnas Burdulis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/20/2015 04:33 PM, Pedro Côrte-Real wrote:
> On Fri, Nov 20, 2015 at 8:54 PM, Šarūnas Burdulis
>  wrote:
>> would someone care to take a look at the attached patch? It ads
>> $(EXIF_MODEL) to recognized variables in the export to files on disk
>> file naming field. I used darktable-org/darktable master branch to start
>> with.
> 
> Is exif_model actually what you want? Here's what's in the img struct:
> 
> exif_make: the camera make exactly as reported in EXIF (cameras from
> the same manufacturer will have slightly different values)
> exif_model: the model exactly as reported in EXIF (often the maker is
> also in the model)
> camera_make: the camera make cleaned up (no needlessly long names, all
> cameras will report the same)
> camera_model: the camera model cleaned up (no needlessly long names,
> if there are aliases the base name is used so "EOS REBEL SL1" becomes
> "EOS 100D")
> camera_alias: same as before but the alias is used (so "EOS REBEL SL1"
> stays that way)
> 
> Depending on what you want to do some are better than others. I
> suspect camera_make and camera_alias are actually better for most
> purposes and is what we show in the interface.

Pedro, thanks for a quick reply.

Frankly, I didn't even think about what else might be available in img
struct. So yes, let's use whichever element looks best for showing the
camera model in most of the cases (I only tested with files from Olympus
E-M5 and Moto X cameraphone).

Is the patch itself OK, i.e. is it the way this option should be added?
Do you want me to resend a patch with 'camera_make'?

Thanks!
Šarūnas


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZPntYACgkQVVkpJ1MUn+ZoMgCgiQOxauw0zdUZK7sF0JrXA8OB
QyIAn0FAEE5NgpPRTx4wVN7fpHf2i4up
=2BfH
-END PGP SIGNATURE-
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Feature request: camera model in export module

[Pedro Côrte-Real]

On Fri, Nov 20, 2015 at 8:54 PM, Šarūnas Burdulis
 wrote:
> would someone care to take a look at the attached patch? It ads
> $(EXIF_MODEL) to recognized variables in the export to files on disk
> file naming field. I used darktable-org/darktable master branch to start
> with.

Is exif_model actually what you want? Here's what's in the img struct:

exif_make: the camera make exactly as reported in EXIF (cameras from
the same manufacturer will have slightly different values)
exif_model: the model exactly as reported in EXIF (often the maker is
also in the model)
camera_make: the camera make cleaned up (no needlessly long names, all
cameras will report the same)
camera_model: the camera model cleaned up (no needlessly long names,
if there are aliases the base name is used so "EOS REBEL SL1" becomes
"EOS 100D")
camera_alias: same as before but the alias is used (so "EOS REBEL SL1"
stays that way)

Depending on what you want to do some are better than others. I
suspect camera_make and camera_alias are actually better for most
purposes and is what we show in the interface.

Cheers,

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

Re: [darktable-dev] Feature request: camera model in export module

[Šarūnas Burdulis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/19/2015 02:39 PM, Šarūnas Burdulis wrote:
> Hello,
> 
> Would it be possible to make camera model variable, e.g. $(EXIF_MODEL),
> available in lighttable > export > storage options?

Hello, developers,
would someone care to take a look at the attached patch? It ads
$(EXIF_MODEL) to recognized variables in the export to files on disk
file naming field. I used darktable-org/darktable master branch to start
with.

Sorry if this is not how it should be done. Too many years have passed
since I have written anything in C, and this is the first time I looked
at the darktable source.

Best,
- -- 
Šarūnas Burdulis
http://math.dartmouth.edu/~sarunas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZPiJ4ACgkQVVkpJ1MUn+b9YQCfXcpKSjzfHI80CZCshUqLEGKZ
nZMAn3Ua5s8RK8cJwYmjch842Su8r+Qj
=C/dd
-END PGP SIGNATURE-

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org>From 915c74abcfe308fac32e09bb0509bbd2d979c71f Mon Sep 17 00:00:00 2001
From: sarunasb 
Date: Fri, 20 Nov 2015 15:39:09 -0500
Subject: [PATCH] Ads $(EXIF_MODEL) variable to the list of recognized
 variables while exporting to files on disk.

---
 src/common/variables.c | 4 
 src/gui/gtkentry.c | 1 +
 2 files changed, 5 insertions(+)

diff --git a/src/common/variables.c b/src/common/variables.c
index 62aa3ef..423ce5e 100644
--- a/src/common/variables.c
+++ b/src/common/variables.c
@@ -117,6 +117,7 @@ gboolean _variable_get_value(dt_variables_params_t *params, gchar *variable, gch
   /* image exif time */
   gboolean have_exif_tm = FALSE;
   int exif_iso = 100;
+  char exif_model[64];
   int version = 0;
   int stars = 0;
   struct tm exif_tm = { 0 };
@@ -131,6 +132,7 @@ gboolean _variable_get_value(dt_variables_params_t *params, gchar *variable, gch
   have_exif_tm = TRUE;
 }
 exif_iso = img->exif_iso;
+g_strlcpy(exif_model, img->exif_model, sizeof(exif_model));
 version = img->version;
 stars = (img->flags & 0x7);
 if(stars == 6) stars = -1;
@@ -165,6 +167,8 @@ gboolean _variable_get_value(dt_variables_params_t *params, gchar *variable, gch
 snprintf(value, value_len, "%.2d", (have_exif_tm ? exif_tm.tm_sec : tim->tm_sec));
   else if(g_strcmp0(variable, "$(EXIF_ISO)") == 0 && (got_value = TRUE))
 snprintf(value, value_len, "%d", exif_iso);
+  else if(g_strcmp0(variable, "$(EXIF_MODEL)") == 0 && (got_value = TRUE))
+snprintf(value, value_len, "%s", exif_model);
   else if(g_strcmp0(variable, "$(ID)") == 0 && (got_value = TRUE))
 snprintf(value, value_len, "%d", params->imgid);
   else if(g_strcmp0(variable, "$(VERSION)") == 0 && (got_value = TRUE))
diff --git a/src/gui/gtkentry.c b/src/gui/gtkentry.c
index bee97d8..fa05d9a 100644
--- a/src/gui/gtkentry.c
+++ b/src/gui/gtkentry.c
@@ -203,6 +203,7 @@ const dt_gtkentry_completion_spec *dt_gtkentry_get_default_path_compl_list()
   { "EXIF_MINUTE", N_("$(EXIF_MINUTE) - EXIF minute") },
   { "EXIF_SECOND", N_("$(EXIF_SECOND) - EXIF second") },
   { "EXIF_ISO", N_("$(EXIF_ISO) - ISO value") },
+  { "EXIF_MODEL", N_("$(EXIF_MODEL) - camera model") },
   { "STARS", N_("$(STARS) - star rating") },
   { "LABELS", N_("$(LABELS) - colorlabels") },
   { "PICTURES_FOLDER", N_("$(PICTURES_FOLDER) - pictures folder") },
-- 
2.5.0