Looks like I messed up with the printf() formatting… could you check again?
Thanks!
EDIT: I deleted the latest win64 package… a new one will be available soon here.
Now all the sample points look just right - thank you very much! The only issue I see now, and this was true before pulling and recompiling - so I should have mentione it earlier - is that Sample Point #4 doesn’t have a “4” near it.
I noticed that as well. I wonder if that has to do with how the code is laid out. When we had 8 points, pts 4-8 didn’t have a label; I reported this previously.
That’s just due to my laziness… I’ll fix that now that the functionality seems to be OK.
It is ready now…
Great! I will check it out later and report back on this and filmic2.
Update 1: Samplers
They work fine albeit a little slower (4-12s). When activated, R=, G= and B= for the given sampler box all turn into x=. They run slower when there is another image layer. Might be a good idea to allow the user to resize the sampler info box vertically.
Actually, something strange happens when I import an artificially created image (500x500, blue).
-
If I load this image by itself and try activating a sampler, PF crashes.
-
If I load this image as an image layer, it might redraw the background while applying the new layer and as a result take a longer time to arrive at the “Ready” state, sometimes much longer because it doesn’t appear to be a simple redraw. This happens most of the time when I toggle off that layer; and whether that happens when loading or toggling on might depend on what the background image is (just speculating - don’t know the cause to this slowdown). It most certainly happens with a sampler or two active.
-
In the scenario #2, activated samplers may disappear and the ones that remain shift in position when the image layer is active. Also, toggling samplers will slow down to approximately the extended time it takes to toggle the image layer off.
-
With the image layer, values may go out of whack during the transition between toggle on and off, or stay unusual when on.
Update 2:
More on what was discussed in update 1. I briefly tried doing the above in the previous unstable.
-
PF doesn’t crash.
-
Calculations and redraws still take time but are much snappier.
Also, this calculation and redraw business suffers from the 2-4x slowdown only when I import the blue square. The new sampler implementation makes things slower but not as much as when the square has been imported in the newest unstable.
Could you share the blue image you have been using for your tests? I suspect some color management problem…
@Carmelo_DrRaw blue image: same as the one in my previous post, just displayed as 50x50 
.
I have been enjoying every new updates about Photoflow even though it isn’t ready as a software.
Next item on my list are true L/C/H blend modes… then of course I’ll start turning my code into a real software 
It seems pretty usable to me!
4 Likes
Awesome, and by real software, selection tools will come soon? If so, I can pretty much uninstall GIMP soon. Might as well start a topic about Photoflow in r/Linux, ycombinator and so on whenever you’re ready. By the way, what happened to the Krita plugin?
What do you need selections tools for? This is at the moment not really foreseen, as photoflow is using masks and not selections for local adjustments… what is definitely needed is a way to draw simple shapes (rectangles, circles, polygons, etc…) in a mask.
It is very usable!
2 Likes
Defringe is crashing PF on OK.
BTW, @Carmelo_DrRaw, my next youtube tutorial will be about having fun with the overlay mode using Photoflow. I actually already recorded it, but noticed that it sucked (
), so I’ll have to redo it once I have time.
1 Like
Did you check with the latest windows package from yesterday.
There was indeed a bug that I fixed yesterday evening, and now defringe works stable at least on my system…
Looks like all of my problems (filmic, defringe and maybe samplers) may be related to this. Logs:
-
filmic: log_filmic.txt (20.0 KB)
-
defringe: log_defringe.txt (15.3 KB)
-
input profile none: log_none.txt (17.2 KB)
-
sample image: https://pixls-discuss.s3.amazonaws.com/original/2X/c/cf945f66bd5e4d6e4abe5441416b0ef1faf8c712.png
I have just committed some new features in the linear_gamma branch, which add LCH blend modes and fix an issue in the luminance mode.
By the way, the luminance blend scales the RGB values of the bottom layer by the ratio of the top and bottom luminances (coinciding with the Y channel after an RGB → XYZ conversion). The resulting image has the same luminance as the top layer and approximately the same Hue as the bottom one, while the Chroma is not preserved.
On the other hand, the LCH L blend mode exactly preserves both the Chroma and Hue of the bottom layer.
Here is the result of blending two gradients (one colored at the bottom, and a grayscale one at the top) in luminance and LCH L modes:
Bottom gradient:
Top gradient:
Luminance blend:
LCH L blend:
This should fulfil one of the requests by @Reptorian and others.
Maybe @Elle has some good suggestion regarding which one is more appropriate depending what you want to achieve…
I have also changed the default behaviour of the image loader regarding image files without embedded profiles. Now the code assumes sRGB in such cases (although you still can force a different profile if needed). This should fix the problems recently reported by @afre.
EDIT: OSX and Win64 packages are on their way, they should soon appear here.
1 Like
I dunno nuthin ‘bout fancy zings’ insides - that’s for @afre’s third eye - but changes… I can see, buttons I can press and they’re most welcome, indeed the filmic acapella is a powerful ghettoblaster, thank you Mr Dr Sir Penguin Raw
2 Likes