Virtual Lighttable and Darkroom

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Long mail deserves sum comments from me, the real deal darktable expert
user. ;)

28.09.2010 22:23, Olivier Tribout kirjoitti:
> 
> Hi,
> 
> - the lack of "spot removal" tool is a deal-breaker (discussed on irc)
> 

Open in GIMP button plz and some method for returning gimp result to
darktable :)

> 
> About other software:
> - for styles ("presets" in Lr and Aperture), it would be cool to have, 
> like in Aperture, a small preview of the effect applied on the current 
> image at the end of each line.
> So when the user open the "styles" list and hovers a line, a thumb shows 
> the results, had this style been applied to the current image (discussed 
> on irc)
Mmmmh.. nice to have, but needs sum moar speed.. I think there are more
vital things to do .. 1.0 feature? :)

> - handling of virtual copies: Lightroom does it really nice.

Yeah, darktable really needs this..

> 
> - it would be really great to have a shortcut that displays original 
> image at any moment (lt or dr but especially in dr). In aperture, that 
> function is called "master image" and can be used thanks to "m".
I like this, embedded jpeg or something similar with one button.. or
maybe return to version that has defaults enabled?

And then, let's add some other nice-to-haves.. "Loupe" function for
checking those fine details without zooming the whole picture...

some work with noise removal... DT is close to Lr, but there is still
room for improvement.

Please note this is not meant to be critical comment, I'm loving every
day with darktable.. I just want my best friend to be perfect.. ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyihzMACgkQksZpPwDgmoJJRQCfa4egfHhQn+l/2iCgsLJibHD2
gVgAn2Gz9XD/p/JitY7H/E8ZoAnyQoFp
=MtEe
-----END PGP SIGNATURE-----

On 09/29/2010 02:24 AM, Mikko Ruohola wrote:

> Open in GIMP button plz and some method for returning gimp result to
> darktable :)

What use? Darktable is floating point. Gimp is 8bit. It won't have 16bit
or float support before 3.0. Destroy all my data to remove a spot?

Maybe Krita could be a tmp. solution. But I think that work is better
spent on adding a spot removal tool to Darktable itself.
Maybe by taking some code from Gimp. ;)


.mm

On 9/29/10, Mikko Ruohola wrote:

>> - the lack of "spot removal" tool is a deal-breaker (discussed on irc)
>
> Open in GIMP button plz and some method for returning gimp result to
> darktable :)

I hope it was some sort of obscure joke :)

1. Heal brush in GIMP doesn't work properly. Everybody knows that.

2. Your changes in GIMP will be destructive, you won't be able to undo
them, and you will have to keep two files of same picture around.

Where's the sense in that? :)

Alexandre Prokoudine
http://libregraphicsworld.org

On Tue, Sep 28, 2010 at 10:23 PM, Olivier Tribout
<olivier.tribout@...> wrote:
>
> Hi,
>
> I spent last week-end with friends having Lightroom and Aperture and was
> able to play with both software a little, along with doing a short
> presentation of Darktable to the others.
> In this e-mail, there are some basics ideas that came in my mind as a
> basis for discussion.
>
> About darktable
> - globally: they were really impressed by darktable capabilities
> - they appreciate that an action could be in different ways
> (transforming into b&w, denoise, etc)
> - the lack of "spot removal" tool is a deal-breaker (discussed on irc)

Deal breaker? Not for me. Nice to have. The other day I had the idea
of suggesting DT team a video editing plugin given the fact that most
recent cameras can do video too (and of course frustrated that there's
no video editor for linux in the same league with DT for photo
processing) but then I thought of the consequences.

>
>
> About other software:
> - for styles ("presets" in Lr and Aperture), it would be cool to have,
> like in Aperture, a small preview of the effect applied on the current
> image at the end of each line.

Don't we have history as a way to preview an action and revert if we
don't like it? I use in OSX CaptureOne, didn't know Aperture and LR
had such "niceties". As someone recently wrote on the list, maybe it's
time for DT to follow it's own way rather then try to mimic all
features from commercial software. Between usability and kissing
client ass is a difference.

> So when the user open the "styles" list and hovers a line, a thumb shows
> the results, had this style been applied to the current image (discussed
> on irc)
>
> - 7 color labels (already in ToDo)
>
> - local enhancement (already on ToDo)
>
> - handling of virtual copies: Lightroom does it really nice. Virtual
> copies of an image (to test different developments) are grouped on the
> library and filmstrip, by using a frame having a darker color than the
> global UI one. They can be stacked also, so only one image is shown but
> with a flagged indicating that "x" virtual copies exist.
>
> - it would be really great to have a shortcut that displays original
> image at any moment (lt or dr but especially in dr). In aperture, that
> function is called "master image" and can be used thanks to "m".

Again, wouldn't this replicate a function of history?

On Wed, Sep 29, 2010 at 10:02 AM, andu novac <novac.andu@...> wrote:
[...]
>> - it would be really great to have a shortcut that displays original
>> image at any moment (lt or dr but especially in dr). In aperture, that
>> function is called "master image" and can be used thanks to "m".
>
> Again, wouldn't this replicate a function of history?

What that makes is show original image for comparison. We have that
with snapshots. Maybe we should include the option to show the full
image instead a split one. Using history for that is not optimal, as
you have to undo and then redo.




-- 
José Carlos García Sogo
   jcsogo@...

oh nice point, automatic create of a snapshot when entering Darktable
without history... or maybe with current history...

ofcourse the snapshot feature needs some changed.. maybe handels like in
clipping to give user oppertunity to show piece of snapshot onto original...
On 29 Sep 2010 10:09, "Jose Carlos Garcia Sogo" <jcsogo@...> wrote:
> On Wed, Sep 29, 2010 at 10:02 AM, andu novac <novac.andu@...> wrote:
> [...]
>>> - it would be really great to have a shortcut that displays original
>>> image at any moment (lt or dr but especially in dr). In aperture, that
>>> function is called "master image" and can be used thanks to "m".
>>
>> Again, wouldn't this replicate a function of history?
>
> What that makes is show original image for comparison. We have that
> with snapshots. Maybe we should include the option to show the full
> image instead a split one. Using history for that is not optimal, as
> you have to undo and then redo.
>
>
>
>
> --
> José Carlos García Sogo
>    jcsogo@...
>
>
------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> darktable-devel mailing list
> darktable-devel@...
> https://lists.sourceforge.net/lists/listinfo/darktable-devel

On 09/29/2010 10:02 AM, andu novac wrote:
> Don't we have history as a way to preview an action and revert if we
> don't like it? I use in OSX CaptureOne, didn't know Aperture and LR
> had such "niceties". As someone recently wrote on the list, maybe it's
> time for DT to follow it's own way rather then try to mimic all
> features from commercial software. Between usability and kissing
> client ass is a difference.

Please elaborate how the introduction of presets would impact usability
(negatively, I presume)?
If you don't need them, don't use them. If you do, they are utterly
convenient and useful (you can call most useful things "niceties"). E.g.
your computer's keyboard or the screen (why not use punch cards?).

Furthermore the poster asked for very /specific/ features, not to "mimic
/all/". In the interest of a constructive debate about this, I'd refrain
from using generalizations to make a point.

I've been a LR user since 1.0 and I can tell you that Adobe has done the
opposite of kissing the client's ass. Just one example: the perspective
correction tool was asked for by clients even before 1.0 was released
and it's only in 3.0, recently, years after the request was made.
Frankly, one of the reasons I love DT is that I will soon be able to
drop LR (that and the fact I don't have to boot into OSX any more).

The thing I very often use in LR is just copying of settings. You get a
huge panel with checkboxes for all parameters and tick those you need,
copy them, then paste them onto other images.

When you do fashion or product shoots, you often have a series of shots
requiring mostly the same settings. You tweak one shot for 20mins, the
all you need to do for the other 20 is to do a selective copy and adjust
one or two sliders.
This is a very common use case for people doing photography
professionally (i.e. to actually pay their rent).
I think DT needs to offer something in that area.

Both LR an Aperture have excellent usability. A team of usability
experts working on software like this and client feedback of several
years is hard to beat.
I'm always surprised when people, who don't do user interface
engineering professionally, think they can do better by just having an
idea how things "should" work.
When it comes to digital imaging or 3d software, I'd always copy from
the pro's, then divert from that based on user feedback and careful use
case evaluation. Not the other way around.
Human computer interface design is one of the hardest things to get
right, in software development.

Te short version: did you ever use LR or Aperture with the presets in a
professional context? No?
Maybe then just refrain from commenting on that very subject matter
until you did and can afford a valid option on how much this "nicety" is
needed. ;)

>> - it would be really great to have a shortcut that displays original
>> image at any moment (lt or dr but especially in dr). In aperture, that
>> function is called "master image" and can be used thanks to "m".
> 
> Again, wouldn't this replicate a function of history?

He asks for a shortcut, not new functionality.
So if there was a shortcut added, to view the unrolled history
instantly, that would do it (and I second this being useful to have).


.mm


-- 
moritz moeller
the /*jupiter jazz*/ group — algorists & polymaths
mercenaries of jupiter jazz ltd. — hong kong s.a.r.
 http://www.jupiter-jazz.com

2010/9/29 Moritz Moeller <realritz@...>:
> On 09/29/2010 10:02 AM, andu novac wrote:
>> Don't we have history as a way to preview an action and revert if we
>> don't like it? I use in OSX CaptureOne, didn't know Aperture and LR
>> had such "niceties". As someone recently wrote on the list, maybe it's
>> time for DT to follow it's own way rather then try to mimic all
>> features from commercial software. Between usability and kissing
>> client ass is a difference.
>
> Please elaborate how the introduction of presets would impact usability
> (negatively, I presume)?
> If you don't need them, don't use them. If you do, they are utterly
> convenient and useful (you can call most useful things "niceties"). E.g.
> your computer's keyboard or the screen (why not use punch cards?).
>
> Furthermore the poster asked for very /specific/ features, not to "mimic
> /all/". In the interest of a constructive debate about this, I'd refrain
> from using generalizations to make a point.
>
> I've been a LR user since 1.0 and I can tell you that Adobe has done the
> opposite of kissing the client's ass. Just one example: the perspective
> correction tool was asked for by clients even before 1.0 was released
> and it's only in 3.0, recently, years after the request was made.
> Frankly, one of the reasons I love DT is that I will soon be able to
> drop LR (that and the fact I don't have to boot into OSX any more).
>
> The thing I very often use in LR is just copying of settings. You get a
> huge panel with checkboxes for all parameters and tick those you need,
> copy them, then paste them onto other images.
>
> When you do fashion or product shoots, you often have a series of shots
> requiring mostly the same settings. You tweak one shot for 20mins, the
> all you need to do for the other 20 is to do a selective copy and adjust
> one or two sliders.
> This is a very common use case for people doing photography
> professionally (i.e. to actually pay their rent).
> I think DT needs to offer something in that area.
>
is the current copy/past of historystack not useful in this case ?
can it be improved ? what is the drawbacks ?

> Both LR an Aperture have excellent usability. A team of usability
> experts working on software like this and client feedback of several
> years is hard to beat.
> I'm always surprised when people, who don't do user interface
> engineering professionally, think they can do better by just having an
> idea how things "should" work.
> When it comes to digital imaging or 3d software, I'd always copy from
> the pro's, then divert from that based on user feedback and careful use
> case evaluation. Not the other way around.
> Human computer interface design is one of the hardest things to get
> right, in software development.
>
> Te short version: did you ever use LR or Aperture with the presets in a
> professional context? No?
> Maybe then just refrain from commenting on that very subject matter
> until you did and can afford a valid option on how much this "nicety" is
> needed. ;)
>
>>> - it would be really great to have a shortcut that displays original
>>> image at any moment (lt or dr but especially in dr). In aperture, that
>>> function is called "master image" and can be used thanks to "m".
>>
>> Again, wouldn't this replicate a function of history?
>
> He asks for a shortcut, not new functionality.
> So if there was a shortcut added, to view the unrolled history
> instantly, that would do it (and I second this being useful to have).
>
>
> .mm
>
>
> --
> moritz moeller
> the /*jupiter jazz*/ group — algorists & polymaths
> mercenaries of jupiter jazz ltd. — hong kong s.a.r.
> http://www.jupiter-jazz.com
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> darktable-devel mailing list
> darktable-devel@...
> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>

On 09/29/2010 04:09 PM, Henrik Andersson wrote:
> 2010/9/29 Moritz Moeller <realritz@...>:
>> When you do fashion or product shoots, you often have a series of shots
>> requiring mostly the same settings. You tweak one shot for 20mins, the
>> all you need to do for the other 20 is to do a selective copy and adjust
>> one or two sliders.
>> This is a very common use case for people doing photography
>> professionally (i.e. to actually pay their rent).
>> I think DT needs to offer something in that area.
>>
> is the current copy/past of historystack not useful in this case ?
> can it be improved ? what is the drawbacks ?

You want to be able to copy /specific/ settings, not a whole plugin
being applied.
I.e. only copy brightness but not contrast, only copy crop but not
rotation etc.

Here is screenshot of the relevant LR 'Copy Develop Settings...' dialog
that pops up.

.mm

2010/9/30 Moritz Moeller <realritz@...>:
> On 09/29/2010 04:09 PM, Henrik Andersson wrote:
>> 2010/9/29 Moritz Moeller <realritz@...>:
>>> When you do fashion or product shoots, you often have a series of shots
>>> requiring mostly the same settings. You tweak one shot for 20mins, the
>>> all you need to do for the other 20 is to do a selective copy and adjust
>>> one or two sliders.
>>> This is a very common use case for people doing photography
>>> professionally (i.e. to actually pay their rent).
>>> I think DT needs to offer something in that area.
>>>
>> is the current copy/past of historystack not useful in this case ?
>> can it be improved ? what is the drawbacks ?
>
> You want to be able to copy /specific/ settings, not a whole plugin
> being applied.
> I.e. only copy brightness but not contrast, only copy crop but not
> rotation etc.
>
ah ok, a finegrained control of what goes or not.. hmm... my first
thought is that is going to be messy... i want to see that screenshoot
of how it was solved in LR and it seems that you forgot to attach it...

> Here is screenshot of the relevant LR 'Copy Develop Settings...' dialog
> that pops up.
>
please attach the screenshoot...

> .mm
>

Henrik Andersson wrote:
> 2010/9/30 Moritz Moeller <realritz@...>:
>> On 09/29/2010 04:09 PM, Henrik Andersson wrote:
>>> 2010/9/29 Moritz Moeller <realritz@...>:
>>>> When you do fashion or product shoots, you often have a series of shots
>>>> requiring mostly the same settings. You tweak one shot for 20mins, the
>>>> all you need to do for the other 20 is to do a selective copy and adjust
>>>> one or two sliders.
>>>> This is a very common use case for people doing photography
>>>> professionally (i.e. to actually pay their rent).
>>>> I think DT needs to offer something in that area.
>>>>
>>> is the current copy/past of historystack not useful in this case ?
>>> can it be improved ? what is the drawbacks ?
>>
>> You want to be able to copy /specific/ settings, not a whole plugin
>> being applied.
>> I.e. only copy brightness but not contrast, only copy crop but not
>> rotation etc.
>>
> ah ok, a finegrained control of what goes or not.. hmm... my first
> thought is that is going to be messy... i want to see that screenshoot
> of how it was solved in LR and it seems that you forgot to attach it...
>


It can be done with Ctr+V - "paste all" and Ctrl+Shift+V - "display a dialog box with a dynamic set of checkboxes what to paste". Just the same for Ctrl+C vs. Ctrl+Shift+C  :)

With respect,
Alexander Rabtchevich

-- 
GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!*
http://portal.gmx.net/de/go/dsl

On 09/30/2010 01:50 AM, Moritz Moeller wrote:

> Here is screenshot of the relevant LR 'Copy Develop Settings...' dialog
> that pops up.

Ooops. :)
Here it is:
http://www.nikonians.org/html/resources/software/Adobe_digital_workflow/images/15_lr-quickdevelop-02.jpg

.mm

On 09/30/2010 01:30 PM, Moritz Moeller wrote:
> On 09/30/2010 01:50 AM, Moritz Moeller wrote:
> 
>> Here is screenshot of the relevant LR 'Copy Develop Settings...' dialog
>> that pops up.
> 
> Ooops. :)
> Here it is:
> http://www.nikonians.org/html/resources/software/Adobe_digital_workflow/images/15_lr-quickdevelop-02.jpg

This is a LR 1.0 one. It has become bigger in subsequent versions:

http://blogs.oreilly.com/lightroom/uploads/2008/05/Synchronize%20Settings.jpg

On Thu, Sep 30, 2010 at 8:31 AM, Moritz Moeller
<realritz@...> wrote:
> On 09/30/2010 01:30 PM, Moritz Moeller wrote:
>> On 09/30/2010 01:50 AM, Moritz Moeller wrote:
>>
>>> Here is screenshot of the relevant LR 'Copy Develop Settings...' dialog
>>> that pops up.
>>
>> Ooops. :)
>> Here it is:
>> http://www.nikonians.org/html/resources/software/Adobe_digital_workflow/images/15_lr-quickdevelop-02.jpg
>
> This is a LR 1.0 one. It has become bigger in subsequent versions:
>
> http://blogs.oreilly.com/lightroom/uploads/2008/05/Synchronize%20Settings.jpg
>

The way LR handles presets, copying of settings and setting
synchronization is one of the main advantages over other software, as
it improves a lot the workflow for adjusting hundreds (or thousands)
of photos. This is the main reason I'm still stuck to LR.

Rafael

http://www.rafaelfoto.com
Fotografia de Casamentos, Aniversários, Formaturas, Shows, Eventos
Esportivos, e festas em geral.

On Tue, Sep 28, 2010 at 6:24 PM, Mikko Ruohola <photos@...> wrote:
> 28.09.2010 22:23, Olivier Tribout kirjoitti:
>> - the lack of "spot removal" tool is a deal-breaker (discussed on irc)
>
> Open in GIMP button plz and some method for returning gimp result to
> darktable :)

I must stress emphatically that Gimp is a completely broken piece of
software and any attempt to integrate it into a darktable workflow
cannot be allowed. Here is why:

Your camera most likely produces RAW images containing 12 or 14 bit
color depth. You open these images in darktable, which manipulates
those colors in a nondestructive 32-bit color space, preserving all
original 12/14bit data. You then open this image in Gimp, which
immediately (before you've even done anything) clips the data to a
measly 8-bit colorspace, where you do some edits, and then save the
file, having lost a ton of important color data. What is darktable
supposed to do with that? It's garbage.

Perhaps once Gimp has completed it's integration of gegl we could
consider some kind of gimp/darktable hybrid workflow, but as it stands
now gimp is just worse than useless, because it actively and silently
destroys photographic information.

-- 
http://exolucere.ca

Dear Robert,

I'm not (completely) convinced.
Why not start with a warning (balloon) in Darktable
before anyone tries to redirect the improved image?

As long as Darktable doesn't posses layers or tools to improve local
it's up to the (amateur) photographer to do some finishing touch in Gimp.

regards Ger
  - http://www.gersiemerink.net -

On Sat, Oct 2, 2010 at 5:37 PM, G.Siemerink <g.siemerink@...> wrote:
> Dear Robert,
>
> I'm not (completely) convinced.
> Why not start with a warning (balloon) in Darktable
> before anyone tries to redirect the improved image?
>
> As long as Darktable doesn't posses layers or tools to improve local
> it's up to the (amateur) photographer to do some finishing touch in Gimp.

The bigger point is that you don't need 32bit floating point or for
that matter 16 bit integer accuracy to touch up some pimples/zits,
etc...

Regards,
Pascal de Bruijn

On Sat, Oct 2, 2010 at 9:40 AM, Pascal de Bruijn <pmjdebruijn@...> wrote:
> The bigger point is that you don't need 32bit floating point or for
> that matter 16 bit integer accuracy to touch up some pimples/zits,
> etc...

You're correct that 8-bit editing is sufficient for pimple removal,
but my point is that once you open the photo in Gimp, you've now lost
a significant amount of photographic information, which can then never
be recovered. There is no point whatsoever in taking a gimp-edited
photo and then re-opening it in darktable. If you must use Gimp, you
should do as much editing as possible inside darktable _first_, then
export a TIFF from darktable, and gimp all over that, and then export
directly to web/print/etc from gimp without bothering darktable with
this 8-bit file afterwards.

The other problem is that gimp editing is destructive editing, so you
need to maintain two copies of your files: the original RAW, and a
gimp-edited TIFF. But what if you want to go back and change some of
the darktable edits on the image? You have to throw out all the work
you did in gimp and then start over. Who wants to re-remove all the
pimples every time you make a slight edit with darktable? It's a
rubbish workflow. Darktable really needs clone/heal spot removal tools
like in lightroom, that is a godsend. On my mac, I almost never use
Photoshop these days because I do all necessary edits inside
lightroom.

-- 
http://exolucere.ca

Until Darktable will grow its own spot removal tools there is also
Cinepaint for 16bit editing of tiffs. The application is kind of
awkward but does a decent job.

On Sat, Oct 2, 2010 at 7:08 PM, Robert Park <rbpark@...> wrote:
> On Sat, Oct 2, 2010 at 9:40 AM, Pascal de Bruijn <pmjdebruijn@...> wrote:
>> The bigger point is that you don't need 32bit floating point or for
>> that matter 16 bit integer accuracy to touch up some pimples/zits,
>> etc...
>
> You're correct that 8-bit editing is sufficient for pimple removal,
> but my point is that once you open the photo in Gimp, you've now lost
> a significant amount of photographic information, which can then never
> be recovered. There is no point whatsoever in taking a gimp-edited
> photo and then re-opening it in darktable. If you must use Gimp, you
> should do as much editing as possible inside darktable _first_, then
> export a TIFF from darktable, and gimp all over that, and then export
> directly to web/print/etc from gimp without bothering darktable with
> this 8-bit file afterwards.
>
> The other problem is that gimp editing is destructive editing, so you
> need to maintain two copies of your files: the original RAW, and a
> gimp-edited TIFF. But what if you want to go back and change some of
> the darktable edits on the image? You have to throw out all the work
> you did in gimp and then start over. Who wants to re-remove all the
> pimples every time you make a slight edit with darktable? It's a
> rubbish workflow. Darktable really needs clone/heal spot removal tools
> like in lightroom, that is a godsend. On my mac, I almost never use
> Photoshop these days because I do all necessary edits inside
> lightroom.
>
> --
> http://exolucere.ca
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> darktable-devel mailing list
> darktable-devel@...
> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>

clear!!! I'm convinced.


Darktable really needs clone/heal spot removal tools
> like in lightroom, that is a godsend.
>

I agree with that

>
>
regards Ger

--

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/30/2010 03:40 PM, Rafael Jeffman wrote:
> On Thu, Sep 30, 2010 at 8:31 AM, Moritz Moeller
> <realritz@...> wrote:
>> On 09/30/2010 01:30 PM, Moritz Moeller wrote:
>>> On 09/30/2010 01:50 AM, Moritz Moeller wrote:
>>>
>>>> Here is screenshot of the relevant LR 'Copy Develop Settings...' dialog
>>>> that pops up.
>>>
>>> Ooops. :)
>>> Here it is:
>>> http://www.nikonians.org/html/resources/software/Adobe_digital_workflow/images/15_lr-quickdevelop-02.jpg
>>
>> This is a LR 1.0 one. It has become bigger in subsequent versions:
>>
>> http://blogs.oreilly.com/lightroom/uploads/2008/05/Synchronize%20Settings.jpg
>>
> 
> The way LR handles presets, copying of settings and setting
> synchronization is one of the main advantages over other software, as
> it improves a lot the workflow for adjusting hundreds (or thousands)
> of photos. This is the main reason I'm still stuck to LR.

hehe.. i hate this. :)

this means we have to move to the semantic annotation xml bloatware
dreggn serialization in the module parameters. with that, such a dialog
could be procedurally created for each new module.

but it can be done, and should probably extend the current ctrl-c ctrl-v
functionality, i agree.

- -j.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyq3ZgACgkQkuDaVvmNdriNIACgjSfBEFoXyCl3p0yowG2eN0lB
8ZMAnRma74YYJgR99bNy3RkxOLrhrYm2
=WiaQ
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/29/2010 10:02 AM, andu novac wrote:
> On Tue, Sep 28, 2010 at 10:23 PM, Olivier Tribout
> <olivier.tribout@...> wrote:
>> About other software:
>> - for styles ("presets" in Lr and Aperture), it would be cool to have,
>> like in Aperture, a small preview of the effect applied on the current
>> image at the end of each line.
> 
> Don't we have history as a way to preview an action and revert if we
> don't like it? I use in OSX CaptureOne, didn't know Aperture and LR
> had such "niceties". As someone recently wrote on the list, maybe it's
> time for DT to follow it's own way rather then try to mimic all
> features from commercial software. Between usability and kissing
> client ass is a difference.

i want to stress that i and a lot of our contributors have no
windoos/mac and also no lr/aperture in any virtual machine and have thus
never used/seen them at all.

jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyq3aIACgkQkuDaVvmNdrjCggCeKyRBA9Cxtr5UCy9zEH1J5u9i
FBwAn3tdEBMWs2GAnszpUB9HTZsVyl0P
=c5y+
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/29/2010 02:24 AM, Mikko Ruohola wrote:
[..]
>> - it would be really great to have a shortcut that displays original 
>> image at any moment (lt or dr but especially in dr). In aperture, that 
>> function is called "master image" and can be used thanks to "m".
> I like this, embedded jpeg or something similar with one button.. or
> maybe return to version that has defaults enabled?

well, we could bind 'm' to press 0 - original, take snapshot, enable
snapshot, go back to history_top.


> And then, let's add some other nice-to-haves.. "Loupe" function for
> checking those fine details without zooming the whole picture...

again the loupe? :) another thing i don't like, because i'm not going to
use it and it will eat resources. as dt processes it's pixels based on
what you see on screen (zoom ratio and region of interest), such a
plugin would need to create a separate pixelpipe, which needs:

- - at least one more thread for processing

- - a separate pixel buffer cache for the processing of the plugins

- - need to lock the history mutex whenever new parameters are pulled in.
while i'm sure we're not lock-contention bound yet, it will surely slow
things down.

with all that and the middle mouse button for 1:1-2:1-fit zoom cycling,
i think it's too much resources thrown at it.

but if somebody really wants it, go code a plugin.

- -j.



> 
> some work with noise removal... DT is close to Lr, but there is still
> room for improvement.
> 
> Please note this is not meant to be critical comment, I'm loving every
> day with darktable.. I just want my best friend to be perfect.. ;)

-
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
darktable-devel mailing list
darktable-devel@...
https://lists.sourceforge.net/lists/listinfo/darktable-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyq3Z0ACgkQkuDaVvmNdrhNOwCePsL3mv8kNYpdEmsNn/BJvxvj
CrEAniXSldodpefcN8ZszmTxHo9czq7M
=Ken0
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/02/2010 05:37 PM, G.Siemerink wrote:
> Dear Robert,
> 
> I'm not (completely) convinced.
> Why not start with a warning (balloon) in Darktable
> before anyone tries to redirect the improved image?
> 
> As long as Darktable doesn't posses layers or tools to improve local
> it's up to the (amateur) photographer to do some finishing touch in Gimp.

and of course the remove-trotzki button. please remember that dt is not
the gimp, and it is also not designed to exploit the full capabilities
of libraries such as gegl.

dt can't do non-linear editing (in the sense of webs of nodes of
operations with multiple input images, output images, arbitrary
operators in between, in arbitrary order)

this is because a lot of our operations are specifically targeted toward
raw development (demosaic, white balance, base curve) and only make
sense in this linear, fixed order.

dt is meant to make large-scale photo workflow (develop and organise
your 1000 shots quickly) feasible.

i don't want it to manipulate/falsify photographs or create new pieces
of artwork (via touch screen drawings etc).

this is also part of the keep-it-simple strategy. i very much believe
that too many too powerful features with too many small buttons too
close to each other result in unusable/hard to learn software. i really
like blender and it can solve all my 3d problems. but is it easy to use?

(spot removal sounds like a simple plugin though..)

- -j.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyq3dwACgkQkuDaVvmNdrhWugCfYSc+hFY9oyvEMIB48e+J+ds0
29oAoIwtce42rI80lXmAzKfJ+4ZV0DQ/
=jN7w
-----END PGP SIGNATURE-----

>i want to stress that i and a lot of our contributors have no
>windoos/mac and also no lr/aperture in any virtual machine and have thus
>never used/seen them at all.

Not missing much...

> this is also part of the keep-it-simple strategy. i very much believe
> that too many too powerful features with too many small buttons too
> close to each other result in unusable/hard to learn software.

I subscribe to this ideology unfriendly as it may sound.

WARNING: Braindump following!

Am Dienstag, 5. Oktober 2010 schrub johannes hanika:
> On 10/02/2010 05:37 PM, G.Siemerink wrote:
> > Dear Robert,
> > 
> > I'm not (completely) convinced.
> > Why not start with a warning (balloon) in Darktable
> > before anyone tries to redirect the improved image?
> > 
> > As long as Darktable doesn't posses layers or tools to improve local
> > it's up to the (amateur) photographer to do some finishing touch in Gimp.
> 
> and of course the remove-trotzki button. please remember that dt is not
> the gimp, and it is also not designed to exploit the full capabilities
> of libraries such as gegl.

Let me use this thread to write a few ideas I had regarding GIMP and other 
tools. Please keep in mind that I'm writing from the distant future where 
everything is as it should be, not as it happens to be.

In this world GIMP has reached a state where it's completely gegl based and 
non-destructive. It also supports arbitrary color spaces and bit depths. What 
that means in essence is that GIMP will construct a graph of gegl nodes which 
are stored together with the initial image data (plus some more fancy things 
which I'll ignore in our setting). To display the final image these nodes are 
applied to the image.

Another application which has moved to gegl will be darktable – we'll build a 
linear graph of gegl nodes which are stored together with the input image. I 
hope you see that it's basically the same thing as GIMP does.

My idea would be the following:

Add a GIMP-plugin to darktable. The special thing about this plugin is that it 
has no fixed place in the pipeline but can be inserted anywhere (drag&drop?). 
It can also be inserted several times in different places.
All it does is rendering the image up until the place in the pipeline where 
the GIMP plugin is inserted (full resolution pixel pipeline?), build some kind 
of minimal XCF file from it and pass it to GIMP. There the user can do his 
regular editing and save the file when he's done. This file has now a gegl 
graph which is extracted from the XCF file and inserted into our linear graph. 
This blob of nodes coming from GIMP will from now on be treated as a single 
node which can be turned on/off, removed, …
The GIMP plugin will also allow the user to re-open the file in GIMP: render 
the image, put it into an XCF file together with the blob of nodes, proceed as 
above.

I'm well aware that having a plugin at several places in the pipeline is far 
from ideal, but i guess there are use cases to have the possibility of editing 
anywhere in the pipeline. It has to go before monochrome if one needs color 
information from the image in GIMP, it has to be at the end to do $WHATEVER, …

> dt can't do non-linear editing (in the sense of webs of nodes of
> operations with multiple input images, output images, arbitrary
> operators in between, in arbitrary order)
> 
> this is because a lot of our operations are specifically targeted toward
> raw development (demosaic, white balance, base curve) and only make
> sense in this linear, fixed order.

That would still hold as our nodes would still be linear. The graphs coming 
from GIMP won't hurt.

> dt is meant to make large-scale photo workflow (develop and organise
> your 1000 shots quickly) feasible.
> 
> i don't want it to manipulate/falsify photographs or create new pieces
> of artwork (via touch screen drawings etc).
> 
> this is also part of the keep-it-simple strategy. i very much believe
> that too many too powerful features with too many small buttons too
> close to each other result in unusable/hard to learn software. i really
> like blender and it can solve all my 3d problems. but is it easy to use?
> 
> (spot removal sounds like a simple plugin though..)

When we are geglified I'd also like a way to save the whole gegl graph in a 
way accessible from GIMP.

> -j.

Tobias

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/05/2010 01:04 PM, Tobias Ellinghaus wrote:
> WARNING: Braindump following!
> 
> Am Dienstag, 5. Oktober 2010 schrub johannes hanika:
>> On 10/02/2010 05:37 PM, G.Siemerink wrote:
>>> Dear Robert,
>>>
>>> I'm not (completely) convinced.
>>> Why not start with a warning (balloon) in Darktable
>>> before anyone tries to redirect the improved image?
>>>
>>> As long as Darktable doesn't posses layers or tools to improve local
>>> it's up to the (amateur) photographer to do some finishing touch in Gimp.
>>
>> and of course the remove-trotzki button. please remember that dt is not
>> the gimp, and it is also not designed to exploit the full capabilities
>> of libraries such as gegl.
> 
> Let me use this thread to write a few ideas I had regarding GIMP and other 
> tools. Please keep in mind that I'm writing from the distant future where 
> everything is as it should be, not as it happens to be.
> 
> In this world GIMP has reached a state where it's completely gegl based and 
> non-destructive. It also supports arbitrary color spaces and bit depths. What 
> that means in essence is that GIMP will construct a graph of gegl nodes which 
> are stored together with the initial image data (plus some more fancy things 
> which I'll ignore in our setting). To display the final image these nodes are 
> applied to the image.
> 
> Another application which has moved to gegl will be darktable – we'll build a 
> linear graph of gegl nodes which are stored together with the input image. I 
> hope you see that it's basically the same thing as GIMP does.
> 
> My idea would be the following:
> 
> Add a GIMP-plugin to darktable. The special thing about this plugin is that it 
> has no fixed place in the pipeline but can be inserted anywhere (drag&drop?). 
> It can also be inserted several times in different places.
> All it does is rendering the image up until the place in the pipeline where 
> the GIMP plugin is inserted (full resolution pixel pipeline?), build some kind 
> of minimal XCF file from it and pass it to GIMP. There the user can do his 
> regular editing and save the file when he's done. This file has now a gegl 
> graph which is extracted from the XCF file and inserted into our linear graph. 
> This blob of nodes coming from GIMP will from now on be treated as a single 
> node which can be turned on/off, removed, …
> The GIMP plugin will also allow the user to re-open the file in GIMP: render 
> the image, put it into an XCF file together with the blob of nodes, proceed as 
> above.

the gegl interoperability part i like and think it's realistic (in 20
years..). which i'd like to exploit to make my point stronger:

you use dt to develop your images in 1000s in short time, organize them
and quickly find your archived images by collections.

when you're done with that, you can still (non-destructively) import the
linear processing pipe into gimp and make your fine tuning adjustments,
make people smile and power lines disappear.

after these finishing moves, i don't really see a reason to go back to dt?



> I'm well aware that having a plugin at several places in the pipeline is far 
> from ideal, but i guess there are use cases to have the possibility of editing 
> anywhere in the pipeline. It has to go before monochrome if one needs color 
> information from the image in GIMP, it has to be at the end to do $WHATEVER, …
> 
>> dt can't do non-linear editing (in the sense of webs of nodes of
>> operations with multiple input images, output images, arbitrary
>> operators in between, in arbitrary order)
>>
>> this is because a lot of our operations are specifically targeted toward
>> raw development (demosaic, white balance, base curve) and only make
>> sense in this linear, fixed order.
> 
> That would still hold as our nodes would still be linear. The graphs coming 
> from GIMP won't hurt.
> 
>> dt is meant to make large-scale photo workflow (develop and organise
>> your 1000 shots quickly) feasible.
>>
>> i don't want it to manipulate/falsify photographs or create new pieces
>> of artwork (via touch screen drawings etc).
>>
>> this is also part of the keep-it-simple strategy. i very much believe
>> that too many too powerful features with too many small buttons too
>> close to each other result in unusable/hard to learn software. i really
>> like blender and it can solve all my 3d problems. but is it easy to use?
>>
>> (spot removal sounds like a simple plugin though..)
> 
> When we are geglified I'd also like a way to save the whole gegl graph in a 
> way accessible from GIMP.

gegl has already some (unfinished, unstable) xml serialization code, so
done ;)

- -jo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyrB7EACgkQkuDaVvmNdrj0BACeKRn+N9reyBs9Oy16mi7UTRoS
aGQAn1iX+SGVBJRKzYd7NZYgS2leeVw4
=CCdz
-----END PGP SIGNATURE-----

On Tue, Oct 5, 2010 at 3:10 PM, johannes hanika wrote:

> the gegl interoperability part i like and think it's realistic (in 20
> years..). which i'd like to exploit to make my point stronger:
>
> you use dt to develop your images in 1000s in short time, organize them
> and quickly find your archived images by collections.
>
> when you're done with that, you can still (non-destructively) import the
> linear processing pipe into gimp and make your fine tuning adjustments,
> make people smile and power lines disappear.
>
> after these finishing moves, i don't really see a reason to go back to dt?

Because keeping stuff organized is the reason digital photography
workflow software exists.

Alexandre Prokoudine
http://libregraphicsworld.org

On Tue, Oct 5, 2010 at 8:10 AM, johannes hanika <hanatos@...> wrote:
>
> you use dt to develop your images in 1000s in short time, organize them
> and quickly find your archived images by collections.
>
> (...)
>
> after these finishing moves, i don't really see a reason to go back to dt?
>

After using DT to organize my images before retouching, why shouldn't
I still use its organization after retouching?

Rafael

http://www.rafaelfoto.com
Fotografia de Casamentos, Aniversários, Formaturas, Shows, Eventos
Esportivos, e festas em geral.

On 10/05/2010 01:10 PM, johannes hanika wrote:

> you use dt to develop your images in 1000s in short time, organize them
> and quickly find your archived images by collections.
> 
> when you're done with that, you can still (non-destructively) import the
> linear processing pipe into gimp and make your fine tuning adjustments,
> make people smile and power lines disappear.

Er, no. It is all bout the /when/.
For example, grading the image happens as the /last/ step in the
pipeline. And grading is mostly what DT is about.
Demoasicing happens /before/. Bringing the image into a neutral LUT
happens /before/.
Noise is symmetric. You remove noise /before/ warping around features of
an image, but add new noise /after/.

That's precisely one of the reasons why tools like LR have localized
editing facilities built in.


.mm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/05/2010 01:37 PM, Rafael Jeffman wrote:
> On Tue, Oct 5, 2010 at 8:10 AM, johannes hanika <hanatos@...> wrote:
>>
>> you use dt to develop your images in 1000s in short time, organize them
>> and quickly find your archived images by collections.
>>
>> (...)
>>
>> after these finishing moves, i don't really see a reason to go back to dt?
>>
> 
> After using DT to organize my images before retouching, why shouldn't
> I still use its organization after retouching?

right. AFTER retouching. so you don't need to go to dr mode anymore, so
no need for gimp/krita edits in form of o dt plugin..?

jo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyrEDkACgkQkuDaVvmNdrjF4gCcCMxG9r1dTAavYDepemx/xeUZ
OGQAnAj1/3xtqdwylOIB+PNpydXODs2D
=1j9c
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/05/2010 01:45 PM, Moritz Moeller wrote:
> On 10/05/2010 01:10 PM, johannes hanika wrote:
> 
>> you use dt to develop your images in 1000s in short time, organize them
>> and quickly find your archived images by collections.
>>
>> when you're done with that, you can still (non-destructively) import the
>> linear processing pipe into gimp and make your fine tuning adjustments,
>> make people smile and power lines disappear.
> 
> Er, no. It is all bout the /when/.
> For example, grading the image happens as the /last/ step in the
> pipeline. And grading is mostly what DT is about.
> Demoasicing happens /before/. Bringing the image into a neutral LUT
> happens /before/.
> Noise is symmetric. You remove noise /before/ warping around features of
> an image, but add new noise /after/.
> 
> That's precisely one of the reasons why tools like LR have localized
> editing facilities built in.

i don't get it i think. are you arguing for a fixed pipeline because
changing the order doesn't make sense? so why gimp?

and localized editing (in form of masking operations) is not a problem
in dt. we just need some draw-mask facility and multiply it for each
operation and apply it as a layer. that's somewhere in the todo list
already.

j.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyrENEACgkQkuDaVvmNdrg/1ACfQKUSuUZ9hX8TUva4R/FZbh+v
w4AAoJIKXLk1y8pzOHKPZLiJ2Nb+Ipsm
=hLCD
-----END PGP SIGNATURE-----

On 10/05/2010 01:47 PM, johannes hanika wrote:
>> After using DT to organize my images before retouching, why shouldn't
>> I still use its organization after retouching?
> 
> right. AFTER retouching. so you don't need to go to dr mode anymore, so
> no need for gimp/krita edits in form of o dt plugin..?
> 

You /never/ want to burn anything into an image. That's the whole idea
of a nondestructive work flow.
And it means no /real/ copies of images.

If I have a DT catalog which has both the images /before/ export for
editing and /after/ they are finalized, I have every image at least n+1
times in my catalog, for n differing edits. That sucks.

And /after retouching/ doesn't equal /after grading/. See my previous
comment.

That's the reason why LR has virtual copies. After all, in a
nondestructive editor, edits are just lightweight parameter vector metadata.

.mm

P.S.:
I think one of the main issues here is that many people have never
worked in professional environment using such tools. I can only suggest
looking at LR and Aperture.
You can't learn how to swim by reading a book.

On Tue, Oct 5, 2010 at 8:58 AM, Moritz Moeller <realritz@...> wrote:
> On 10/05/2010 01:47 PM, johannes hanika wrote:
>>> After using DT to organize my images before retouching, why shouldn't
>>> I still use its organization after retouching?
>>
>> right. AFTER retouching. so you don't need to go to dr mode anymore, so
>> no need for gimp/krita edits in form of o dt plugin..?
>>
>
> You /never/ want to burn anything into an image. That's the whole idea
> of a nondestructive work flow.
> And it means no /real/ copies of images.
>
> If I have a DT catalog which has both the images /before/ export for
> editing and /after/ they are finalized, I have every image at least n+1
> times in my catalog, for n differing edits. That sucks.
>
> And /after retouching/ doesn't equal /after grading/. See my previous
> comment.
>
> That's the reason why LR has virtual copies. After all, in a
> nondestructive editor, edits are just lightweight parameter vector metadata.
>

When editing in an external software in LR (i.e. Photoshop), LR does
not create a virtual copy, it creates another file, either a PSD or a
TIFF based on your current settings. You end up with two copies (which
can then have several virtual copies). The same might be applied to DT
(not that I'm asking it!).

I don't know/remember how Aperture works, as much as I liked it
(1.0/1.1), it is too slow for me.

>
> P.S.:
> I think one of the main issues here is that many people have never
> worked in professional environment using such tools. I can only suggest
> looking at LR and Aperture.
> You can't learn how to swim by reading a book.

No, but you can learn software by reading books, specially, seeing
tons of videos on youtube or on sites everywhere (for portuguese
speaking people I'd suggest the ones by Clicio Barroso at
http://www.clicio.com.br/blog/sobre-o-podcast/).

Rafael

http://www.rafaelfoto.com
Fotografia de Casamentos, Aniversários, Formaturas, Shows, Eventos
Esportivos, e festas em geral.

On 10/05/2010 01:49 PM, johannes hanika wrote:
> On 10/05/2010 01:45 PM, Moritz Moeller wrote:
>> That's precisely one of the reasons why tools like LR have localized
>> editing facilities built in.
> 
> i don't get it i think. are you arguing for a fixed pipeline because
> changing the order doesn't make sense? so why gimp?

Firstly, let me state that I will never touch Gimp with a ten foot pole
unless I have no choice. :)
I use commercial software (The Foundry's Nuke) for most of my editing
tasks and for grading I use LR (and more and more DT).
I know Photoshop inside out (I used it before it was even called
Photoshop) and I'm not a big fan of that software either. But as far as
destructive image editing goes, it is 2nd to none.

But back to your question: I'm not arguing for any of these tools.

There are just some things, like an overall grade or noise that are
/fixed/ in when they get applied. Editing (as in" moving pixels around)
is usually /not/ the final step.

> and localized editing (in form of masking operations) is not a problem
> in dt. we just need some draw-mask facility and multiply it for each
> operation and apply it as a layer. that's somewhere in the todo list
> already.

That is great. But a spot healing/removal tool is also needed. That set
would make most people happy, I think.

.mm

On 10/05/2010 02:08 PM, Rafael Jeffman wrote:

> When editing in an external software in LR (i.e. Photoshop), LR does
> not create a virtual copy, it creates another file, either a PSD or a
> TIFF based on your current settings. You end up with two copies (which
> can then have several virtual copies). The same might be applied to DT
> (not that I'm asking it!).

I'm not talking about editing in a destructive app like PS. It is
obvious that LR must create a real copy here since the connection is
lost (that's what 'destructive' means).

I'm talking about the fact that I can make 10 virtual copies and apply
all that LR offers differently to each.
Yet they are all linked to the original.

Now if my whole editing pipeline was metadata based, this would even
work with another app.


.mm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/05/2010 01:58 PM, Moritz Moeller wrote:
> On 10/05/2010 01:47 PM, johannes hanika wrote:
>>> After using DT to organize my images before retouching, why shouldn't
>>> I still use its organization after retouching?
>>
>> right. AFTER retouching. so you don't need to go to dr mode anymore, so
>> no need for gimp/krita edits in form of o dt plugin..?
>>
> 
> You /never/ want to burn anything into an image. That's the whole idea
> of a nondestructive work flow.
> And it means no /real/ copies of images.

no, you wouldn't. but starting gimp nd-edit (in 20 years from now), you
would just switch tools, as gegl ops would be 1:1 transferable from dt
to gimp. just different, more involved controls, hidden in an
all-powerful gui.


> If I have a DT catalog which has both the images /before/ export for
> editing and /after/ they are finalized, I have every image at least n+1
> times in my catalog, for n differing edits. That sucks.
> 
> And /after retouching/ doesn't equal /after grading/. See my previous
> comment.

grading as in rating?


> That's the reason why LR has virtual copies. After all, in a
> nondestructive editor, edits are just lightweight parameter vector metadata.

but we have virtual copies and parameter vector stuff? i'm still not
sure i see the direction of this discussion.. you want all gimp
reimplemented in dt?


> P.S.:
> I think one of the main issues here is that many people have never
> worked in professional environment using such tools. I can only suggest
> looking at LR and Aperture.
> You can't learn how to swim by reading a book.

hm. will it compile under gentoo? i started dt because they didn't. i'm
open for good ideas you want to transfer from proprietary stuff, but i'm
not going to use these tools.

j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyrFn0ACgkQkuDaVvmNdrhzhwCfcrimiErvLtf2wK/hMJjC8EPe
wpAAmgMjfT+t+tp1VGMn22NupvHmLpPv
=owx2
-----END PGP SIGNATURE-----

On 10/05/2010 02:13 PM, johannes hanika wrote:
> grading as in rating?

No, grading is the term used to refer to any sort of aesthetical color
correction. Usually an image is brought into a 'neutral grade', so are
all other images that need to be 'combined' with it (retouching).
Then the image is composed from these bits, then the final grade is applied.

>> That's the reason why LR has virtual copies. After all, in a
>> nondestructive editor, edits are just lightweight parameter vector metadata.
> 
> but we have virtual copies and parameter vector stuff? i'm still not
> sure i see the direction of this discussion.. you want all gimp
> reimplemented in dt?

No, by all means! :)
It would be great to have an app that does all what DT does and all that
Nuke does and some of what PS does. But we're years away from that.

All I'm arguing for is to not reject the possibility of having some
tools from Gimp/PS show up in DT.

E.g. spot removal/healing.

.mm

On Tue, Oct 5, 2010 at 3:13 PM, johannes hanika <hanatos@...> wrote:

>
> hm. will it compile under gentoo? i started dt because they didn't. i'm
> open for good ideas you want to transfer from proprietary stuff, but i'm
> not going to use these tools.
>
> j.

I think it all boils down to providing a few more tools (plugins) such
as healing/cloning, local adjustments, etc., the constant comparison
to LR or Aperture goes nowhere, they are not the ultimate solution for
everyone either.

On Tue, Oct 5, 2010 at 6:13 AM, johannes hanika <hanatos@...> wrote:
> but we have virtual copies and parameter vector stuff? i'm still not
> sure i see the direction of this discussion.. you want all gimp
> reimplemented in dt?

No, because Gimp is awful. However, consider this scenario:

You take some photos of a person with lots of acne. You use darktable
to process these photos (white balance, exposure, contrast, etc). Then
you export these images to tiff and spend 4 hours in Gimp with the
clone tool trying to remove all acne from the person.

THEN, some days later, you look back at your photos and realize "oh
no! I made a mistake in darktable! I need to go back and change the
exposure/contrast/etc"

Then what? Then once you finish fixing the photos in darktable, THEN
you have to spend ANOTHER 4 hours removing pimples in Gimp.

This is why darktable needs just some basic local editing tools such
as clone/heal, masking, etc, in the short term. Long term, Tobias'
idea of a gegl-gimp plugin for local edits sounds really nice, but I
won't hold my breath. I've already been waiting for gegl for 5 years.

-- 
http://exolucere.ca