It needs to be added to the windows version as well, but that’s not a big deal (I’ve never had any request so far…). You’ll get a new test package very soon.
It looks nice.
I would try to save expensive vertical space by making the layers and control boxes more condensed. For example, by omitting the box title line (“V basic adjustments”) and by putting the sliders next to the control name This is a summary of suggestions. See the marked lines and arrows, and notice the relocated sliders of brightness/contrast/etc at the bottom left.):
2 Likes
I see two steps where the batch treatment is useful:
- pre development where we can apply the basic raw treatment, with a default preset file. A pfi file is saved for every image with or without output image.
1.1. it could be interesting to have the option to save the pfi file in the same folder as the output image (instead of the source folder). - to produce the final image, resized, watermark, sharpened, …
Another small UI improvement, following a suggestion from @chroma_ghost: if more than one layer is selected when adding a new layer group, the layers get automatically moved inside the new group.
layers get automatically moved inside the new group.
macaroni, stracciatella, umpa lumpas, manga nera, consumismo, riot griot, OSS non SOS 
That how the mice chant when they’re raving around these parts
Today I did try something different: loaded 3 raws (HDR) inside same project and kicked the hell out of PF.
The “bad” thing is that without HSV secondaries for opacity or other effects it takes time, too long.
The good things are that I really like how PF treats inserted raw images, it groups its components (raw loader and raw developer) automatically, nice! Other thing that I liked is that if gradients and/or paths masks are changed to darken or lighten, the work together; a bit cumbersome, but it’s useful. And for my surprise I kicked the hell out of the prog and it didn’t crush, NEAT!
A semi-sourer annoyance possible bug is that as the project gains more layers path masks and gradients tend to get lazy and don’t want to leave the viewer. If PF could align the shots and there was a way of using luminosity masks, I could also see PF as 1 stop, develop,blend and finish HDR shots… for the long distant future, when Logan wakes up. All and all, a lot of fun.
Thank you Mr Pinguin honorious with a camera =)
;
3 Likes
More feedback notes 
I don’t remember if it was like that before, but if so I hadn’t notice it: path can be moved directly in UI which is very nice. Improvement suggestion, something to toogle its wireframe on/off so the result can be reviewed (also individually), maybe for future also area affected visibility, mask, red would be pretty standard.
A couple other hard edges
- Cropped info in gmic’s emulation dropdown menu
- And when giving layers new names it takes way too long, sometimes only apearing after several layers have been created… by then the mice already ate the cheese
{cannot believe there’s not an emoticon for cheese… mon dieu!!!}
Cheeeeers
Yes, it is the same for me too.
there most certainly is!
Ha ha ha Mica 
you saved the 
from a very tough forced migration to Normandy, ha ha ha it was hidden after the sign that normally plays next song, so now all is good these for later, after getting rid of the snake
1 Like
I’ve also noticed those two problems… the first one should be rather easy to fix, on the other hand I’m fighting with the second one since a while…
Thanks!
I have prepared updated packages of the current stable branch, which contain fixes for most of the issues recently pointed out by @chroma_ghost, namely:
- the quality of the scaled-down preview has been greatly improved thanks to a better resizing algorithm
- the changes in layer names are now immediately reflected in the layers list
- the layout of several UI drop-down widgets has been improved
I am also in the process of doing some optimizations of the processing pipeline, which should hopefully bring some performance improvements…
OSX package: Filebin | xbcw6gg3zp7tjfgc
Linux AppImage: Release Continuous build · aferrero2707/PhotoFlow · GitHub
4 Likes
I am also in the process of doing some optimizations of the processing pipeline, which should hopefully bring some performance improvements…
Autobahn Autobahn Autobahn Autobahn Autobahn
4 snails 4 snails 4 snails 4 snails
yes it does as U said, in coming days more thourough punching. I keep collecting dumb ideas and moldy suggestions, but not for today, today enjoyment!!!
Zennkiou =)
1 Like
De nada!!!
Great! Not really important, but this issue riled me every time I bumped into it 
Gracias!!!
1 Like
Can you add a new Windows package?
Sure! I will do it tomorrow…
1 Like
@assaft You can find the updated windows packages here: Release Continuous build · aferrero2707/PhotoFlow · GitHub
From now on, I will add updated Windows and OSX packages on this release page whenever I create new ones…
2 Likes
Andrea would you preffer we submit bugs, issues and suggestions also there or is it okay to do it here?
I would prefer the GitHub issue tracker, simply because the various issues are easier to follow with it…
While improving the photoflow UI, I am also working on the next big release, that will correspond to the 0.3.x series…
One of the main goals of this next release is to add support for processing HDR images in linear RGB colorspaces. The new code will be able to load EXR files and floating-point TIFFs, and will handle the HDR floating point pixel values in unbounded mode.
It will also support some of the most commonly used Tone Mapping Operators, although there is no specific local contrast enhancement available yet…
Here is an example of HDR processing (image courtesy of dutch360hdr):
Original linear RGB image:
Linear RGB image underexposed by 5EV:
Result of Reinhard tone mapping:
Hopefully this code will evolve into a full-featured HDR processing solution… one of the next steps is to add support for floating-point DNGs produced by HDRmerge.
4 Likes