Christian Kanzian píše v Út 03. 12. 2013 v 11:07 +0100:
> So I seppareted them into folders whereby I don't manage my RAWs with
> digikam.
That seems to be the safest way.
> I sort, rate, process and tag my RAWs with darktable and collect the
> exports in digikam, don't using the xmp files in dig
On Tuesday, December 03, 2013 01:04:50 AM Tobias Ellinghaus wrote:
> Am Montag, 2. Dezember 2013, 22:57:51 schrieb Simon Spannagel:
> > I actually thought darktable would write into the same XMP file using its
> > own name space. Therefore the two sets of information shouldn't interfere
> > beside
Am Mittwoch, 4. Dezember 2013, 10:24:47 schrieb Giacomo Catenazzi:
> On Tue, Dec 3, 2013 at 12:29 PM, Tobias Ellinghaus wrote:
> > Am Dienstag, 3. Dezember 2013, 10:12:49 schrieb Giacomo Catenazzi:
> > > (geotagging in dt still sucks; OTOH many other things sucks much more,
> > > in the other prog
On Tue, Dec 3, 2013 at 12:29 PM, Tobias Ellinghaus wrote:
> Am Dienstag, 3. Dezember 2013, 10:12:49 schrieb Giacomo Catenazzi:
> > (geotagging in dt still sucks; OTOH many other things sucks much more,
> > in the other programs)
>
> Bug reports and feature requests are welcome.
>
>
I don't want t
Am Dienstag, 3. Dezember 2013, 10:12:49 schrieb Giacomo Catenazzi:
> On Tue, Dec 3, 2013 at 9:17 AM, Pascal Obry wrote:
> > 2013/12/3 :
> > > All of which is to say: there is diversity in what people are trying to
> >
> > do.
> >
> > Right, I just wanted to be sure the whole dt workflow was und
> Workflows are very personal.
Of course, would be interesting how different they are.
I use digikam since 2004 as hoppyist, but didn't took care on any 'workflow'.
Starting processing RAWs in darktable last year, I quickly noticed that having
RAWs and exported JPGs in digikam is a nightmare.
On Tue, Dec 3, 2013 at 9:17 AM, Pascal Obry wrote:
> 2013/12/3 :
> > All of which is to say: there is diversity in what people are trying to
> do.
>
> Right, I just wanted to be sure the whole dt workflow was understood
> before trying to find something better :)
>
> I had some cases where peopl
2013/12/3 :
> All of which is to say: there is diversity in what people are trying to do.
Right, I just wanted to be sure the whole dt workflow was understood
before trying to find something better :)
I had some cases where people didn't take the necessary time to
understand and adapt to a new s
I use darktable and digikam together and have never had a problem. I use
digikam to import images from my cameras card, give the images a star rating in
digikam then open the folder they are in with darktable to do my processing.
Darktable displays the star rating I gave the image in digikam so
On 2013-12-02 davi...@frontier.com wrote:
> A raw file keeps all of our options open: We can at any time produce a
> small jpg for a slide show or sell a giant print from a tiff.
...and nobody is trying to take that away from you. It just isn't a
consideration for some people; selling giant prin
Le 03/12/2013 04:12, David Vincent-Jones a écrit :
> A raw file keeps all of our options open: We can at any time produce a
> small jpg for a slide show or sell a giant print from a tiff. Raw files
> are not massive in size and compare in storage with a full sized 100% jpg.
+1 and you have the o
A raw file keeps all of our options open: We can at any time produce a
small jpg for a slide show or sell a giant print from a tiff. Raw files
are not massive in size and compare in storage with a full sized 100% jpg.
David
On 13-12-02 02:03 PM, junkyardspar...@yepmail.net wrote:
> This very clo
One of the strengths of darktable is the ability to apply a style over a
large number of images that have commonality, this allows at least 'base
processing' to be done extreemly efficiently even over hundreds of
images being imported from a days work; whereas digikam works
(pedantically) on ea
On 12/02/2013 04:57 PM, Simon Spannagel wrote:
> I actually thought darktable would write into the same XMP file using
> its own name space. Therefore the two sets of information shouldn't
> interfere beside the things like rating that are stored in the common
> namespace.
I read through one of t
Am Montag, 2. Dezember 2013, 22:57:51 schrieb Simon Spannagel:
> I actually thought darktable would write into the same XMP file using its
> own name space. Therefore the two sets of information shouldn't interfere
> beside the things like rating that are stored in the common namespace.
Basically
This very closely mirrors my feelings/use case. In fact, I'm increasingly not
even keeping most of my RAW files if I still like the "developed" JPEG a week
later. Before you become horrified, just consider that different people have
different reasons for taking pictures, and don't have to be "se
I actually thought darktable would write into the same XMP file using its own
name space. Therefore the two sets of information shouldn't interfere beside
the things like rating that are stored in the common namespace.
Correct me when I'm wrong - i haven't used another tool producing XMPs for
y
If you are using a file system based DAM you can also ignore darktable DAM
in the sense that you only will need to access the files by importing the
folders and then select them in the collect modules. But that does nothing
to do with XMP files, they store in them tags and ratings, but they also
st
Am Montag, 2. Dezember 2013 schrieb Pascal Obry:
> Le 02/12/2013 22:17, Jose Carlos Garcia Sogo a écrit :
> > If you all are trying to shoot yourself on the foot and eventually loose
> > all your processing to you different images is OK what you are
> > proposing. Elsewhere you shoukd keep what dar
| Le 02/12/2013 22:17, Jose Carlos Garcia Sogo a Âcrit :
| > If you all are trying to shoot yourself on the foot and eventually
| > loose all your processing to you different images is OK what you are
| > proposing. Elsewhere you shoukd keep what darktable is proposing.
|
| I fully agree, I reall
Le 02/12/2013 22:17, Jose Carlos Garcia Sogo a écrit :
> If you all are trying to shoot yourself on the foot and eventually loose
> all your processing to you different images is OK what you are
> proposing. Elsewhere you shoukd keep what darktable is proposing.
I fully agree, I really find it str
If you all are trying to shoot yourself on the foot and eventually loose
all your processing to you different images is OK what you are proposing.
Elsewhere you shoukd keep what darktable is proposing.
BTW, to make it even more clear. Darktable stores both the Dam information
an all the processing
On 2013-12-02 ellest...@ninedegreesbelow.com wrote:
> The information that darktable stores in its xmp file does look very
> useful. If there were an option to tell darktable to put all its XMP
> files in one directory, completely separated from my archive folder
> where my originals are stored,
| The information that darktable stores in its xmp file does look very
| useful. If there were an option to tell darktable to put all its XMP
| files in one directory, completely separated from my archive folder
| where my originals are stored, that would be great! Have I overlooked
| such an optio
On 12/02/2013 01:27 PM, David Vincent-Jones wrote:
> Not writing sidecar files would probably negate much of darktables
> capability since there would be no history of processing. Darktable
> would then be another 'dumb' processor in the same manner as Digikam.
> Oil and water simply do not mix wel
* David Vincent-Jones [12-02-13 13:28]:
>
> On 13-12-02 09:55 AM, Robert William Hutton wrote:
> > On 02/12/13 17:52, Robert William Hutton wrote:
> >> On 02/12/13 17:52, Elle Stone wrote:
> >>> Is there any way to disable the writing of darktable's XMP files? I
> >>> don't want them written to m
On 12/02/2013 12:55 PM, Robert William Hutton wrote:
> On 02/12/13 17:52, Robert William Hutton wrote:
>> On 02/12/13 17:52, Elle Stone wrote:
>>> Is there any way to disable the writing of darktable's XMP files? I
>>> don't want them written to my archive folder as I use digikam and
>>> exiftool
On 13-12-02 09:55 AM, Robert William Hutton wrote:
> On 02/12/13 17:52, Robert William Hutton wrote:
>> On 02/12/13 17:52, Elle Stone wrote:
>>> Is there any way to disable the writing of darktable's XMP files? I
>>> don't want them written to my archive folder as I use digikam and
>>> exiftool to
> "Elle" == Elle Stone writes:
Elle> Is there any way to disable the writing of darktable's XMP files? I
Elle> don't want them written to my archive folder as I use digikam and
Elle> exiftool to take care of tagging, rating, etc.
Elle> I really don't want to use darktable's D
On 02/12/13 17:52, Robert William Hutton wrote:
> On 02/12/13 17:52, Elle Stone wrote:
>> Is there any way to disable the writing of darktable's XMP files? I
>> don't want them written to my archive folder as I use digikam and
>> exiftool to take care of tagging, rating, etc.
>
> I've not tried
On 02/12/13 17:52, Elle Stone wrote:
> Is there any way to disable the writing of darktable's XMP files? I
> don't want them written to my archive folder as I use digikam and
> exiftool to take care of tagging, rating, etc.
I've not tried it, but maybe setting write_sidecar_files=FALSE in
~/.co
Is there any way to disable the writing of darktable's XMP files? I
don't want them written to my archive folder as I use digikam and
exiftool to take care of tagging, rating, etc.
I really don't want to use darktable's DAM functionality. I don't want
darktable to ever write xmp files and espec
32 matches
Mail list logo
