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.
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.
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?
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.
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?
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.
Would be nice to know where the handle is for adjusting the width like the double lines in between the layer and parameter sections.
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.
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.
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.
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?).
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.
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…
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.