PhotoFlow News and Updates

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.

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.

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 - Krita 3.3.2 Released | Krita

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.

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?

1 Like

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?

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.

Sidebar.

  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 Like
  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?).

1 Like

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.

Thanks!

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

Yes, gtk3 builds have some issues due to other code I am introducing. I hope to get it sorted out in the next hours…

Could you add “Area” to the non-raw white balance tool? Also, is there a point to a “Camera” mode there?

Yes, I will do it. However, at the moment I am focusing on the completion of the lens correction module, to allow user-selectable camera and/or lens to be used in the correction (for the moment, the module only uses the EXIF data to automatically determine the camera/lens combination…

Yes, for example to give the possibility to apply the original camera WB to a TIFF file that was created from a RAW image and saved in UniWB mode.

I have no time at the moment to elaborate on this, but the basic workflow would be the following:

  • open a RAW image, adjust the WB to taste (so that the demosaicing is performed with optimal WB coefficients), and keep the image in the camera colorspace
  • add a WB adjustment layer, and set it to UniWB. This will likely produce a green-ish image that restores the RGB values as captured by the sensor, but demosaiced
  • save the image as floating-point TIFF
  • open the TIFF, add a WB adjustment layer, and set the WB as you wish. One can also add multiple instances of the WB adjustment module, combined with masks to selectively adjust the WB of different areas of the image
  • finally, add a colorspace conversion layer and convert from the camera colorspace to your preferred working colorspace (sRGB, Rec.2020, ProPhoto…)

The important thing is to perform the WB adjustments in the camera colorspace, otherwise the results might be wrong (particularly if the RGB colorspace is gamma-encoded).

The TIFF file saved as above can be considered as a “processed digital negative”, ready for further processing but already converted from RAW to RGB format…

1 Like

Didn’t expect a response but thanks for giving a longish explanation :snowboarder:.

1 Like

I customarily turn on hot pixel and lens corrections. Recently, I have noticed that lens corrections tool isn’t active. I guess that is because you are working on it. As for hot pixels, it would be nice if there were a prompt that told me whether or not there were hot pixels to clean in the first place.

I have tried turning on and off the hot pixel tool and exporting one of each to compare. One thing I have noticed is that sometimes the difference image yields a slight non-zero grey image when the two exports should probably be equal except for the hot pixels. Then when I re-export one of both, the difference is 0. Haven’t tested this thoroughly.