Digikam raw files and darktable
Locked
1234
1234
Re: Digikam raw files and darktable
 
|
On sábado, 7 de enero de 2017 15:03:38 (CET) Gilles Caulier wrote:
> 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). Okay. But there is no need to change anything in DK for storing thumbnails. The only thing needed is to change the way thumbnails are generated and updated for raw files. Simply, when DK finds a new raw file, instead of loading the embedded jpg file, simply call the raw processor and generate the new file. And when the thumbnail is dirty (as I explained before), regenerate the thumbnail. Isn't that possible currently? > > 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]>: > > 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 > > > > > > > > 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
|
|
2017-01-07 15:08 GMT+01:00 Juan Jose Casafranca <[hidden email]>: On sábado, 7 de enero de 2017 15:03:38 (CET) Gilles Caulier wrote: But this is already the case. We use already a raw decoder named libraw to process RAW thumbnails. We will not using another one... Stop to puzzle the code Gilles Caulier |
Re: Digikam raw files and darktable
|
|
On sábado, 7 de enero de 2017 15:14:09 (CET) Gilles Caulier wrote:
> 2017-01-07 15:08 GMT+01:00 Juan Jose Casafranca <[hidden email]>: > > On sábado, 7 de enero de 2017 15:03:38 (CET) Gilles Caulier wrote: > > > 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). > > > > Okay. But there is no need to change anything in DK for storing > > thumbnails. > > The only thing needed is to change the way thumbnails are generated and > > updated for raw files. > > > > Simply, when DK finds a new raw file, instead of loading the embedded jpg > > file, > > simply call the raw processor and generate the new file. And when the > > thumbnail > > is dirty (as I explained before), regenerate the thumbnail. > > But this is already the case. We use already a raw decoder named libraw to > process RAW thumbnails. We will not using another one... Stop to puzzle the > code > > Gilles Caulier So you are telling me that if we want to process a raw file and manage a library with DK, we have to stay with the simply DK raw processor instead of using a much more powerful one like darktable? Do you really think that people out there use the DK raw processor to process their images? Even more, I have just tried to convert a raw image to BW, and yes, I can convert it, but the raw thumbnail is not updated accordingly... |
Re: Digikam raw files and darktable
|
|
2017-01-07 15:22 GMT+01:00 Juan Jose Casafranca <[hidden email]>:
But digiKam is not DarkTable. The way to mix both cannot be done. This is 2 different applications, one written in Qt other one in GTK... The goal currently in DK is to stabilize the code, reduce dependencies, improve port to non Linux. We have plenty of jobs to do, DarkTable is not a priority for the moment. Gilles Caulier |
Re: Digikam raw files and darktable
|
|
On sábado, 7 de enero de 2017 15:25:43 (CET) Gilles Caulier wrote:
> 2017-01-07 15:22 GMT+01:00 Juan Jose Casafranca <[hidden email]>: > > On sábado, 7 de enero de 2017 15:14:09 (CET) Gilles Caulier wrote: > > > 2017-01-07 15:08 GMT+01:00 Juan Jose Casafranca <[hidden email]>: > > > > On sábado, 7 de enero de 2017 15:03:38 (CET) Gilles Caulier wrote: > > > > > 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). > > > > > > > > Okay. But there is no need to change anything in DK for storing > > > > thumbnails. > > > > The only thing needed is to change the way thumbnails are generated > > > > and > > > > updated for raw files. > > > > > > > > Simply, when DK finds a new raw file, instead of loading the embedded > > > > jpg > > > > > > file, > > > > simply call the raw processor and generate the new file. And when the > > > > thumbnail > > > > is dirty (as I explained before), regenerate the thumbnail. > > > > > > But this is already the case. We use already a raw decoder named libraw > > > > to > > > > > process RAW thumbnails. We will not using another one... Stop to puzzle > > > > the > > > > > code > > > > > > Gilles Caulier > > > > So you are telling me that if we want to process a raw file and manage a > > library with DK, we have to stay with the simply DK raw processor instead > > of > > using a much more powerful one like darktable? Do you really think that > > people > > out there use the DK raw processor to process their images? > > But digiKam is not DarkTable. The way to mix both cannot be done. This is > 2 different applications, one written in Qt other one in GTK... > > The goal currently in DK is to stabilize the code, reduce dependencies, > improve port to non Linux. We have plenty of jobs to do, DarkTable is not a > priority for the moment. > > Gilles Caulier I know that they are two different apps. I dont understand why GTK and Qt is even a question here. I'm not saying to add DT as a depency for DK, just let the user decide which raw processor uses. As I said, I can try to develop this by myself, I'm not asking any dedicated DK developer to do it... What I only need is a little guideline on how the thumbnails are generated, how they are stored in the database and some other stuff for letting the user choose which processor wants to choose. And of course DK is not DT. But if you want to target photographers, maybe its a good idea to consider how photographers work. They need a way to organize their library, which DK is good at, and a way to process raw files, which DT is good at (DK is not a good raw processor and DT is not good for library management). But if it's not possible to use DK to organize raw files with thumbnails preview for processed imaged... then is useless for managing a raw library. |
Re: Digikam raw files and darktable
|
|
2017-01-07 15:41 GMT+01:00 Juan Jose Casafranca <[hidden email]>:
But Raw processor from DT is not the same than DK as i know. Changing Raw processor in digiKam by DT one is as to add DT dependencies to DK. No way here...
2 possibilities : 1/ use DBus to ping digiKam core about thumbnails changed externally. Only Linux solution. 2/ use XMP sidecar to store a local path to new thumbnails processed into DT XMP namespace. I don't like this too much by at least it store the minimum to XMP. 3/ store wavelets compressed preview in XMP sidecar to Iptc.Application2.Preview 4/ use a thumbnail sidecar file near RAW file as .thumb. I see this solution already used under Windows, but i don't remember which application exactly. I know that Canon camera do it also. It's a simple JPEG file with metadata This way will duplicata data of course. Gilles Caulier |
Re: Digikam raw files and darktable
|
|
I have a 5 idea, just tell what you think about it. When digikam founds a raw file, call the raw processor to process the raw file using the xmp file. Get the returned image and store it in the database the same way other thumbnails are stored. Darktable writes its history in an xmp file, so the only thing needed is both software dont override the info written by the other software. So when digikam needs the processed image, simply calls DT and gives the current xmp file. If its the first time darktable sees that image, then it would write the default history and return the image. If the xmp file already has a DT history, it would return the image that result from that iamge. If the user want to manipulate the image, simply open DT from digikam interface and when it's closed, recover the image (the xmp file will have the DT history). I think its a pretty easy way to do it. Do you think there is any issue with this idea? 2017-01-07 16:22 GMT+01:00 Gilles Caulier <[hidden email]>:
|
Re: Digikam raw files and darktable
|
|
In reply to this post by Juan Jose Casafranca
On samedi 7 janvier 2017 15:41:25 CET Juan Jose Casafranca wrote:
(...) > > And of course DK is not DT. But if you want to target photographers, maybe > its a good idea to consider how photographers work. They need a way to > organize their library, which DK is good at, and a way to process raw > files, which DT is good at (DK is not a good raw processor and DT is not > good for library management). But if it's not possible to use DK to > organize raw files with thumbnails preview for processed imaged... then is > useless for managing a raw library. Well, one way to get what you want is to "export" the images you developed in DT to the same folder as where the RAW files are stored. In that way, the current versions of Digikam will take care of generating the thumbnails and store them, without any change in how either program works. And digikam will still have one image file or video per thumbnail stored. And grouping on extension should still work as well. Remco |
Re: Digikam raw files and darktable
|
|
That is not even close to want I want. What I want is the raw thumbnail to be updated... If I have 20 similar raw files, and I decided one of them is the perfect one and I process it, I want its thumbnail in DK to be updated so when I see my 20 files in DK, I know which one is the one I was processing. Maybe with 1 processed file is not a huge gain, but imagine I process the 20 of them, one to BW, one to other thing... Now I want to open the one I processed in BW low contrast... how do I know which one is it? Visual reference is better than tags for this... 2017-01-07 16:39 GMT+01:00 Remco Viëtor <[hidden email]>: On samedi 7 janvier 2017 15:41:25 CET Juan Jose Casafranca wrote: |
Re: Digikam raw files and darktable
|
|
In reply to this post by Gilles Caulier-4
2017-01-07 16:22 GMT+01:00 Gilles Caulier <[hidden email]>:
I'm not asking to change the raw processor. Just asking to allow the user which raw processor wants to use. If the user selects to use DT, simply make him enter the DT executable which will be called when the raw file must be processed. No dependency needed.
|
Re: Digikam raw files and darktable
|
|
In reply to this post by Juan Jose Casafranca
We definitely don't want digikam developers to do any extra work for that. They have their roadmap and want to stay on it. What we want from them is to tell us how could importing thumbnails from darktable to digikam be done with absolute minimal changes in the digikam code. Am I correct ? Also, if the Linux only solution (DBus) is the simplest solution I think we should stick to it. I am actually a windows user and there is no darktable version for Windows so I created a designated virtual machine (ubuntu studio) and do all DAM and photo / video processing there. The pictures folder can be accessed from both Windows and Linux so there is nothing that needs to be done twice. Any changes can be seen in any OS. Sent from my Samsung Galaxy smartphone. -------- Original message -------- From: Juan Jose Casafranca <[hidden email]> Date: 2017-01-07 8:59 AM (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 2017-01-07 16:22 GMT+01:00 Gilles Caulier <[hidden email]>:
I'm not asking to change the raw processor. Just asking to allow the user which raw processor wants to use. If the user selects to use DT, simply make him enter the DT executable which will be called when the raw file must be processed. No dependency needed.
|
Re: Digikam raw files and darktable
|
|
Yes, I don't want digikam developers to do this. I understand that they have their own roadmap. Opensource strength is the possibility for any user to propose changes and implement them if they know how to do it :-) I also think the DBus option is the best one, although it's only Linux available so I will have a look at it 2017-01-07 17:25 GMT+01:00 Andrey Goreev <[hidden email]>:
|
Re: Digikam raw files and darktable
|
|
In reply to this post by Juan Jose Casafranca
On samedi 7 janvier 2017 16:43:58 CET Juan Jose Casafranca wrote:
> That is not even close to want I want. What I want is the raw thumbnail to > be updated... > > If I have 20 similar raw files, and I decided one of them is the perfect > one and I process it, I want its thumbnail in DK to be updated so when I > see my 20 files in DK, I know which one is the one I was processing. Maybe > with 1 processed file is not a huge gain, but imagine I process the 20 of > them, one to BW, one to other thing... Now I want to open the one I > processed in BW low contrast... how do I know which one is it? Visual > reference is better than tags for this... > OK, then we clearly have a different way of working: I want to be able to see the original raw and the edit(s) side by side. And when I have 20 similar raw files, I want to see all these 20 files with their edits (that is supposing I'm going to edit 20 similar images... Not likely when coming back with a few hundred after e.g. an insect hunt). I most certainly do not want to see only the edited result, as that makes it impossible to judge the amount of editing already done, and whether it went too far compared to the original. As for not finding one specific file among your edits, I don't know how you order your files within the Digikam window, but for me the edits would be right next to the original RAW file. Or grouped, so that the edit showed, with the others hidden. I can then open the group and go to the RAW that is there with the same base name. Just one thing I'm curious about: how are you going to handle the case where you have multiple edits from the same RAW file, e.g. both a B/W and a colour edit (yes, this is quite possible with darktable). With your suggestion, you'd have only one thumbnail per RAW file, so how are you ever going to retrieve or remember the other edit? (Even with one thumbnail per edit it's not as straight-forward as i would like it to be, as you don't want to edit the exported jpg, but continue from the DT history stack before export). > 2017-01-07 16:39 GMT+01:00 Remco Viëtor <[hidden email]>: (..) > > > > Well, one way to get what you want is to "export" the images you developed > > in > > DT to the same folder as where the RAW files are stored. In that way, the > > current versions of Digikam will take care of generating the thumbnails > > and > > store them, without any change in how either program works. > > > > And digikam will still have one image file or video per thumbnail stored. > > And > > grouping on extension should still work as well. > > > > Remco |
Re: Digikam raw files and darktable
|
|
On sábado, 7 de enero de 2017 17:39:28 (CET) Remco Viëtor wrote:
> On samedi 7 janvier 2017 16:43:58 CET Juan Jose Casafranca wrote: > > That is not even close to want I want. What I want is the raw thumbnail to > > be updated... > > > > If I have 20 similar raw files, and I decided one of them is the perfect > > one and I process it, I want its thumbnail in DK to be updated so when I > > see my 20 files in DK, I know which one is the one I was processing. Maybe > > with 1 processed file is not a huge gain, but imagine I process the 20 of > > them, one to BW, one to other thing... Now I want to open the one I > > processed in BW low contrast... how do I know which one is it? Visual > > reference is better than tags for this... > > OK, then we clearly have a different way of working: I want to be able to > see the original raw and the edit(s) side by side. And when I have 20 > similar raw files, I want to see all these 20 files with their edits (that > is supposing I'm going to edit 20 similar images... Not likely when coming > back with a few hundred after e.g. an insect hunt). I most certainly do not > want to see only the edited result, as that makes it impossible to judge > the amount of editing already done, and whether it went too far compared to > the original. I usually do a duplicate in the first place so I have the original file, and then the processed ones. This way I can see the amount of processing in each image without exporting any image, just having different xmp, one of them with an empty history. > > As for not finding one specific file among your edits, I don't know how you > order your files within the Digikam window, but for me the edits would be > right next to the original RAW file. Or grouped, so that the edit showed, > with the others hidden. I can then open the group and go to the RAW that is > there with the same base name. > > Just one thing I'm curious about: how are you going to handle the case where > you have multiple edits from the same RAW file, e.g. both a B/W and a > colour edit (yes, this is quite possible with darktable). With your > suggestion, you'd have only one thumbnail per RAW file, so how are you ever > going to retrieve or remember the other edit? > (Even with one thumbnail per edit it's not as straight-forward as i would > like it to be, as you don't want to edit the exported jpg, but continue > from the DT history stack before export). I'm still thinking about this. Of course, it's a very necessary feature. Maybe digikam should show #xmp views instead of #rawfile views for raw files. Or, maybe just saying that "xmp" it's an image format that should be read by digikam, but dont know if this would work or it will continually generate xmp files... > > > 2017-01-07 16:39 GMT+01:00 Remco Viëtor <[hidden email]>: > (..) > > > > Well, one way to get what you want is to "export" the images you > > > developed > > > in > > > DT to the same folder as where the RAW files are stored. In that way, > > > the > > > current versions of Digikam will take care of generating the thumbnails > > > and > > > store them, without any change in how either program works. > > > > > > And digikam will still have one image file or video per thumbnail > > > stored. > > > And > > > grouping on extension should still work as well. > > > > > > Remco |
Re: Digikam raw files and darktable
|
|
In reply to this post by Juan Jose Casafranca
I agree 100%. I am willing to help if needed Sent from my Samsung Galaxy smartphone. -------- Original message -------- From: Juan Jose Casafranca <[hidden email]> Date: 2017-01-07 9:30 AM (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 Yes, I don't want digikam developers to do this. I understand that they have their own roadmap. Opensource strength is the possibility for any user to propose changes and implement them if they know how to do it :-) I also think the DBus option is the best one, although it's only Linux available so I will have a look at it 2017-01-07 17:25 GMT+01:00 Andrey Goreev <[hidden email]>:
|
Re: Digikam raw files and darktable
|
|
Could you look if there is anyway to ask darktable for an image through DBus? The image should be returned without been saved in disk. (As a char* for example). Right now I'm trying to understand how digikam asks for the thumbnails and for the preview images so I can ask for them when it's necessary. 2017-01-07 18:20 GMT+01:00 Andrey Goreev <[hidden email]>:
|
|
|
Just saw this now and have been far far away from DK & DT for a long time, so sorry if I speak outdated: I tried to combine both for my workflow before, with limited success. What I wished for back then was a proper solution in DK for grouping. I wouldn't mind developing my edits into JPEGs (actually want to, since I may have multiple edits as someone said earlier). In the past DK didn't group them well, that's where I had issues. If grouping is working well now I think the preview topic is not really a serious shortcoming, no? On Sun, 8 Jan 2017 at 01:27, Juan Jose Casafranca <[hidden email]> wrote:
|
Re: Digikam raw files and darktable
|
|
I don't know about grouping. Each time I have tried to use DK as my management software I quit because I can't update the thumbnails... If you develop your edits as JPEG because you have several of them, how do you later continue developing one of them because you want to do something else from that point? If you modify the history to do a completely different edit, you lose the other. If you duplicate in DT your image, you cant see both files in DK. If you duplicate the whole raw file so you can see it in DK, you don't know which one is each because thumbnails are outdated and don't represent what the editor has done with the raw file. That's why I want a way to update thumbnails and previews with the current editing history... 2017-01-08 2:20 GMT+01:00 HaJo Schatz <[hidden email]>:
|
|
|
I usually do a "base development" of each RAW. then export this. Then I have some pre-set styles I might apply, e.g. a specific B/W style. That goes on top of my base development. I'd like to have JPEGs exported at both steps and grouped properly, then my world would be fine :) On Sun, 8 Jan 2017 at 09:30, Juan Jose Casafranca <[hidden email]> wrote:
|
Re: Digikam raw files and darktable
|
|
Thats a way of doing things. I usually do different editions and I dont export any of them at least I need to send them somewhere. Thats why I need to see the different views for the different xmps :-) El 8 ene. 2017 2:35, "HaJo Schatz" <[hidden email]> escribió:
|
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |