Digikam raw files and darktable
Locked
1234
1234
 
|
isn't that more of a DT issue first - some sort of stack branching, a la revision control including a preview per branch? Or export, for that matter ;) On Sun, 8 Jan 2017 at 09:40, Juan Jose Casafranca <[hidden email]> wrote:
|
Re: Digikam raw files and darktable
|
|
Currently, DT allows to duplicate a "raw file". What this does is to duplicate the xmp file where the history is stored. So what Im trying to do is to load this xmps, generate two views in DK where each of them have the correct thumbnail and preview. There is nothing to be done in DT, although some kind of revision history as the one used in git will be marbelous :-) El 8 ene. 2017 2:49, "HaJo Schatz" <[hidden email]> escribió:
|
Re: Digikam raw files and darktable
|
|
In reply to this post by Juan Jose Casafranca
Umm, no… Like I’m sure that others do, my workflow includes both programs on Mac OS. Please, don’t suggest leaving us out in the cold!
|
signature.asc (465 bytes)
Re: Digikam raw files and darktable
|
|
On miércoles, 11 de enero de 2017 21:15:06 (CET) J Albrecht wrote:
> > On 07 Jan 2017, at 08:41, Juan Jose Casafranca <[hidden email]> wrote: > > > > (Anyway, windows and mac users already has another raw > > processing workflow which includes other software, dont they?) > > Umm, no… Like I’m sure that others do, my workflow includes both programs > on Mac OS. Please, don’t suggest leaving us out in the cold! I will take that into account when I begin doing the code ;-) |
Re: Digikam raw files and darktable
|
|
In reply to this post by Juan Jose Casafranca
For the Developer’s benefit, I’d like to reiterate the above statement: digiKam is a brilliant program but please, let’s maintain the focus on where it is brilliant rather than trying to craft it into an all-singing-all-dancing piece of bloatware comprising relatively mediocre modules just for the sake of doing so. In the FOSS realm, digikam is an excellent Digital Asset Management program, darktable is, IMHO, the best Raw editor and GIMP is unparalleled for post-processing. It’s folly and perhaps a bit arrogant to assume that Users would willingly be hobbled by using only one program simply because they are “loyal” to that program. Wouldn’t it be nice if we could just all get along….
|
Re: Digikam raw files and darktable
|
|
Thanks Albrecht, that's exactly my opinion and the reason I want to develop this module :-) 2017-01-12 15:15 GMT+01:00 J Albrecht <[hidden email]>:
|
Re: Digikam raw files and darktable
|
|
In reply to this post by Juan Jose Casafranca
I agree 100% but digikam devs have their own point of view on how the program should look like and we need to respect it. This is how fork projects appear. If it is not too complicated to replace libraw with darktable a fork could be not a bad idea. Someone will have to maintain it though, new versions of both digikam and darktable come out pretty frequently. Sent from my Samsung Galaxy smartphone. -------- Original message -------- From: Juan Jose Casafranca <[hidden email]> Date: 2017-01-13 8:29 AM (GMT-07:00) To: digiKam - Home Manage your photographs as a professional with the power of open source <[hidden email]> Cc: [hidden email], darktable-user <[hidden email]> Subject: Re: Digikam raw files and darktable Thanks Albrecht, that's exactly my opinion and the reason I want to develop this module :-) 2017-01-12 15:15 GMT+01:00 J Albrecht <[hidden email]>:
|
|
|
Dear all,
Then we would need to have a fork for RawTherapee, one for LightZone (which I both prefer to Darktable for RAF file editing) and so on .... would it not be better to have a mechanism to use the preferred editor? Best Regards Quoting Andrey Goreev <[hidden email]>: > I agree 100% but digikam devs have their own point of view on how > the program should look like and we need to respect it. > This is how fork projects appear. If it is not too complicated to > replace libraw with darktable a fork could be not a bad idea. > Someone will have to maintain it though, new versions of both > digikam and darktable come out pretty frequently. > > Sent from my Samsung Galaxy smartphone. > -------- Original message --------From: Juan Jose Casafranca > <[hidden email]> Date: 2017-01-13 8:29 AM (GMT-07:00) To: > digiKam - Home Manage your photographs as a professional with the > power of open source <[hidden email]> Cc: > [hidden email], darktable-user > <[hidden email]> Subject: Re: Digikam raw files > and darktable > Thanks Albrecht, that's exactly my opinion and the reason I want to > develop this module :-) > 2017-01-12 15:15 GMT+01:00 J Albrecht <[hidden email]>: > > On 07 Jan 2017, at 09:41, Juan Jose Casafranca <[hidden email]> wrote: > 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). > For the Developer’s benefit, I’d like to reiterate the above > statement: digiKam is a brilliant program but please, let’s maintain > the focus on where it is brilliant rather than trying to craft it > into an all-singing-all-dancing piece of bloatware comprising > relatively mediocre modules just for the sake of doing so. In the > FOSS realm, digikam is an excellent Digital Asset Management > program, darktable is, IMHO, the best Raw editor and GIMP is > unparalleled for post-processing. It’s folly and perhaps a bit > arrogant to assume that Users would willingly be hobbled by using > only one program simply because they are “loyal” to that program. > Wouldn’t it be nice if we could just all get along…. |
Re: Digikam raw files and darktable
|
|
And that is my intentionm not replacing the raw editoe but calling the external one to receive the edited image El 13 ene. 2017 5:01 PM, "cerp" <[hidden email]> escribió: Dear all, |
|
|
Dear Juan Jose,
I think it is an interesting concept particularly if the plugin allowed to chose every time from a series of possible RAW editors. Best, Quoting Juan Jose Casafranca <[hidden email]>: > And that is my intentionm not replacing the raw editoe but calling the > external one to receive the edited image > > El 13 ene. 2017 5:01 PM, "cerp" <[hidden email]> escribió: > >> Dear all, >> >> Then we would need to have a fork for RawTherapee, one for LightZone >> (which I both prefer to Darktable for RAF file editing) and so on .... >> would it not be better to have a mechanism to use the preferred editor? >> >> Best Regards >> >> Quoting Andrey Goreev <[hidden email]>: >> >> I agree 100% but digikam devs have their own point of view on how the >>> program should look like and we need to respect it. >>> This is how fork projects appear. If it is not too complicated to replace >>> libraw with darktable a fork could be not a bad idea. >>> Someone will have to maintain it though, new versions of both digikam and >>> darktable come out pretty frequently. >>> >>> Sent from my Samsung Galaxy smartphone. >>> -------- Original message --------From: Juan Jose Casafranca < >>> [hidden email]> Date: 2017-01-13 8:29 AM (GMT-07:00) To: digiKam - >>> Home Manage your photographs as a professional with the power of open >>> source <[hidden email]> Cc: [hidden email], >>> darktable-user <[hidden email]> Subject: Re: Digikam >>> raw files and darktable >>> Thanks Albrecht, that's exactly my opinion and the reason I want to >>> develop this module :-) >>> 2017-01-12 15:15 GMT+01:00 J Albrecht <[hidden email]>: >>> >>> On 07 Jan 2017, at 09:41, Juan Jose Casafranca <[hidden email]> >>> wrote: >>> 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). >>> For the Developer’s benefit, I’d like to reiterate the above statement: >>> digiKam is a brilliant program but please, let’s maintain the focus on >>> where it is brilliant rather than trying to craft it into an >>> all-singing-all-dancing piece of bloatware comprising relatively mediocre >>> modules just for the sake of doing so. In the FOSS realm, digikam is an >>> excellent Digital Asset Management program, darktable is, IMHO, the best >>> Raw editor and GIMP is unparalleled for post-processing. It’s folly and >>> perhaps a bit arrogant to assume that Users would willingly be hobbled by >>> using only one program simply because they are “loyal” to that program. >>> Wouldn’t it be nice if we could just all get along…. >>> >> >> >> >> |
Re: Digikam raw files and darktable
|
|
In linux there is already the option "Open with..." which is what you
are asking for. Juan wants to go one step further and generate thumbnails of raw fails according to how they are processed, using external tools. On 13/01/17 19:46, cerp wrote: > Dear Juan Jose, > > I think it is an interesting concept particularly if the plugin > allowed to chose every time from a series of possible RAW editors. > > Best, > > > > Quoting Juan Jose Casafranca <[hidden email]>: > >> And that is my intentionm not replacing the raw editoe but calling the >> external one to receive the edited image >> >> El 13 ene. 2017 5:01 PM, "cerp" <[hidden email]> escribió: >> >>> Dear all, >>> >>> Then we would need to have a fork for RawTherapee, one for LightZone >>> (which I both prefer to Darktable for RAF file editing) and so on .... >>> would it not be better to have a mechanism to use the preferred editor? >>> >>> Best Regards >>> >>> Quoting Andrey Goreev <[hidden email]>: >>> >>> I agree 100% but digikam devs have their own point of view on how the >>>> program should look like and we need to respect it. >>>> This is how fork projects appear. If it is not too complicated to >>>> replace >>>> libraw with darktable a fork could be not a bad idea. >>>> Someone will have to maintain it though, new versions of both >>>> digikam and >>>> darktable come out pretty frequently. >>>> >>>> Sent from my Samsung Galaxy smartphone. >>>> -------- Original message --------From: Juan Jose Casafranca < >>>> [hidden email]> Date: 2017-01-13 8:29 AM (GMT-07:00) To: >>>> digiKam - >>>> Home Manage your photographs as a professional with the power of open >>>> source <[hidden email]> Cc: [hidden email], >>>> darktable-user <[hidden email]> Subject: Re: >>>> Digikam >>>> raw files and darktable >>>> Thanks Albrecht, that's exactly my opinion and the reason I want to >>>> develop this module :-) >>>> 2017-01-12 15:15 GMT+01:00 J Albrecht <[hidden email]>: >>>> >>>> On 07 Jan 2017, at 09:41, Juan Jose Casafranca <[hidden email]> >>>> wrote: >>>> 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). >>>> For the Developer’s benefit, I’d like to reiterate the above >>>> statement: >>>> digiKam is a brilliant program but please, let’s maintain the focus on >>>> where it is brilliant rather than trying to craft it into an >>>> all-singing-all-dancing piece of bloatware comprising relatively >>>> mediocre >>>> modules just for the sake of doing so. In the FOSS realm, digikam >>>> is an >>>> excellent Digital Asset Management program, darktable is, IMHO, the >>>> best >>>> Raw editor and GIMP is unparalleled for post-processing. It’s folly >>>> and >>>> perhaps a bit arrogant to assume that Users would willingly be >>>> hobbled by >>>> using only one program simply because they are “loyal” to that >>>> program. >>>> Wouldn’t it be nice if we could just all get along…. >>>> >>> >>> >>> >>> > > > |
Re: Digikam raw files and darktable
|
|
I think that this also includes the ability to choose a default editor (either Raw or Post). Thus, those who are satisfied with the limited capabilities of the incumbent digikam raw and editing modules can continue to use them while those of us who require more advanced capabilities can do it seamlessly.
|
Re: Digikam raw files and darktable
|
|
By the way… darktable uses an optional lua script to allow a user to open a selected file in Gimp. The file is then auto-magically returned to darktable as a new edited instance after Gimp has been closed. Is this something that can be used from the digiKam side to provide the desired functionality?
|
Re: Digikam raw files and darktable
|
|
Maybe the lua script is a good approach, at least it saves the file in disk and the open it. I'll check it. Simon, you have explained really well what I'm trying to do :-) 2017-01-13 21:57 GMT+01:00 J Albrecht <[hidden email]>:
|
|
|
In reply to this post by J Albrecht
This is how I interpreted it as well. In other words when you open the
Image Editor on a RAW files you can choose the internal editor or any of the others (Darktable, Lightzone, Rawtherapee or whatever) and integrate outcomes seamlessly into the workflow managed with digikam. Is that correct, Juan? Best, Quoting J Albrecht <[hidden email]>: >> On 13 Jan 2017, at 14:26, Simon Frei <[hidden email]> wrote: >> >> wants to go one step further and generate thumbnails of raw fails >> according to how they are processed, using external tools. > > I think that this also includes the ability to choose a default > editor (either Raw or Post). Thus, those who are satisfied with the > limited capabilities of the incumbent digikam raw and editing > modules can continue to use them while those of us who require more > advanced capabilities can do it seamlessly. |
Re: Digikam raw files and darktable
|
|
More or less. I prefer to think that the user has defined a default raw processor (normally, users only use one raw processor, dont they?) and all the raw files will be decoded using that raw processor in order to generate the thumbnail and preview image. When the user opens that file, it will be opened in the default raw processor and after the edition is done, thumbnail will be updated accordingly.
Maybe allowing the user to select a specific raw processor for a specific raw file can be done, but lets do things one step at a time. The original idea is already hard for me, as I've never worked neither with digikam code nor any other raw processor but DT. |
|
|
Dear Juan,
I am not sure people use always the same editor. People may have more than one camera using different RAW format, and you tend to use the best RAW editor for the specific format. For example, we use a combination of editors. Even proprietary software we have used CaptureOne, Lightroom and Silkypix, depending on the camera (CaptureOne and Lightroom for the Leica, Silkypix for the RAF). This is even more true in the OS environment. Best, Quoting Juan Jose Casafranca <[hidden email]>: > More or less. I prefer to think that the user has defined a default raw > processor (normally, users only use one raw processor, dont they?) and all > the raw files will be decoded using that raw processor in order to generate > the thumbnail and preview image. When the user opens that file, it will be > opened in the default raw processor and after the edition is done, > thumbnail will be updated accordingly. > > Maybe allowing the user to select a specific raw processor for a specific > raw file can be done, but lets do things one step at a time. The original > idea is already hard for me, as I've never worked neither with digikam code > nor any other raw processor but DT. |
Re: Digikam raw files and darktable
|
|
I havent thought it that way since Ive always use nikon cameras, but ypu may be right. Anyway, as I said, lets try to hace a working concept for a global raw processor and after that, think about other necessities. This weekend Ill begin to study DK code to try to find a way of implementing this feature. Thanks for the tips :-) El 13 ene. 2017 11:57 PM, "cerp" <[hidden email]> escribió: Dear Juan, |
|
|
Hi Juan,
Maybe there is one more option. The solution in this case is in darktable instead of in digiKam:
* have DT store an export of the current state of processing as PGF in DK's thumbs database, overwriting the current thumbnail for DK * use an external database for DK, so that it is accessible even when DK is not running
The first hurdles I see are: * storage options of DT do not include 'save in database' as target storage * storage options of DT do not include 'PGF' as file format option * I have never had a look in the thumbs-db, and no idea whether the thumbnailname is identical to the file name
It seems that there are Lua-options to work with PGF, there are MySQL-Lua-bindings and DT can use Lua scripts, so it may be a viable path.
The result would be that DK 'just shows' the thumbnail of latest version of the photo, even without knowing it does. Whenever you're sick of seeing the thumbnail of the latest version of the photo, you open the photo (via any route) in DT, go back to a previous step and save the new thumbnail to the database.
Best regards,
Boudewijn
PS, the thumbnail maintenance may be this code (please correct me if wrong!), I see insert, replace and update being handled by id, where the thumbnails.id = thumbid from filepath.
QHash<QString, int> ThumbsDb::getFilePathsWithThumbnail() { DbEngineSqlQuery query = d->db->prepareQuery(QString::fromLatin1("SELECT path, id " "FROM FilePaths " " INNER JOIN Thumbnails ON FilePaths.thumbId=Thumbnails.id " "WHERE type BETWEEN %1 AND %2;") .arg(DatabaseThumbnail::PGF) .arg(DatabaseThumbnail::PNG));
if (!d->db->exec(query)) { return QHash<QString, int>(); }
QHash <QString, int> filePaths;
while (query.next()) { filePaths[query.value(0).toString()] = query.value(1).toInt(); }
return filePaths; }
BdEngineBackend::QueryState ThumbsDb::replaceThumbnail(const ThumbsDbInfo& info) { return d->db->execSql(QLatin1String("REPLACE INTO Thumbnails (id, type, modificationDate, orientationHint, data) VALUES(?, ?, ?, ?, ?);"), QList<QVariant>() << info.id << info.type << info.modificationDate << info.orientationHint << info.data); }
On zaterdag 14 januari 2017 01:39:11 CET Juan Jose Casafranca wrote: > I havent thought it that way since Ive always use nikon cameras, but ypu > may be right. > > Anyway, as I said, lets try to hace a working concept for a global raw > processor and after that, think about other necessities. > > This weekend Ill begin to study DK code to try to find a way of > implementing this feature. > > Thanks for the tips :-) > > El 13 ene. 2017 11:57 PM, "cerp" <[hidden email]> escribió: > > Dear Juan, > > I am not sure people use always the same editor. People may have more than > one camera using different RAW format, and you tend to use the best RAW > editor for the specific format. For example, we use a combination of > editors. Even proprietary software we have used CaptureOne, Lightroom and > Silkypix, depending on the camera (CaptureOne and Lightroom for the Leica, > Silkypix for the RAF). > > This is even more true in the OS environment. > > > Best, > > Quoting Juan Jose Casafranca <[hidden email]>: > > More or less. I prefer to think that the user has defined a default raw > > > processor (normally, users only use one raw processor, dont they?) and all > > the raw files will be decoded using that raw processor in order to > > generate > > the thumbnail and preview image. When the user opens that file, it will be > > opened in the default raw processor and after the edition is done, > > thumbnail will be updated accordingly. > > > > Maybe allowing the user to select a specific raw processor for a specific > > raw file can be done, but lets do things one step at a time. The original > > idea is already hard for me, as I've never worked neither with digikam > > code > > nor any other raw processor but DT.
|
Re: Digikam raw files and darktable
|
|
Is that a darktable only solution? I dont want a darktable only solution but a global solution, for several raw processors. When I say darktable, its because its the raw processor I use, not because it deserves a special treatment. I still think that a solution in which dk calls the raw processor to generate the processed image is the best. El 14 ene. 2017 22:47, "Boudewijn" <[hidden email]> escribió:
|
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |