PhotoFlow News and Updates


(Carmelo Dr Raw) #126

I will make the histogram and layer list position configurable, should not be very difficult…

Regarding the exposure compensation and its relation with the mask, I will have a look, there might be something wrong going on…

(Carmelo Dr Raw) #127

Over the Christmas vacations I managed to introduce some improvements in the image scaling tool, in particular the choice of the interpolation method. Choices are nearest neighbour, bilinear, bicubic, lanczos2, lanczos3 (the VIPS default) and no halo:

This should give enough flexibility to cover most of the user needs… I think that @elle was requesting the no halo option some times ago.

(Andrew) #128

hi Dr.Raw, can I ask you about white balance factors and clipping please.
In your post in November you were explaining to afre. At the end you said you were testing a workaround to keep all info. Did you get a good outcome?

I’m wondering why any clipping is/was needed. I assume clipping is “if x>1 then set x=1” or whatever the appropriate max value is. To me clipping just seems plain wrong and to be avoided in algorithms if at all possible. Is it possible to always scale values rather than clip them? I may not understand the nuances here. In the original method, I get steps 1 and 2. But in step 3, why not scale by a factor which ensures that the largest R or G or B value resulting will be exactly 1?, i.e. no clipping needed. This surely? means all the tones and colours are accurately represented relative to each other, and leaves the user free to make whatever artistic adjustments they wish via tone curves and other tools.

(Bijan ) #129

A bit off topic but is there a Roadmap for the next few releases of photoflow?


I’m really liking this software. Only wish there was a streamlined workflow with the software that I prefer to use as in not having to treat TIFF exported by Photoflows as file layer and not having to go back to use Photoflow just to export to TIFF.

(Carmelo Dr Raw) #131

I guess you are referring to a possible Krita plug-in… I had a discussion some time ago with the Krita developers, but so far we have not found a good solution for implementing a mechanism similar to that already in use for GIMP, mostly due to the lack of per-layer storage of arbitrary meta-data (the PhF configuration in this specific case). I am still trying to find an acceptable workaround, but at the moment I’m a bit out of ideas, sorry…

Anyway, I’m really glad you like how PhF is evolving, and I really hope to be able to offer you the feature you are asking in a not too far future!


That is similar to my request re G’MIC a while back. To extend that idea, I wonder if we could get a feature where one could use a third party (CLI) app. E.g., PF could pipe its current buffer to gmic (or any other app) and then the result would be sent back to a new layer. Maybe some form of this already exists in PF but I forgot or am unaware about it…?

It would greatly benefit my current workflow, as G’MIC and many of the other CLI apps that I regularly use don’t have color management capabilities, and I don’t want to export, import and configure settings for every intermediary file I need to make use of. The third benefit would be giving the user control over updating his or her own app without waiting for a PF update. I guess the user would have to scale or cut the data to fit an acceptable range so that the third party app would be able to understand the input. That would probably be the most challenging part.

G'MIC in PhotoFlow

When I checked Krita, I do see something to do with XML in filter layers/mask. I wonder if it were possible to say convert PhF configuration to XML data. Maybe something to do with that would finally solve this issue.

(Carmelo Dr Raw) #134

Would you be able to provide me a link to a documentation page? I have tried to find some information, but without success… Thanks!


Well, the only information I have is this quote here found in -

Filters: it’s now possible to edit the filter’s settings directly in the xml that is used to save filter definitions to .krita files.

So, there needs to be some sort of bridge between Krita and Photoflow to make it happen, but if storing configuration is all there needs to be. XML is probably the answer here, and you might be set here. XML store information like color depth, filter data, and so on.

(Carmelo Dr Raw) #136

I just implemented a small UI improvement: there is now an option that allows to place the histogram and layer list on the right of the preview:

A restart of the application is needed for the new setting to take effect…

Next step will be add an option to put the active tool controls into a floating dialog (instead of the bottom of the layers list as it is right now). This should give more space for the layers list itself, and allow to place the controls anywhere on the screen. What do you think?

Unbounded Floating Point Pipelines

if it floats over the image it will be harder to see the effect a tool has while changing parameters…or how would you solve it?

(Carmelo Dr Raw) #138

On the contrary, it would be possible to put the dialog closer to the image portion affected by the parameter changes, thus reducing the eye movements… the floating dialog would be significantly smaller than the preview area, and therefore only covering a small portion of it. I think it is probably a question of personal taste, and therefore should be given as an option. I will try to make a “teaser” screenshot to explain what I have in mind.


@Carmelo_DrRaw I would

  • Let the side panel occupy the full height of the window.

  • Combine the top and bottom row of icons into one row.

  • In the remaining space maybe place

    1. A samplers table. That way you could remove the histogram / samplers tabs to give a bit more vertical real estate to the panel.
    2. Or metadata of the image that is currently active.
    3. Or as I requested before, the full names of the embedded, working and export profiles.


I understand, makes sense. And you would get rid of a lot of scrolling.
I am curious to see your teaser.

Adding to @afre’s suggestions:
Do you need the tab rider on top of the image?
The file name could be shown in the window’s top frame. Or are there cases were you would have multiple images open?


@McCap There is utility in that, unless it is possible to open multiple instances of PF.

I am glad we are talking about this because maximizing the use of real estate is important to users with small screens (like me).


I just downloaded the latest update (gtk3). Probably just early days but allow me to make some observations. First, the screenshot.

  1. Now, it is more apparent than ever that the bottom row should join the top and that the the sidebar should span the full height of the window. My reason is not only to save space but that the bottom row doesn’t appear to be “grounded” and it requires extra eyeball movement to reach.


  1. Would be nice to know where the handle is for adjusting the width like the double lines in between the layer and parameter sections.

  2. The screenshot shows the min width of the sidebar. Any attempt to make it narrower would cut out its right portion. There is no horizontal scroll bar currently and the right justified controls also don’t move leftward even though there is still space to the left.

  3. As you can see by the vertical scroll bar, the sections within the sidebar should have a wider margin or padding, and perhaps a border.

  4. Lastly, the toggle titles (“image info”, “more”) should probably look different from the other headings and with an arrow icon to show that they are toggles. Maybe “image info” doesn’t have to exist. Instead, perhaps integrate the toggle into the histogram and samplers row.

  1. Layer section’s height resets with each restart.

  2. Making the sidebar wide has weird side effects on relaunch.
    a. The contents spread out horizontally in a strange way and the min width is increased.
    b. If it is super wide, the preview image keeps on redrawing and bouncing left and right.
    c. The sidebar cannot be resized to a sane size again (need to delete prefs?).

(Carmelo Dr Raw) #144

Hopefully the weird behavior of the preview area is fixed in the latest version that I have just committed (packages will be ready in about one hour…).

The rest of the UI suggestions are very good, I will try at least to work on the regrouping of the top and bottom rows during next week. I will also do some more detailed testing of the Windows versions, and see if they behave differently from the Linux ones from the UI point of view.



Only see photoflow-w64-20180121_0044, which isn’t GTK3.