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:
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.
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.
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.