I have done some work to improve and extend the command-line options in batch processing mode, and wrote a rather extensive blog post that explains all the details.
The rearrangement and update of the command-line options was motivated by the fact that up to now it was not possible to specify the image export parameters (format, bit-depth, output colorspace, image size, port-resize sharpening, etc…) in batch mode.
Now this is fixed in the stable branch, and new packages are available for download.
Among other things, PhotoFlow can now be used as an alternative for high-quality image resizing. All resizing operations are performed on linear-gamma data in 32-bit floating-point precision, using the default high-quality algorithm of the VIPS library.
You can read more and get all the useful details in this blog post.
The latest photoflow-git appimage as well as installation from " ppa:dhor/myway" of 07 Nov 2018 does not open in my system (Linux Mint 18.3 Sylvia). Earlier version of appimage is working OK.
I also may like to add that appimage of rawtherapee “RawTherapee-dev-5.4-1098-ge1742c8.AppImage” also does not open. Earlier version is OK.
Strange! Could you post the full terminal output that you get when you run the failing photoflow and rawtherapee appimages, as well as the ppa version?
The latest release of appimage “PhotoFlow-git-stable-20181108_1224-fbd1fd779dbabe1b3f787e1fb535be86215c0094-x86_64.AppImage” is opening in my system. (Linux Mint 18.3 Sylvia). Will check in detail later.
There’s a typo in phf’s batch code, right now is height, should be heigh… this was driving me
Is there a way to pass arguments for just one parameter; i.e. just the longest side. If not, what’s the proper way of dealing with it? What is working for me now is for an output of 666px wide (longest side) > width=666, height=200000 < I honoured the bug, may live short but shan’t be insulted =)
Just to be sure, in the CLI arguments; 0 (zero) equals to ON/enable and 1 (one) equals OFF/disable?
Even when the image is successfully rendered, I get a buffer: vips_image_get: field "icc-profile-data" not found vips_image_get: field "icc-profile-data" not found care to comment, is it a dead animal, shall I grab shovel and flashlight?
Just out of curiosity what’s high-water mark 60.89 MB referring to?
What I’m using: /photoflow --batch --export-opt=jpg_depth=8,jpg_compress=100,width=666,height=200000,sharpen_enabled=1,sharpen_radius=0.5, profile_type=sRGB,trc_type=linear INPUT OUTPUT.jpg
1.Height is the correct spelling. 2. I don’t think that is possible even in the GUI. I asked a bunch of stuff regarding resize. I am sure that they are on the to-do list.
You’re right , my bad, what was I drinking thinking?!!!
I know you did… for instance with IM’s convert you can “duplicate” the param, say 666x666 and the program would convert to whichever the largest size corresponds.
{22nd century - telepathy and stuff}
me grandpa used to say a real friend was someone who’ll take you offtopic… ohhh the good old times he!!!
Mica, not good enough if can steer right
@afre your exercising will be the end of my good eye; you could at least do a proper, mad flicker rate, epilapsys inducing, way beyond nauseating, clockwork soundtracked subliminous moderfuckin’ gif, then I won’t need dringk. Here some inspiration ,but brace yourself!!
6. Any way to change the scaler in the CLI, I really cannot test if they’re mutually exclusive (if set scale & rotate in pfi)?
7. photoflow --batch [--config=config_file.pfi] --export-opt=[export options] in_file out_file that config_file.pfi is the “normal” edit text file, innit? I use below settings and I’m not able to make it work. What am I doing wrong?
@Carmelo_DrRawphotoflow --batch --help is verbose (43 lines!) before the Usage text. The usage text itself is kind of overwhelming. Is there a way to make it easier to read?
I am also having trouble replicating the GUI export function in CLI. The ranges are different: [0,16383] (CLI) and [5.79227e-005,1.66992] (GUI). The CLI doesn’t retain the profile when I set no_change or make it explicit:
for %i in (*.CR2) do photoflow --batch batch.pfi --export-opt=tiff_depth=32,tiff_compress=1,profile_type=Rec2020,trc_type=linear %i pf\%~ni.tif
Edit: There is a few error messages at the end, which I forgot to copy. Maybe --batch has trouble finding the proper profile.
Indeed there was a bug that I’ve fixed. Now if one dimension is not given it will be automatically computed such that the aspect ratio is preserved.
Thanks for reporting this!
No, it is the opposite: 0->OFF, 1->ON
Why you get this impression? I just tested with the sharpen_enabled parameter, and setting it to 0 indeed disables the sharpening…
I also see that from time to time, but I still have to figure out the exact reason. Seems to be harmless though…
This is the maximum amount of RAM used by the VIPS library to process the image.
There is not jpg_depth option available, and jpg_compress should be jpeg_quality instead. For the rest, it seems correct…
They will be processed sequentially, first the scale/rotate in the .pfi, then the one in the export module.
The help is a bit misleading, and I should correct it. The .pfi must in fact correspond to a PRESET, i.e. a group of one or more layers without the background layer with the input image. The input image is taken from the last-but-one command line parameter…
Hope this is clear. If it still doesn’t work, I’d need a sample input image and config file to see what is going wrong.
I had a look at your batch.pfi file, and I noticed one problem: it contains the RAW loader layer, which should be omitted instead. The RAW loader is automatically inserted at the bottom of the stack when an input RAW file is detected. You should only put the RAW developer (and any layer above it in case there is further processing) in the .pfi
By the way, the .pfi should be actually renamed .pfp to denote a preset. It is only an aesthetic change (the code works fine with both names), but it makes things a bit clearer.
I will change the help messages accordingly.
Could you first try what I suggested? The other problems might be a by-product of the presence of the RAW loader layer…
Indeed there was a bug that I’ve fixed. Now if one dimension is not given it will be automatically computed such that the aspect ratio is preserved.
Thanks for reporting this!
SUPER!! Check Working fine, life’s a tiny bit easier now. thanks
No, it is the opposite: 0->OFF, 1->ON
Why you get this impression? I just tested with the sharpen_enabled parameter, and setting it to 0 indeed disables the sharpening…
Ok, gotcha. Me got too many impressions
buffer: vips_image_get: field “icc-profile-data” not found vips_image_get: field “icc-profile-data” not found
I also see that from time to time, but I still have to figure out the exact reason. Seems to be harmless though…
Ok, gud to know, I started giving milk, calling it bobichu
high-water mark 60.89 MB referring to?
This is the maximum amount of RAM used by the VIPS library to process the image.
this poet coders =)
There is not jpg_depth option available, and jpg_compress should be jpeg_quality instead. For the rest, it seems correct…
Mend it grace
Any way to change the scaler in the CLI, I really cannot test if they’re mutually exclusive (if set scale & rotate in pfi)?
They will be processed sequentially, first the scale/rotate in the .pfi, then the one in the export module.
Ok, I still have to do neu tests (when I figure out the pfi file thingy) and such…lanczos is sometimes just too sharp for 1 stop downscale, IMO.
The help is a bit misleading, and I should correct it. The .pfi must in fact correspond to a PRESET, i.e. a group of one or more layers without the background layer with the input image. The input image is taken from the last-but-one command line parameter…
The help is a glorious mess, I bet was written in the intermission of a quantum photo developing thesis by a playing pong pizza eatin’ penguin, je je - breathe BREATHE!!! SAid Dr. Frankenspock to the potatoe
So you mean save - all but background / raw dev - as a preset (.pfp); IF yes nevermind I tested it with a pfp and does not work… I’ll have to come back to this photoflow --batch [--config=config_file.pfi] later
Okay, now understand; one saves the pfi (photoflow’s settings file) with the backgrounf / raw unchecked; then just --config=PATH-TO.pfi
I slightly edited the --help layout for my own use and sanity. It takes more space but it’s more readable IMO
$ photoflow --batch --help
Usage: photoflow --batch [--config=config_file.pfi] --export-opt=[export options] in_file out_file
The .pfi file should be saved with background or raw layers unchecked. Also 0->OFF and 1->ON
OPTIONS
• profile_type=X (default: sRGB) ICC profile for the exported image
SUB-OPTIONS
no_change: keep the image in the same colorspace used for processing (by default linear Rec2020)
sRGB, Rec2020, AdobeRGB, ProPhoto, ACEScg, ACES: convert the image to the specified colorspace
from_disk: use a custom ICC profile from disk
• profile_name="X.icc" path to profile from disk when "profile_type" is set to "from_disk"
• trc_type=X (default: standard) TRC of the output ICC profile
This option has no effect when using a custom profile from disk
SUB-OPTIONS
- standard: use the standard TRC for the selected colorspace
sRGB TRC for the sRGB colorspace, gamma=2.2 for AdobeRGB, etc...
- linear: linear (gamma=1.0) TRC
- perceptual: same TRC as defined in the CIELab L channel specifications
- sRGB: same TRC as defined in the sRGB specifications
• intent=X (default: relative_colorimetric) Rendering intent for the output ICC conversion.
Only relative and absolute colorimetric intents are implemented for the built-in colorspaces.
Perceptual and saturation intents might be available when using LUT profiles from disk.
SUB-OPTIONS
- relative_colorimetric:
- perceptual:
- saturation:absolute_colorimetric (default:
- relative_colorimetric)
• bpc=0/1 (default: 1) enable/disable black point compensation in the output ICC conversion
Example:
--export-opt=tiff_depth=16,tiff_compress=1,width=800,height=600,sharpen_enabled=1,sharpen_radius=0.5,\
profile_type=Rec2020,trc_type=linear
too
, my bad, what was I 
Working fine, life’s a tiny bit easier now. thanks 
