Digikam raw files and darktable
Locked
1234
1234
Digikam raw files and darktable
 
|
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? |
Re: Digikam raw files and darktable
|
|
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? |
Re: Digikam raw files and darktable
|
|
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 <[hidden email]>: Hi, |
Re: Digikam raw files and darktable
|
|
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:
|
Re: Digikam raw files and darktable
|
|
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 <[hidden email]> schrieb am Fr., 6. Jan. 2017, 20:47:
|
Re: Digikam raw files and darktable
|
|
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 <[hidden email]>: Hi, |
Re: Digikam raw files and darktable
|
|
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 <[hidden email]> schrieb am Fr., 6. Jan. 2017 um 21:49 Uhr:
|
Re: Digikam raw files and darktable
|
|
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.- 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) 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 <[hidden email]> wrote:
|
IMGP0385.dng.xmp (3K)
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>: > >> > >> 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 <[hidden email]> 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 <[hidden email]>: > >> > >> 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? |
Re: Digikam raw files and darktable
|
|
In reply to this post by Juan Jose Casafranca
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 <[hidden email]> 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 <[hidden email]> Subject: Re: Digikam raw files and darktable 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>: > >> > >> 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 <[hidden email]> 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 <[hidden email]>: > >> > >> 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? |
Re: Digikam raw files and darktable
|
|
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" <[hidden email]> escribió:
|
Re: Digikam raw files and darktable
|
|
On samedi 7 janvier 2017 03:42:35 CET Juan Jose Casafranca wrote:
> 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. Wouldn't it be easier to get an option in Darktable to write a thumbnail file to disk when leaving darkroom mode or changing file there? And then add a link to that thumbnail in the XMP file. Basically, you add an API for external programs to provide a thumbnail image (and afaik, KDE has a standardised way to store thumbnails in a directory). And Darktable already generates preview images/thumbnails (top left in the darkroom window, and of course in lighttable mode). Better to reuse those if at all possible. It's clear that Digikam's editor will not be able to generate a thumbnail from the original RAW and a Darktable XMP. But starting Darktable for each and every RAW file that has a Darktable XMP is going to be slow (even if you can reliably detect whether an image has been changed). So at the very least, starting Darktable to generate thumbnails would have to be optional or a batch process. Another problem with that would be all the other RAW processors out there. Why would Digikam treat Darktable in a special way and ignore all the others? For the record, I use Darktable as primary editor, and getting the processed images visible in Digikam would be nice. I'm not sure this should be addressed (only) from the Digikam side, though. |
Re: Digikam raw files and darktable
|
|
I follow this thread, and that i can said is : RAW workflow is terrific and very complex. I spare few years to undstand all main subtilities to implement a first suitbale support of RAW files in digiKam.
Read the contextual responses below for the next... 2017-01-07 10:15 GMT+01:00 Remco Viëtor <[hidden email]>: On samedi 7 janvier 2017 03:42:35 CET Juan Jose Casafranca wrote: This API is limited even if it's standardized by Open Desktop. digiKam drop this support since a while for multiple technical reasons, as using Wavelets compression to reduce space instead PNG, using a dedicted database to handle disconnected removable media, be able to store thumb in a remote database, support more than 256x256 thumbnails size, etc... So no KDE API here. In all case, we want to reduce to the max KDE dependencies for the future to be porta le everywhere and reduce complexity. Note : KDE thumbnials use KIO : we drop this support since 5.0, which DO NOT WORK outside Linux, and cannot be bundled in AppImage. No KIO in digiKam for the future... And Darktable already generates preview Where are stored this preview image ? In a dedicated place... This will be another puzzle to interface digiKam with that...
Wrong. digiKam use libraw and extract JPEG preview from RAW file to generate thumbnails... and a Darktable XMP. But starting Darktable for each and A possible solution is to use IPTC field stored in XMP. There is a IPTC preview tag to host JPEG preview. It's limited to 256Kb of data which is enough to do the job. Problem : Old IPTC support is, in XMP i don't know, especially to host binary data in XML. Other problem is to explode the sidecar XMP file size. This is why we use a dedicted database....
Remember that we use already a RAW processor : libraw. there are plenty of new feature in this processor not yet used in digiKam. The best way is to implment new RAW feature in digiKam, at least to import RAW data in editor. For the record, I use Darktable as primary editor, and getting the processed exactly... Gilles Caulier |
Re: Digikam raw files and darktable
|
|
On samedi 7 janvier 2017 10:31:27 CET Gilles Caulier wrote:
> I follow this thread, and that i can said is : RAW workflow is terrific and > very complex. I spare few years to undstand all main subtilities to > implement a first suitbale support of RAW files in digiKam. > > Read the contextual responses below for the next... > > 2017-01-07 10:15 GMT+01:00 Remco Viëtor <[hidden email]>: > > On samedi 7 janvier 2017 03:42:35 CET Juan Jose Casafranca wrote: > > > 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. > > > (...) > > > > Wouldn't it be easier to get an option in Darktable to write a thumbnail > > file > > to disk when leaving darkroom mode or changing file there? And then add a > > link > > to that thumbnail in the XMP file. Basically, you add an API for external > > programs to provide a thumbnail image (and afaik, KDE has a standardised > > way > > to store thumbnails in a directory). > > This API is limited even if it's standardized by Open Desktop. digiKam drop > this support since a while for multiple technical reasons, as using > Wavelets compression to reduce space instead PNG, using a dedicted database > to handle disconnected removable media, be able to store thumb in a remote > database, support more than 256x256 thumbnails size, etc... > > So no KDE API here. In all case, we want to reduce to the max KDE > dependencies for the future to be porta le everywhere and reduce complexity. > > Note : KDE thumbnials use KIO : we drop this support since 5.0, which DO > NOT WORK outside Linux, and cannot be bundled in AppImage. No KIO in > digiKam for the future... OK, so that is not a viable option. But a clear way for external programs to get information (like thumbnails) back to Digikam would be helpful, and the sidecar could be a channel for that. > > And Darktable already generates preview > > images/thumbnails (top left in the darkroom window, and of course in > > lighttable mode). Better to reuse those if at all possible. > > Where are stored this preview image ? In a dedicated place... This will be > another puzzle to interface digiKam with that... > Ideally, Digikam shouldn't have to worry about if and where those thumbnails are stored internally by Darktable. But the code to *generate* those thumbnails is in place already, what's missing is a way to *export* those thumbnails for use with external programs (i.e. Digikam). > > It's clear that Digikam's editor will not be able to generate a thumbnail > > from > > the original RAW > > Wrong. digiKam use libraw and extract JPEG preview from RAW file to > generate thumbnails... > > > and a Darktable XMP. But starting Darktable for each and > > (...) Sorry, you cut my phrase at the wrong point... What I wanted to say is that Digikam cannot repeat the processing Darktable does, i.e. cannot generate a thumbnail by combining the information from the RAW file and the XMP file (of course Digikam can generate a thumbnail from the RAW file only, it's doing just that all the time...) > A possible solution is to use IPTC field stored in XMP. There is a IPTC > preview tag to host JPEG preview. It's limited to 256Kb of data which is > enough to do the job. Problem : Old IPTC support is, in XMP i don't know, > especially to host binary data in XML. > > Other problem is to explode the sidecar XMP file size. This is why we use a > dedicted database.... > > > Another problem with that would be all the other RAW processors out there. > > Why > > would Digikam treat Darktable in a special way and ignore all the others? > > Remember that we use already a RAW processor : libraw. there are plenty of > new feature in this processor not yet used in digiKam. The best way is to > implment new RAW feature in digiKam, at least to import RAW data in editor. Possible, but not relevant to this subject (IMO): there are many reasons why someone would use Digikam for DAM, and another program for RAW development. The point here is to get a *representation* of the image, as produced by that other program, in the Digikam thumbnails view. So, basically, what I'd aim for is: - define a way to get thumbnails from an external source into Digikam; - get the external programs to provide (access to) those thumbnails in a well- defined way; - find a way to make sure Digikam won't import unchanged thumbnails a second time. Remco |
Re: Digikam raw files and darktable
|
|
I think you are trying to solve the problem in a very complex way.
First of all, where does digikam currently saves the thumbnails? If it's in the database, then, the only thing needed is a way to generate the processed raw as a thumbnail and a flag which specify if the thumbnail is up to date. This flag es very easy to maintain. When loading the database, the thumbnails are not up to date. So darktable (or any other raw processor) will be called to generate the thumbnails. When a raw file is opened for edition through the digikam interface, then also mark the thumbnail is not up to date. If the user opens the file for edition from other place different from the digikam interface (opening the raw processor directly for example), then do anything. I know that thumbnail stored and the processed image will not match in this case, this should be documented. Enable an option to update manually the thumbnails for raw files. Digikam should have an option to choose which raw processor want the user to user. Default one, darktable, raw therapee, whatever. When a user try to edits a raw file, then the raw processor selected is opened. I dont think that we need to store any extra information in the xmp file. Simply, made different software dont override other software xmp tags (as I said in other post, I think this is common sense). Digikam would not treat darktable in a special way. I'm just asking for an interface to connect digikam with any raw processor. This interface should only need to provide a way to open the raw processor with the selected image and a way to get back the image from the raw processor. I dont really understand why digikam and raw processors should communicate through the xmp file. So, to summarize: User selects darktable for raw editing User opens a raw file in digikam -> darktable is opened User edits in darktable and close it -> thumbnail is marked as not up to date Thumbnail is updated calling darktable which returns an image (maybe with a LUA script?) The thumbnail is stored in digikam the same way other jpeg or current raw thumbnails are stored On sábado, 7 de enero de 2017 12:33:43 (CET) Remco Viëtor wrote: > On samedi 7 janvier 2017 10:31:27 CET Gilles Caulier wrote: > > I follow this thread, and that i can said is : RAW workflow is terrific > > and > > very complex. I spare few years to undstand all main subtilities to > > implement a first suitbale support of RAW files in digiKam. > > > > Read the contextual responses below for the next... > > > > 2017-01-07 10:15 GMT+01:00 Remco Viëtor <[hidden email]>: > > > On samedi 7 janvier 2017 03:42:35 CET Juan Jose Casafranca wrote: > > > > 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. > > > > (...) > > > > > > Wouldn't it be easier to get an option in Darktable to write a thumbnail > > > file > > > to disk when leaving darkroom mode or changing file there? And then add > > > a > > > link > > > to that thumbnail in the XMP file. Basically, you add an API for > > > external > > > programs to provide a thumbnail image (and afaik, KDE has a standardised > > > way > > > to store thumbnails in a directory). > > > > This API is limited even if it's standardized by Open Desktop. digiKam > > drop > > this support since a while for multiple technical reasons, as using > > Wavelets compression to reduce space instead PNG, using a dedicted > > database > > to handle disconnected removable media, be able to store thumb in a remote > > database, support more than 256x256 thumbnails size, etc... > > > > So no KDE API here. In all case, we want to reduce to the max KDE > > dependencies for the future to be porta le everywhere and reduce > > complexity. > > > > Note : KDE thumbnials use KIO : we drop this support since 5.0, which DO > > NOT WORK outside Linux, and cannot be bundled in AppImage. No KIO in > > digiKam for the future... > > OK, so that is not a viable option. But a clear way for external programs to > get information (like thumbnails) back to Digikam would be helpful, and the > sidecar could be a channel for that. > > > > And Darktable already generates preview > > > images/thumbnails (top left in the darkroom window, and of course in > > > lighttable mode). Better to reuse those if at all possible. > > > > Where are stored this preview image ? In a dedicated place... This will be > > another puzzle to interface digiKam with that... > > Ideally, Digikam shouldn't have to worry about if and where those thumbnails > are stored internally by Darktable. But the code to *generate* those > thumbnails is in place already, what's missing is a way to *export* those > thumbnails for use with external programs (i.e. Digikam). > > > > It's clear that Digikam's editor will not be able to generate a > > > thumbnail > > > from > > > the original RAW > > > > Wrong. digiKam use libraw and extract JPEG preview from RAW file to > > generate thumbnails... > > > > > and a Darktable XMP. But starting Darktable for each and > > > (...) > > Sorry, you cut my phrase at the wrong point... > What I wanted to say is that Digikam cannot repeat the processing Darktable > does, i.e. cannot generate a thumbnail by combining the information from the > RAW file and the XMP file (of course Digikam can generate a thumbnail from > the RAW file only, it's doing just that all the time...) > > > A possible solution is to use IPTC field stored in XMP. There is a IPTC > > preview tag to host JPEG preview. It's limited to 256Kb of data which is > > enough to do the job. Problem : Old IPTC support is, in XMP i don't know, > > especially to host binary data in XML. > > > > Other problem is to explode the sidecar XMP file size. This is why we use > > a > > dedicted database.... > > > > > Another problem with that would be all the other RAW processors out > > > there. > > > Why > > > would Digikam treat Darktable in a special way and ignore all the > > > others? > > > > Remember that we use already a RAW processor : libraw. there are plenty of > > new feature in this processor not yet used in digiKam. The best way is to > > implment new RAW feature in digiKam, at least to import RAW data in > > editor. > > Possible, but not relevant to this subject (IMO): there are many reasons why > someone would use Digikam for DAM, and another program for RAW development. > > The point here is to get a *representation* of the image, as produced by > that other program, in the Digikam thumbnails view. > > So, basically, what I'd aim for is: > - define a way to get thumbnails from an external source into Digikam; > - get the external programs to provide (access to) those thumbnails in a > well- defined way; > - find a way to make sure Digikam won't import unchanged thumbnails a second > time. > > Remco |
Re: Digikam raw files and darktable
|
|
Even more, if digikam stores thumbnails in a folder and just link the database
entry to the thumbnail path, then is pretty straightforward for the raw processor to send the thumbnail back, just export the processed image to the desire path and the desired size. On sábado, 7 de enero de 2017 12:51:23 (CET) you wrote: > I think you are trying to solve the problem in a very complex way. > > First of all, where does digikam currently saves the thumbnails? If it's in > the database, then, the only thing needed is a way to generate the processed > raw as a thumbnail and a flag which specify if the thumbnail is up to date. > > This flag es very easy to maintain. When loading the database, the > thumbnails are not up to date. So darktable (or any other raw processor) > will be called to generate the thumbnails. When a raw file is opened for > edition through the digikam interface, then also mark the thumbnail is not > up to date. If the user opens the file for edition from other place > different from the digikam interface (opening the raw processor directly > for example), then do anything. I know that thumbnail stored and the > processed image will not match in this case, this should be documented. > Enable an option to update manually the thumbnails for raw files. > > Digikam should have an option to choose which raw processor want the user to > user. Default one, darktable, raw therapee, whatever. When a user try to > edits a raw file, then the raw processor selected is opened. > > I dont think that we need to store any extra information in the xmp file. > Simply, made different software dont override other software xmp tags (as I > said in other post, I think this is common sense). > > Digikam would not treat darktable in a special way. I'm just asking for an > interface to connect digikam with any raw processor. This interface should > only need to provide a way to open the raw processor with the selected image > and a way to get back the image from the raw processor. > > I dont really understand why digikam and raw processors should communicate > through the xmp file. > > So, to summarize: > User selects darktable for raw editing > User opens a raw file in digikam -> darktable is opened > User edits in darktable and close it -> thumbnail is marked as not up to > date Thumbnail is updated calling darktable which returns an image (maybe > with a LUA script?) > The thumbnail is stored in digikam the same way other jpeg or current raw > thumbnails are stored > > On sábado, 7 de enero de 2017 12:33:43 (CET) Remco Viëtor wrote: > > On samedi 7 janvier 2017 10:31:27 CET Gilles Caulier wrote: > > > I follow this thread, and that i can said is : RAW workflow is terrific > > > and > > > very complex. I spare few years to undstand all main subtilities to > > > implement a first suitbale support of RAW files in digiKam. > > > > > > Read the contextual responses below for the next... > > > > > > 2017-01-07 10:15 GMT+01:00 Remco Viëtor <[hidden email]>: > > > > On samedi 7 janvier 2017 03:42:35 CET Juan Jose Casafranca wrote: > > > > > 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. > > > > > (...) > > > > > > > > Wouldn't it be easier to get an option in Darktable to write a > > > > thumbnail > > > > file > > > > to disk when leaving darkroom mode or changing file there? And then > > > > add > > > > a > > > > link > > > > to that thumbnail in the XMP file. Basically, you add an API for > > > > external > > > > programs to provide a thumbnail image (and afaik, KDE has a > > > > standardised > > > > way > > > > to store thumbnails in a directory). > > > > > > This API is limited even if it's standardized by Open Desktop. digiKam > > > drop > > > this support since a while for multiple technical reasons, as using > > > Wavelets compression to reduce space instead PNG, using a dedicted > > > database > > > to handle disconnected removable media, be able to store thumb in a > > > remote > > > database, support more than 256x256 thumbnails size, etc... > > > > > > So no KDE API here. In all case, we want to reduce to the max KDE > > > dependencies for the future to be porta le everywhere and reduce > > > complexity. > > > > > > Note : KDE thumbnials use KIO : we drop this support since 5.0, which DO > > > NOT WORK outside Linux, and cannot be bundled in AppImage. No KIO in > > > digiKam for the future... > > > > OK, so that is not a viable option. But a clear way for external programs > > to get information (like thumbnails) back to Digikam would be helpful, > > and the sidecar could be a channel for that. > > > > > > And Darktable already generates preview > > > > images/thumbnails (top left in the darkroom window, and of course in > > > > lighttable mode). Better to reuse those if at all possible. > > > > > > Where are stored this preview image ? In a dedicated place... This will > > > be > > > another puzzle to interface digiKam with that... > > > > Ideally, Digikam shouldn't have to worry about if and where those > > thumbnails are stored internally by Darktable. But the code to *generate* > > those thumbnails is in place already, what's missing is a way to *export* > > those thumbnails for use with external programs (i.e. Digikam). > > > > > > It's clear that Digikam's editor will not be able to generate a > > > > thumbnail > > > > from > > > > the original RAW > > > > > > Wrong. digiKam use libraw and extract JPEG preview from RAW file to > > > generate thumbnails... > > > > > > > and a Darktable XMP. But starting Darktable for each and > > > > (...) > > > > Sorry, you cut my phrase at the wrong point... > > What I wanted to say is that Digikam cannot repeat the processing > > Darktable > > does, i.e. cannot generate a thumbnail by combining the information from > > the RAW file and the XMP file (of course Digikam can generate a thumbnail > > from the RAW file only, it's doing just that all the time...) > > > > > A possible solution is to use IPTC field stored in XMP. There is a IPTC > > > preview tag to host JPEG preview. It's limited to 256Kb of data which is > > > enough to do the job. Problem : Old IPTC support is, in XMP i don't > > > know, > > > especially to host binary data in XML. > > > > > > Other problem is to explode the sidecar XMP file size. This is why we > > > use > > > a > > > dedicted database.... > > > > > > > Another problem with that would be all the other RAW processors out > > > > there. > > > > Why > > > > would Digikam treat Darktable in a special way and ignore all the > > > > others? > > > > > > Remember that we use already a RAW processor : libraw. there are plenty > > > of > > > new feature in this processor not yet used in digiKam. The best way is > > > to > > > implment new RAW feature in digiKam, at least to import RAW data in > > > editor. > > > > Possible, but not relevant to this subject (IMO): there are many reasons > > why someone would use Digikam for DAM, and another program for RAW > > development. > > > > The point here is to get a *representation* of the image, as produced by > > that other program, in the Digikam thumbnails view. > > > > So, basically, what I'd aim for is: > > - define a way to get thumbnails from an external source into Digikam; > > - get the external programs to provide (access to) those thumbnails in a > > well- defined way; > > - find a way to make sure Digikam won't import unchanged thumbnails a > > second time. > > > > Remco |
Re: Digikam raw files and darktable
|
|
In reply to this post by Juan Jose Casafranca
2017-01-07 12:51 GMT+01:00 Juan Jose Casafranca <[hidden email]>: I think you are trying to solve the problem in a very complex way. Already possible in Linux desktop, through OpenWith context menu. User opens a raw file in digikam -> darktable is opened Already possible in Linux Desktop, with default application set in desktop, that can be handle through a keyboard shortcut. I introduced myself in 5.0.0. Perhaps this need to be improved, but a good desktop settings in a best start. User edits in darktable and close it -> thumbnail is marked as not up to date DBUS can be used here. It's easy, but... This will only work under Linux. Forget MacOS and Windows, DBUS is a waste of time. The thumbnail is stored in digikam the same way other jpeg or current raw On this point, i'm not agree. It"s a regression and an user wish fixed few year ago... Gilles Caulier
|
Re: Digikam raw files and darktable
|
|
In reply to this post by Juan Jose Casafranca
And this will duplicate data and slowdown the thumbnails processing. Definitively, it's wrong. Gilles Caulier 2017-01-07 12:55 GMT+01:00 Juan Jose Casafranca <[hidden email]>: Even more, if digikam stores thumbnails in a folder and just link the database |
Re: Digikam raw files and darktable
|
|
In reply to this post by Gilles Caulier-4
On sábado, 7 de enero de 2017 13:51:57 (CET) Gilles Caulier wrote:
> 2017-01-07 12:51 GMT+01:00 Juan Jose Casafranca <[hidden email]>: > > I think you are trying to solve the problem in a very complex way. > > > > First of all, where does digikam currently saves the thumbnails? If it's > > in > > the database, then, the only thing needed is a way to generate the > > processed > > raw as a thumbnail and a flag which specify if the thumbnail is up to > > date. > > > > This flag es very easy to maintain. When loading the database, the > > thumbnails > > are not up to date. So darktable (or any other raw processor) will be > > called > > to generate the thumbnails. When a raw file is opened for edition through > > the > > digikam interface, then also mark the thumbnail is not up to date. If the > > user > > opens the file for edition from other place different from the digikam > > interface (opening the raw processor directly for example), then do > > anything. > > I know that thumbnail stored and the processed image will not match in > > this > > case, this should be documented. Enable an option to update manually the > > thumbnails for raw files. > > > > Digikam should have an option to choose which raw processor want the user > > to > > user. Default one, darktable, raw therapee, whatever. When a user try to > > edits > > a raw file, then the raw processor selected is opened. > > > > I dont think that we need to store any extra information in the xmp file. > > Simply, made different software dont override other software xmp tags (as > > I > > said in other post, I think this is common sense). > > > > Digikam would not treat darktable in a special way. I'm just asking for an > > interface to connect digikam with any raw processor. This interface should > > only need to provide a way to open the raw processor with the selected > > image > > and a way to get back the image from the raw processor. > > > > I dont really understand why digikam and raw processors should communicate > > through the xmp file. > > > > So, to summarize: > > User selects darktable for raw editing > > Already possible in Linux desktop, through OpenWith context menu. > > > User opens a raw file in digikam -> darktable is opened > > Already possible in Linux Desktop, with default application set in desktop, > that can be handle through a keyboard shortcut. I introduced myself in > 5.0.0. Perhaps this need to be improved, but a good desktop settings in a > best start. > > > User edits in darktable and close it -> thumbnail is marked as not up to > > date > > Thumbnail is updated calling darktable which returns an image (maybe with > > a > > LUA script?) > > DBUS can be used here. It's easy, but... This will only work under Linux. > Forget MacOS and Windows, DBUS is a waste of time. What do you propose for windows and mac? Or just implement this as a linux only feature? (Anyway, windows and mac users already has another raw processing workflow which includes other software, dont they?) > > > The thumbnail is stored in digikam the same way other jpeg or current raw > > thumbnails are stored > > On this point, i'm not agree. It"s a regression and an user wish fixed few > year ago... How do you propose to store raw thumbnails then? I don't really know how digikam stores thumbnails for other types, or even if it stores something or simply generate them online. > > Gilles Caulier > > > On sábado, 7 de enero de 2017 12:33:43 (CET) Remco Viëtor wrote: > > > On samedi 7 janvier 2017 10:31:27 CET Gilles Caulier wrote: > > > > I follow this thread, and that i can said is : RAW workflow is > > > > terrific > > > > and > > > > very complex. I spare few years to undstand all main subtilities to > > > > implement a first suitbale support of RAW files in digiKam. > > > > > > > > Read the contextual responses below for the next... > > > > > > > > 2017-01-07 10:15 GMT+01:00 Remco Viëtor <[hidden email]>: > > > > > On samedi 7 janvier 2017 03:42:35 CET Juan Jose Casafranca wrote: > > > > > > 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. > > > > > > > > (...) > > > > > > > > > > Wouldn't it be easier to get an option in Darktable to write a > > > > thumbnail > > > > > > > file > > > > > to disk when leaving darkroom mode or changing file there? And then > > > > add > > > > > > > a > > > > > link > > > > > to that thumbnail in the XMP file. Basically, you add an API for > > > > > external > > > > > programs to provide a thumbnail image (and afaik, KDE has a > > > > standardised > > > > > > > way > > > > > to store thumbnails in a directory). > > > > > > > > This API is limited even if it's standardized by Open Desktop. digiKam > > > > drop > > > > this support since a while for multiple technical reasons, as using > > > > Wavelets compression to reduce space instead PNG, using a dedicted > > > > database > > > > to handle disconnected removable media, be able to store thumb in a > > > > remote > > > > > > database, support more than 256x256 thumbnails size, etc... > > > > > > > > So no KDE API here. In all case, we want to reduce to the max KDE > > > > dependencies for the future to be porta le everywhere and reduce > > > > complexity. > > > > > > > > Note : KDE thumbnials use KIO : we drop this support since 5.0, which > > > > DO > > > > > > NOT WORK outside Linux, and cannot be bundled in AppImage. No KIO in > > > > digiKam for the future... > > > > > > OK, so that is not a viable option. But a clear way for external > > > > programs to > > > > > get information (like thumbnails) back to Digikam would be helpful, and > > > > the > > > > > sidecar could be a channel for that. > > > > > > > > And Darktable already generates preview > > > > > images/thumbnails (top left in the darkroom window, and of course in > > > > > lighttable mode). Better to reuse those if at all possible. > > > > > > > > Where are stored this preview image ? In a dedicated place... This > > > > will be > > > > > > another puzzle to interface digiKam with that... > > > > > > Ideally, Digikam shouldn't have to worry about if and where those > > > > thumbnails > > > > > are stored internally by Darktable. But the code to *generate* those > > > thumbnails is in place already, what's missing is a way to *export* > > > those > > > thumbnails for use with external programs (i.e. Digikam). > > > > > > > > It's clear that Digikam's editor will not be able to generate a > > > > > thumbnail > > > > > from > > > > > the original RAW > > > > > > > > Wrong. digiKam use libraw and extract JPEG preview from RAW file to > > > > generate thumbnails... > > > > > > > > > and a Darktable XMP. But starting Darktable for each and > > > > > (...) > > > > > > Sorry, you cut my phrase at the wrong point... > > > What I wanted to say is that Digikam cannot repeat the processing > > > > Darktable > > > > > does, i.e. cannot generate a thumbnail by combining the information from > > > > the > > > > > RAW file and the XMP file (of course Digikam can generate a thumbnail > > > > from > > > > > the RAW file only, it's doing just that all the time...) > > > > > > > A possible solution is to use IPTC field stored in XMP. There is a > > > > IPTC > > > > preview tag to host JPEG preview. It's limited to 256Kb of data which > > > > is > > > > > > enough to do the job. Problem : Old IPTC support is, in XMP i don't > > > > know, > > > > > > especially to host binary data in XML. > > > > > > > > Other problem is to explode the sidecar XMP file size. This is why we > > > > use > > > > > > a > > > > dedicted database.... > > > > > > > > > Another problem with that would be all the other RAW processors out > > > > > there. > > > > > Why > > > > > would Digikam treat Darktable in a special way and ignore all the > > > > > others? > > > > > > > > Remember that we use already a RAW processor : libraw. there are > > > > plenty of > > > > > > new feature in this processor not yet used in digiKam. The best way is > > > > to > > > > > > implment new RAW feature in digiKam, at least to import RAW data in > > > > editor. > > > > > > Possible, but not relevant to this subject (IMO): there are many reasons > > > > why > > > > > someone would use Digikam for DAM, and another program for RAW > > > > development. > > > > > The point here is to get a *representation* of the image, as produced by > > > that other program, in the Digikam thumbnails view. > > > > > > So, basically, what I'd aim for is: > > > - define a way to get thumbnails from an external source into Digikam; > > > - get the external programs to provide (access to) those thumbnails in a > > > well- defined way; > > > - find a way to make sure Digikam won't import unchanged thumbnails a > > > > second > > > > > time. > > > > > > Remco |
Re: Digikam raw files and darktable
|
|
As i explain before, ALL thumbnails generated by digiKam are stored in a dedicated database (sqlite or Mysql). The thumbnails are stored using wavelets compression format PGF to optimize space. In older DK version (3 for ex), we use FreeDesktop way with PNG which explode storage for huge collection and take a while to store thumbnails files. Also FreeDesktop recommendations is only limited to 256x256, which is not enough for Hdpi screen (digiKam can store 512x512 and perhaps more in the future with 8K screen). So, no way to change something in DK to store thumbnails for the moment. Gilles Caulier 2017-01-07 14:41 GMT+01:00 Juan Jose Casafranca <[hidden email]>:
|
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |