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 ?
Simon, thanks for the guidance, I will make a try.
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. 
Looks like you need a mime type for PFI, other than plkain text.
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/”.
I added the MIME file in the stable branch, now I have to see how to properly add it in the installation process…
Thanks!
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 
Whatup guys? Would anybody be kind enough to point out how to go about this on OSX 10.11.6 crapikan?
I’ve got Digikam (beta) installed and running and the latest and greatest Photoflow (27-05). I’ve added the .pfi myme on DK’s preferences, on OSX’s system pfis are assigned to be opened with PF by deffault. Following rasimo’s advice I’ve tried to shovel the xml into few dark places… the maschine did not complain, actually did nuthin’. Also - and following the drowned by good but completelly inept inttentions’ newage philosophy - added pfis as sidecar in DK’s preferences. Pfis still doesn’t show on DonnaKaran 
I can’t help you with OSX specific problems, as I don’t use it at all.
However I am unsure whether there is a misconception about digiKam’s sidecar formats: Additional sidecars are never displayed in digiKam. They are invisibly “joined” with a “real” image file. As pfi’s aren’t really sidecars, you should probably add them as an additional image format - then they should be displayed in digiKam.
You’re absoLUT right @rasimo , I had only to remove the dot from myme’s pfi… pssss I pitty the worms that’ll eat my brain. Now the pfi shows its face on DK. THANKS 
, that’s 1 more step into the woman in the dunes. Now I just need Photoflow to open the file directly with the open with shortcut (ctrl+F4) instead of displaying the generic open dialog with the latest used directory; is it possible @Carmelo_DrRaw ? 
REF
the woman in the dunes is how I see this unholly relation between digikam & photoflow,
a couple’s union to be able to breed monsters {poing echo} hoh huo ho 
I have not (yet) tested the digikam/photoflow combination, but with the latest photoflow version (20170527) you do not even need to ask Digikam to open .pfi files…
Suppose you open an img.nef RAW file, you do some edits and you save them as img.pfi.
Next time you will open img.nef, for example from the Digikam interface, photoflow will detect the presence of the img.pfi “sidecar” and will open it instead of the RAW image…
Does this sound reasonable for you?
P.S: let’s hope I’ll get photoflow out of the sand trap… 
I have not (yet) tested the digikam/photoflow combination, but with the latest photoflow version (20170527) you do not even need to ask Digikam to open .pfi files…
Suppose you open an img.nef RAW file, you do some edits and you save them as img.pfi.
Next time you will open img.nef, for example from the Digikam interface, photoflow will detect the presence of the img.pfi “sidecar” and will open it instead of the RAW image…
Does this sound reasonable for you?
Hey @Carmelo_DrRaw I’m not a “reasonable” man by any measure 
These I managed to assimilate (osmosis process):
A - Now PF can save sidecars (pfi)
B - We can launch directly the pfis
C - Pfis are shown in (e.g.) DigiKam
D - We’re able to launch directly from DK
The only thing not working is that D part (have also to do with B). When in DigiKam and the pfi’s triggered with the open with deffault application, Photoflow launches with its “generic” open dialog pointing to the last used folder. Expected behaviour should be directly opening the pfi. The problem seems on PF side, as when I doubleclick a pfi in the finder, it behaves is exactly as mentioned before.
P.S: let’s hope I’ll get photoflow out of the sand trap…
I like that you assumed PF as the male/victim… je je je… but we need babies 
Cheers and THANK YOU 
Not a good gif; how PF behaves when directly triggering a pfi, both from finder and DK =)
This probably means that digikam does not pass the pfi file name to photoflow when it launches it… I need to test that myself to see what happens.
photoflow-20170527 on windows10 : cannot open any file (nef or pfi) except jpg, even the one you sent to me.
Not this issue with photoflow-20170521.