mikae1
August 7, 2026, 2:56pm
438
For sure! Perhaps @paperdigits could move a bunch of posts to a new to a new “resize module for darktable” topic. If so, here are the posts (from oldest to newest) that tracks the development of the resize module:
…and again, I feel obliged to add that upscaling should be done before the Spektrafilm module . Now I’m sitting here editing a job partly shot on an A7S III (12 MP) and I need to upscale. Can’t use the Spektrafilm module for this, which saddens me. But I should spare you all from my thoughts on this and come back in a separate thread with an idea for a solution.
Don’t you think an upscale module which can be placed before the spektrafilm one would make more sense than integrating upscale code into this module? For the standalone app I think it makes sense to have this feature but for darktable a separate module would fit better I guess. Let me look into this after the fixes for the above bug.
upscale-module.patch (18.1 KB)
Currently CPU only but ready to initial testing I guess. Will add an opencl path later as it’s really slow
Yes! A “resample” module for the darkroom is exactly where I’ve landed in my own reasoning.
Haha, woot. Move fast and break create things!
Nifty! Hacky and cumbersome but a temporary solution. Preview is messed up/pixelated with green borders and it upscaling maxes out at 2x.
Yeah, I’ll do my best later today. Have never built darktable.
Yeah, I’ll do my best later today. Have never built darktable. [3x_without_resize_module_new]
Upscaling 3x with the resize module:
[3x_with_resize_module_new]
spektrafilm is, as I’ve mentioned before, darn …
Did you see @piratenpanda ? Lot’s of posts here, no stress, just want to make sure it didn’t go unnoticed. @gwbarn shared.
yes, this is a proper weekend problem
Oh, I see. Sorry for that!
no need to be sorry. this needs fixing
Should fix the issue I think. But god is 4x upscale slow even on my Ryzen 9 resize-module.patch (25.5 KB)
Now looking at the Magic Kernel Sharp algorithm
with both 2013 and 2021 algorithms:
resize-module.patch (31.2 KB)
now with opencl (which will only be fast until the new image size is bigger than your GPU memory. Afterwards only the CPU path is being used)
resize-module.patch (43.5 KB)
Spektrafilm doesn’t limit it. We do. Spektrafilm should do the same as values above one don’t make sense and only confuse people that’s why I hard limited it. Also different films break at different values above one so I’d rather not explain to the users why their values break the edits.
Here’s an updated resize module:
resize-module.patch (49.6 KB)
[grafik]
Now has another slider for the long edge and it shows the final size
Will think about this. Sounds reasonable but I don’t know the …
I get it. I don’t think I ever used a value above 1.10 or 1.15 in Spektrafilm. It breaks fast above that, but it might be valuable to have it there with a really limited range above 1 and if it’s technically a more correct way of increasing saturation for film (compared to just increasing in color balance rgb).
Nice! Have not attempted to benchmark. Do you know if it mathematically should be a penalty of settings px vs factor scaling?
Can you try this?
resize-module.patch (50.8 KB)
Speed is the same, it uses scale factor internally and just displays the information in a more user friendly way
Haven’t checked, can try later today.
Well, if that’s the case I propose we just skip the scale factor slider, the pixel slider is enough. But, we could display scale factor along the output pixels…
What I mean by this is that: At the end of the “9568 × 6376 → 8420 × 5611 px” row in the (old, not updated) screenshot below we show (scaled 0.88×)
[image]
I can build again and test when this change is made too, if you think it sounds good.
for a quick and dirty testing module I don’t see the point actually to polish it
Sorry, don’t know what else to comment on [image]
Again, details!
1 Like