I’ve moved my Lightroom metadata to Digikam (almost !).
I would like to use Photoflow as editor along with Digikam.
From Digikam when I open a raw image in Photoflow for the first time everything is ok, and I save the sidecar pfi.
But the next time I open the same raw image, Photoflow ignores the sidecar pfi file. That where I have a first request: Opening an image (whatever it is), could Photoflow check if a sidecar pfi exists, and that case, use it ?
Then I plan to store the final images into a subfolder (inside the folder containing the raw images), something like PF-Full (for: developed with Photoflow - full size). If I make several versions of the final image, I would like to keep for each version the corresponding pfi. Here is the second request: when exporting an image, could we have the option to save the corresponding sidecar pfi along with the output image ? Re-opening this output image (back to the first request) Photoflow would open the pfi instead and re-use the source raw file …
With this in mind, I (we) would be able to manage source and final images in Digikam and re-open whatever of those with the associated treatments …
I think these principles would work pretty well with any other DAM tool too.
The fact is that .PFI files are not “sidecar” files, but real “image” files.
As such, there is no 1:1 correspondence between a RAW image and the .PFI file into which you save the edit. For example, you can have multiple .PFI files for one single RAW image, if you are trying different edits (I do that quite often).
I would be really reluctant to give up this design logic…
Would there be a way to tell Digikam to open .PFI files with photoflow?
Same for output TIFF/Jpeg files: the .PFI image from which they originate is not a “sidecar”, but the “master” copy. However, in this case it should be not too difficult to save a .tiff.pfi or .jpeg.pfi file together with the exported .tiff or .jpeg.
I will try to implement this in the next days, and let you know.
I’m not expert with Digikam but I’ve made a try in that direction, without success so far.
I understand your point, if you use several pfi files for the same raw image. But …
there is only one pfi file which has the same path & name than the source image. That’s the one that PF could use automatically. Asking the question every time would be cumbersome, but that could be a setting.
in a single pfi file you can have different treatments, you can enable or disable.
Edit: In fact, if you use several pfi files for the same source image, I’m pretty close of your way. The difference is that I’ve an image file associated to each pfi file (same path/name only a different extension)… Is that a correct way to see it ?
If I follow the logic I’m thinking about it may be better to keep path/name and just replace the extension (jpg → pfi)
I understand your concern and I think the automatic association is completely compatible with your logic. If I’m not mistaken you access the image selecting the pfi file. The automatic association complements this, allowing to access the pfi treatment selecting the image file (source or output).
This is really another interesting way. The question is valid for any application allowing to open an image in an external editor. That means the pfi file is recognized as an image file by the system. I don’t know really how to achieve this. Wouldn’t be one of the conditions to have a preview image embedded the pfi file ?
Thinking a bit more about the issue of how to integrate photoflow with DAM tools, and I came up with another idea: save the .pfi data into a specially crafted JPeg thumbnail, where the XML data of the .pfi file is simply concatenated to the JPeg image.
So, when saving the work to .pfi, photoflow would do the following:
generate a small thumbnail from the current layer stack, and save it in Jpeg format with a .pfi.jpg extension
append the XML data to the Jpeg thumbnail, eventually preceded by a special marker to easily identify the end of the Jpeg and the start of the XML
As far as I know, any image viewer will ignore the additional data at the end of the file, and will open the thumbnail like a normal Jpeg. However, when opened with photoflow, the program can look at the special marker and, if present, load the XML data instead of the Jpeg image itself…
Alternatively, the XML data could be embedded in some EXIF/IPTC/XMP tag, but in this case I have no idea which one would be more appropriate…
I don’t know anything about photoflow and from what I understand (it links to potentially several source images) managing them isn’t that simple. But basic recognition and opening should be possible with digiKam like this:
Add the extension to the custom images files in “Mime Types” under “Views” in the configuration wizard. Now these items should be visible, almost certainly without thumbnail though (as digiKam can’t open it).
Then you need to make your system know about .pfi files. If your system uses MIME (which I think all linuxes and osx do, and open with external application doesn’t work on windows anyway I think) you can just add a type yourself: Save photoflow.xml to /usr/share/mime/packages (or similar, for system-wide addition) or ~/.local/share/mime/packages (for user addition) to x-pfi.xml. Then run update-mime-database ~/.local/share/mime/ (or with sudo and /usr/share/mime/ for system-wide). I only tested it with the xfce mime editor, not with digiKam, but there is no reason why it shouldn’t work there.
I’m not a DAM expert … just trying to manage my files.
If we don’t want to manage the output image files in the DAM I think your proposal is great. In the DAM every output image is visible and if edited from there, photoflow will reuse the source image. Only a thumbnail may be a bit short. I would prefer a preview, to be able to have some evaluation of the image from the DAM.
In that case would we keep the pfi itself ? or only the pfi.jpg file ?
On the other hand if we want to manage the output image files (jpeg, tiff …, this is useful to apply to them keywords, etc …) we will see in the DAM twice the same image (the output itself plus the pfi.jpg file) everytime. I think that adds some complexity on the DAM size.
The xmp container alternative is probably cleaner. It could be applicable, not only to a thumbnail but to the output images themselves jpeg or tiff. Every output would include the reference to its source and the treatment which produced it.
The problem here is when we want to publish the output. We need to have the option not to include the pfi information or a tool to remove them.
That’s where the pfi file, seen as output sidecar (I apologize if I embarass you again but I don’t find a better word), may give more freedom while providing the same services. We see the images we have created in DAM. Opening it with Photoflow, we can reedit the treatment. We can publish the output without concern about the treatment data.
There is another topic related to this if we talk about DAM. It’s the treatment of metadata and how they flow across the different tools. About this, does Photoflow transfer the metadata from source to output ?
Saving “sidecar” .pfi files when exporting to TIFF or Jpeg is quite simple to implement, and now I’m getting convinced that it is also really needed.
When opening the TIFF or Jpeg image, photoflow would then look for the sidecar file and load it if present (maybe a dialog asking whether to load the image itself or the sidecar would be a good idea).
I’ll try to get this implemented in the next days, as it should be almost trivial.
And if/when you do that: Custom sidecar extensions will be supported in the upcoming 5.6.0 release of digiKam (meaning moving/renaming/… of the “main item” performs the same operation on the sidecar). A pre-release test bundle is about to be released. Sorry for the shameless promotion
I’ve made the first configuration in DigiKam and pfi files do appear.
I can make “open with”, find PhotoFlow as graphical app and open the image.
I was expecting DigiKam could remember PhotoFlow but it doesn’t.
But good step, I can reopen an already treated image with PhotoFlow.
Now it is discovered that I don’t actually understand anything about mime types xD
The type attribute is set to “image/x-pfi” in the mime file I linked to, so I have no clue why it shows up as text/plain. Maybe someone with actual knowledge on this could shed some light?
I’m the source of confusion. I’ve just set the Digikam setting for pfi file. Then choosing Photoflow to open the pfi file I have ticked “remember…”. I haven’t made anything about mime type on the system side yet.
EDIT: Completing the process.I had already associated pfi file with PhotoFlow (Open with …). But even applying the photoflow.xml method, Digikam still sees the pfi as a text file. BTW after running update-mime-database the photoflow.xml disappears…
Sorry, I included the wrong path (weirdly, because I discovered the same problem myself before I posted…). You need to put photoflow.xml into “mime/packages/”.
Looks better ! And Digikam remembers it can open the pfi file with Photoflow now.
The pfi icon is not bad, but I would prefer the output image itself, if Carmelo can implement the sidecart effect
