Recently @phweylandhas suggested to introduce the possibility to save sidecar files along with exported TIFFs and Jpegs, to store the processing parameters used to generate the exported images.
This is now implemented in the stable branch, and the new functionality should be soon available through the Linux package managers or the latest AppImage in the continuous build release.
The saving of sidecar files is controlled by a new configuration option, which is disabled by default for backward compatibility:
If enabled, a .tif.pfi or a .jpg.pfi āsidecarā file will always be saved along with exported .tif or .jpg images. When trying to re-open a TIFF or Jpeg image with an associated sidecar file, the program gives the user the option of either opening the image itself, or the sidecar:
This will hopefully improve the integration with DAM tools, like Digikam.
Works perfectly as described (on Linux), thanks Carmelo.
I understand they are personal so far but here are my comments:
What is the benefit to include jpg or tif in the extension of the created pfi (like .tif.pfi) ? If I export the same source to tif or jpg, the pfi file content is exactly the same (as pfi doesnāt describe the export process). If Path/Name of the image file is the same, there is no reason to have different development. Thatās true for jpg & tif, but also for any other format you could add in the future.
Once we have set the configuration option āsave sidecar filesā it is to use it. Asking the question everytime we open the file is a useless click. If some users find the question important, it could be another configuration option: āalways use sidecar filesā.
Now I can see all my output files in the DAM and re-open the development at any time opening the output file itself. Thatās GREAT ! But Iām still missing to re-open the development of the source image (nef). The pfi file attached to the nef file is for me the basic development, where I start from to create one or several output images. I could display the pfi files in the DAM but I would lose the full benefit of your change.
My intial suggestion was the following (without showing pfi file in DAM). Sorry if I have not been clear enough.
If for each image we consider the path, the name and the extension (ext) like path/name.ext. The ext = nef, cr2, ā¦ are source images, but jpg and tif can be source as well.
Case 1 (basic)
path/name.nef
path/name.pfi
(path/name.jpg)
The pfi file can have been created by āSave current Imageā or by āExport current ā¦ā. Whatever the image I open PF opens the nef with pfi development.
Case 2 (extended)
path/name.nef
path/name.pfi
(path/name.jgp)
path/name_xx.jpg (could be path_xx/name.jpg)
path/name_xx.tif (could be path_xx/name.tif)
path/name_xx.pfi (could be path_xx/name.pfi)
If I open name.nef file PF opens the nef file with name.pfi development. If I open the name_xx.jpg (or tif) file PF opens the nef file with name_xx.pfi development.
The case 2 covers the case where the source is a jpg (or tif) file as well. As the pfi knows the source file there is no confusion between the source jpg and the output jpg.
If I understand properly the impact for a non DAM user would be the following, with:
If I open from PF the name.nef file PF would use the name.pfi development instead of no development (or using default.pfp when applicable).
We could use āalways use sidecar filesā to avoid this when not desirable. If set, PF always uses the sidecar file, even for source image. If not set (as default) the current PF behaviour is totally kept.
I apologize for the length of this post. And again a huge Thanks for your work !
Suppose you have a IMG.NEF file that you are processing, and you save your work as IMG.pfi.
Next, you save a master copy as IMG.tiff, and a scaled-down sRGB version for web publishing as IMG.jpg.
If the .tif or .jpg suffixes are not included in the sidecar file name, you would overwrite the .pfi file each time, unless the files are saved in different foldersā¦
As I said, tiff and jpg files might have a different size or color space, additional post-resize sharpening, etcā¦
I would propose simply to add a similar functionality for RAW files, with a [nef/cr2/arw/ā¦].pfi file name automatically proposed the first time the edit is savedā¦
To have a similar functionality for source file would be great !
Some thoughtsā¦
1- Today the default PF behaviour is name.pfi for a name.nef source:
or even a name.jpg source:
I like it ā¦
The source being unique you could keep this behaviour and not include the source extension (nef, ā¦).
2- This must also work for not RAW sources like jpg or tif file. BTW, if you have name.ext.pfi for exported (output) files and name.pfi for source file, you are not obliged to read the the pfi to know if it is a source or an output sidecarā¦
More thoughts ā¦
It is not worth to backup all output files if we have the sources, the pfi and we are able to rebuild the outputs easily.
I was wondering if it could be possible to launch a (PF) batch to do this per tree or per folder.
If I follow your idea about jpg and tif, it should be possible to generate the right file type.
Is the batch processor able to do this ?
Is it available on Linux and Windows ?
Some further work on sidecar filesā¦ the current logic is the following:
when editing a source image img.ext (RAW, TIFF or Jpeg, but not PFI), the Save dialog offers the default option of saving to an img.pfi file.
when exporting the result to img.[jpg,tif], photoflow automatically saves the edit configuration as img.[jpg,tif].pfi
When re-opening a non-PFI image img.ext, the program looks first for an img.pfi sidecar file, and if not found tries with img.ext.pfi. If either one or the other is found, then it is opened instead of the input image, so that the edit gets restored from the sidecar file.
I prefer to keep the option of saving img.[jpg,tif].pfi sidecar files along with the exported images, to keep track of the exact configuration used to generate a given outputā¦
Does this make sense?
I will provide updated Windows and OSX packages in the next few hours.
Concerning the batch processing, it is available on all platforms and requires to run the photoflow executable with the ābatch option, followed by the name of the input and output files. However, I have not tested the batch processing mode in detail under windowsā¦
Sureā¦ here are few simple examples (valid for all platforms, in fact, apart from the executable name and path):
export a .pfi file as Jpeg: path_to_photoflow_installation\bin\photoflow.exe --batch img.pfi img.jpg
export a .pfi file as Jpeg, applying an additional preset on top of the edit in the .pfi file: path_to_photoflow_installation\bin\photoflow.exe --batch img.pfi preset.pfp img.jpg
load a TIFF file, apply a preset and save as .pfi path_to_photoflow_installation\bin\photoflow.exe --batch img.tif preset.pfp img.pfi
Just let me know if you encounter any problems with the batch processing, as it is something that I have tested less than the restā¦
Well, lots of things indeed, but actually not the way the batch processing worksā¦ apart from the replacement of pfbatch by photoflow --batch, all the rest of the article is still valid!
Iāve tried the logic here above:
PF exists immediatly and silently. No pfi created. Same if I try to create a jpg.
āC:\Progra~2\Photoflow\bin\photoflow.exeā opens PF normally.
Once this works I would love to have this work too:
The special %name% prefix will be automatically expanded to the name of the image file, without extension. In the example above, an img.pfi should be createdā¦
The tif or jpg part in ājpg.pfiā doesnāt describe actually the intention or the work done on the image. In your example I would suffix the path or the name ā_Mā for master or ā_Wā for web. But we can have plenty of other goals which are not described by jpg or tif. doing this each pfi file keeps its own *_M or *_W piece of information.
Only the user know and can do that properly, following his own need, process or organization.
I decided to try the latest version 20170527 on MacOS rather than 20170401 I have been using to try out the sidecar file approach. It saved an image.jpg.pfi file as described but exactly as the previous version when you open a image.raw, image.jpg, image.pfi or now the image.jpg.pfi file with photoflow it simply takes you to the āopen existing fileā folder list last used. To be honest this is not a major issue in how Iāve been using photoflow as I tend to be in the same folder for most or all of one session and work directly with photoflow rather than opening via a DAM. It does however mean that the dialogue to select the sidecar file does not appear.
As an aside I noticed that although the newer version continues to work with the .RW2 files from my Panasonic TZ100 the .ORF files originating from my Olympus E-1 and E-620 no longer work, Photoflow just crashes. Has the database of camera profiles used by photoflow changed?
Anyway thanks for the great work on photoflow which Iām really getting to like a lot!
At the moment I am fighting with some crashes in the windows version that occur for any opened imageā¦ once that is fixed, I will finalize the sidecars support.
Indeed I have updated the RAW files definitions to the latest darktable version, but that should not introduce any regressionā¦ I will check.
This seems to be a problem of integration with the OSX systemā¦ does it happen only when you try to open a file from Finder, or also from Digikam?
Anyhow, I will look into that after the next release is out (hopefully by next week), because there are few other OSX integration issues I need to fix (for example, the Cmd-q shortcut does not work for closing the application).
Meanwhile I have prepared a new version that fixes an issue when directly opening .PFI files (and not indirectly via sidecar files). If interested, you can get it here.
I donāt use Digikam much but gave it a try and the problem is the same.
I tried the version you linked to. Not sure what problem it has fixed as I did not have a problem with opening .pfi files directly with version 20170401. It still has a problem opening the .ORF files but then you did not say you had managed to do anything on this.
Iāve just tried loading the E-1 and E-620 samples available at raw.pixls.us, and they open without issuesā¦ could you maybe provide me with an example of .ORF file you cannot open?
Also, could you maybe send me the terminal messages you get when you run photoflow from the console? On my system I can start it this way:
ā¦
