Digikam raw files and darktable

Sat Jan 7 02:42:35 GMT 2017

I know that darktable writes not only tags, rating etc, but also the
process history.

That's why I want digikan to call darktable when it founds a raw file. To
generate the processed image.

Do you have any idea about digikam code? I see that people is interested in
this feature, so tomorrow I will try to define the tasks for the project
and I will share them in the bug I have create for this.

Thanks

El 7 ene. 2017 3:38 AM, "Andrey Goreev" <aegoreev at gmail.com> escribió:

> Hello Juan,
>
> Whatever you do with a RAW file in darktable is being stored in a sidecar
> file (xmp). So the xmp's are not only about tags, camera model, etc. If
> digikam was able to read darktable's xmp it would show the image properly
> (according to the changes you made in darktable) and I guess the thumbnail
> would look correct (I am not sure about that, this might be the hardest
> part).
> I am not sure I will be able to do the whole project but I can try
> anyways. Who knows, maybe I am good at it :).
>
> -------- Original message --------
> From: Juan Jose Casafranca <jjcasmar at gmail.com>
> Date: 2017-01-06 7:04 PM (GMT-07:00)
> To: digiKam - Home Manage your photographs as a professional with the
> power of open source <digikam-users at kde.org>
> Subject: Re: Digikam raw files and darktable
>
> Hi Andrey,
>
> I understand the problems that you are telling.
> I understand that some software doesn't respect the xmp tags created by
> other.
> That would be easily solved only supporting processors that respect other
> software tags (I feel that respecting what other programs write is
> important
> for compatibility)
> I don't think reading is a problem, if a software doesn't understand a
> tag,
> simply ignore it.
>
> I dont think digikam need to read darktable tags. My idea is to create a
> plugin in which you specify which raw processor you want to use. When a
> raw
> file is found, simply call the raw processor with the xmp sidecar and get
> the
> image that the processor generates.
>
> Darktable doesn't need to read digikam tags, does it? What happens when
> darktable founds a tag which doesnt know how to interpret?
>
> About the standards, of course. I think that the xmp files should have a
> set of
> standard tags (for example, title, lens, camera, keywords...) and other
> software specific. Doesn't xmp files already work this way? When a new
> editing
> is done with digikam, you can simply generate a new xmp, the same way that
> you
> will generate two of them in darktable if you duplicate the picture.
>
> I think that doing some kind of xmp standard file and letting different
> software communicate through it is the correct way to do things.
>
> About the pp3 files from raw therapee. Why not? My idea is to do this
> asking
> the user which processor is going to use for raw editing. If the users
> says
> that raw therapee, digikam simply calls raw therapee (feeding it with the
> pp3
> file). The only condition is the software to be used as a library. Anyway,
> I
> wont implement that, I'm focused on the darktable because is the software
> I
> use. If someone wants the raw therapee... he can do it :-)
>
> I think that if we design a good plan to implement all this, developers
> from
> different software will be please to be part of it.
>
> Would you like to help me with this?
>
> On viernes, 6 de enero de 2017 15:09:37 (CET) Andrey Goreev wrote:
> > darktable never saves any changes to RAW files. All changes are to be
> saved
> > in sidecar file originalfilename.xmp
> > Both digikam and darktable will be reading and writing the same sidecar
> > file.
> > There are few issues here:
> > - Writing - Some programs do not respect changes made by another programs
> > and overwrite them;
> > - Read - Some programs do not recognize code added to an xmp-file by
> > another programs.
> > Please see an example of an XMP file created by darktable attached. You
> > will see that digikam's xmp will be different.
> >
> > So what needs to be done here?
> > Someone needs to work with both digikam and darktable devs and make sure
> > that:
> >
> > - digikam can read changes added by darktable (processing filters, etc.)
> > - darktable can read changes added by digikam (tags, etc.)
> > - digikam and darktable use same xmp standards and do not duplicate any
> > information; (e.g. darktable can add keywords (tags); digikam can do RAW
> > editing)
> > - digikam and darktable respect each others code added to xmp and do not
> > overwrite anything
> >
> > Sounds like a lot of work but I do not think there will be much actual
> > coding required from the person. It will be mostly communication and it
> > will be tough since the devs might have different vision on the subject.
> >
> >
> > I personally think it is a great idea. Actually I have seen similar
> wishes
> > on discuss.pixls.us. I think that champions from pixls.us (well
> respected
> > open source photographers) could become that compound that glues up the
> two
> > pieces of software together.
> >
> >
> > PS But be ready to hear "But how about RawTherapee and its pp3 files?"
> >
> > Best regards,
> > Andrey Goreev
> >
> > On Fri, Jan 6, 2017 at 1:53 PM, Eduard Zalar <eduard at zalar.de> wrote:
> > > OK, thanks.
> > >
> > > That's the information I didn't know because I do not work with raw
> > > files.  Hopefully you can find a good solution.
> > >
> > >
> > > Juan Jose Casafranca <jjcasmar at gmail.com> schrieb am Fr., 6. Jan.
> 2017 um
> > >
> > > 21:49 Uhr:
> > >> I have also thought something like that. The problem is that raw
> > >> processors usually dont touch the original raw file. The only output
> an
> > >> xmp
> > >> file. With this in mind, is common to duplicate the xmp file to
> different
> > >> processes, so you end with only a raw file but several xmp files for
> that
> > >> raw file (imagine you want a black and white version of a photo but
> also
> > >> the color version). Therefore, it's not possible to just update the
> > >> embedded file, because there is not just one unique output from the
> raw
> > >> processor :-)
> > >>
> > >> 2017-01-06 21:46 GMT+01:00 Eduard Zalar <eduard at zalar.de>:
> > >>
> > >> Hi,
> > >>
> > >> this is an interesting discussion.
> > >>
> > >> Wouldn't it be better to enable darktable to update the embedded JPEG
> > >> image in the raw file?
> > >>
> > >> In this case digiKam would detect a change in the file and
> automatically
> > >> update the thumbnail, isn't it?
> > >>
> > >> It's just an idea...
> > >>
> > >> Normally, I do not use raw files so I don't know if there may exist
> > >> another restriction which avoids this.
> > >>
> > >> Regards
> > >> Eddie
> > >>
> > >>
> > >>
> > >> Simon Frei <freisim93 at gmail.com> schrieb am Fr., 6. Jan. 2017, 20:47:
> > >>
> > >> First thing to do is open a bugzilla issue where you describe what you
> > >> want:
> > >> https://bugs.kde.org/enter_bug.cgi?product=digikam&format=guided
> > >> There you probably get better pointers for where to start from
> > >> experienced devs, I never worked with that part of the code. This is
> the
> > >> function that creates thumbnails:
> > >> https://cgit.kde.org/digikam.git/tree/libs/threadimageio/
> > >> thumbnailcreator.cpp?id=429fa5fd8e7f53b74c82eb19dffb2e6cf4b4325c#n455
> > >>
> > >>
> > >> On 06/01/17 20:18, Juan Jose Casafranca wrote:
> > >>
> > >> Yes, exactly, that is my suggestion :-)
> > >> I think that it will give digikam a great boost if it can communicate
> > >> with specific raw processors :-)
> > >>
> > >> I understand that it could be an intensive task, but there are some
> ways
> > >> to limit the heavyness.
> > >> For example, digikam should only process the new thumbnail when
> darktable
> > >> is opened through digikam interface and at the beginning.
> > >> Or maybe just marking which files are dirty and then calling
> darktable in
> > >> lib mode to update those thumbnails.
> > >>
> > >> I would be happy to work on something like this. Any idea on where to
> > >> begin with? Ive never touched the digikam code ^^
> > >>
> > >> Cheers
> > >>
> > >> 2017-01-06 20:10 GMT+01:00 Simon Frei <freisim93 at gmail.com>:
> > >>
> > >> Hi,
> > >>
> > >> Do I understand you correctly: You want thumbnails of raw files that
> are
> > >> adjusted based on the processing profiles of darktable?
> > >> If that is the case, it is (currently) not possible in digikam. And
> such
> > >> a function would certainly be very resource heavy, as for every
> > >> thumbnail on every change darktable had to process the raw file.
> > >> The interface between digikam and other photo editing software could
> > >> certainly be improved (e.g. versioning too), so I would be very happy
> if
> > >> you would work on that in any way;)
> > >>
> > >> Cheers,
> > >> Simon
> > >>
> > >> On 06/01/17 20:01, Juan Jose Casafranca wrote:
> > >> > Hi everybody,
> > >> >
> > >> > I would like to know if there is any easy way to use digikam as a
> photo
> > >> > management software and use darktable for raw editing.
> > >> >
> > >> > The main issue I'm finding when I try to do this is this one
> > >> > -Raw thumbnails are loaded from the jpeg embeded file and when I
> change
> > >>
> > >> process
> > >>
> > >> > my photo in darktable, this thumbnail isn't changed in digikam
> > >> >
> > >> > It would be nice that digikam reads the darktable sidecar and uses
> an
> > >>
> > >> specified
> > >>
> > >> > software (or digikam editor tool if no software is specified) to
> load
> > >>
> > >> the
> > >>
> > >> > preview file for raw pictures. Is there any way to do this?
> > >> >
> > >> > If there's no such way to do this, I will be happy to post it in the
> > >> > developers mailing list and try to implement it, because I feel that
> > >>
> > >> darktable
> > >>
> > >> > management features are far away from digikam ones and digikam
> editor
> > >>
> > >> features
> > >>
> > >> > are far away from darktable ones. It would be nice to have both
> > >>
> > >> softwares
> > >>
> > >> > working together :-)
> > >> >
> > >> > Any idea?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20170107/985326d9/attachment.html>