A free high quality resampling tool for ImageMagick users

[NicolasRobidoux]

Bart:
Just like I've mentioned before that I am not sure that the Keys cubics RobidouxSoft, Robidoux and RobidouxSharp are absolutely the best one can do, among Keys cubics, or more generally among BC-splines, I am not sure that the EWA Jinc-windowed Jinc 3 lobe methods LanczosSharpest, LanczosRadius, and LanczosSharp (either of the two variants) are necessarily the best among all deblurred EWA Jinc-windowed Jinc 3-lobe methods.
They seem to produce very good results. But I'm not sure they are necessarily the best. (The optimized ones are the best w.r.t. some criterions, but being the fastest 100m runner does not make you a good cook.)
-----
By letting users choose the amount of deblur (in the guise of sharpening), we can learn something. And we give them flexibility.
I am pretty sure that the criterion used to optimize EWA LanczosSharpest (.88...) implies that one should not deblur more than that, and I see no reason to go more blurry than "classical" EWA Lanczos (blur = 1).

[Bart_van_der_Wolf]

Nicolas, I can't find out how to calculate an expression in ImageMagick. Do you have any idea?

I've tried all sorts of things, also with variations on -fx, like
SET Deblur=(convert -format "%%[fx:1-3290*%Deblur%/2873127]" info:)
, but in-line evaluation of e.g.

-define filter:blur=(1-3290*%Deblur%/2873127) -filter Lanczos

is what I'm looking for.

EDIT: I have got it calculating a result (the Blur parameter) on the command line console with the following code:

>SET Deblur=100

>SET Deblur=convert xc: -format '%[fx:1-3290*%Deblur%/2873127]' info:

>%deblur%
'0.885491'

But I'm probably doing something wrong (some silly Escape character requirement or such) to get it doing the right thing when the variable is used in the convert script section .... Also the precision is a bit low, but that is probably a -format issue that needs some work.

Maybe something like '%[option: ...]' will allow to directly set an expert option like -define , don't know yet.

Suggestions are (still) welcome.

Cheers,
Bart

[NicolasRobidoux]

Bart:
You are producing a string that contains the numerical value you want in decimal representation, which is not the same as a number.

-----

Question:
My understanding is that Fred Weinhaus, in his scripts, always has this kind of numerical preprocessing done by the shell (the scripting language), not by ImageMagick itself.
Are you able to have your scripting language do basic arithmetic and push the result over to IM?

-----

I'll post something on the Users Forum. This, really, is more of a scripting language question than an IM one, I think, but hopefully someone will know.

P.S http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=26006

[NicolasRobidoux]

Bart:
Unrelated suggestion (untested): I think that if you put the -delete 0 before the previous pair of parenthesis (so that it is just after the parenthesis in which there is the last reference to list image 0) you will reduce the memory footprint of the script, and probably make it faster. That is, use

...
-delete 0 ^
( -clone 2 -colorspace gray -auto-level ) ^
...

Make sure this does not change the results first. I'm making assumptions about IM list syntax and internals.
-----
I also think that a skilled IM command line programmer would know how to avoid to clone a second time and then deleting, but I don't know off the top of my head. Maybe just skip the last -clone 0 and then the -delete 0? Or the first one?

[NicolasRobidoux]

Bart:
See http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=26006#p113878. Please thank Alan Gibson (a.k.a. snibgo, so putting a link to im.snibgo.com would be nice, just like giving a link to Fred Weinhaus' scripts page) in your script's header. He's helped twice now (also helped with AdobeRGB).

[Bart_van_der_Wolf]

Bart:
You are producing a string that contains the numerical value you want in decimal representation, which is not the same as a number.

Yes, probably something like that won't work. I'm also exploring the option to set one's own global option, like:

-set option:mydeblur '%%[fx:1-3290*%Deblur%/2873127]'

after which one should be able to use it as

'%%[mydeblur]'

The double %% are supposed to be a Windows batch escaped single %.

Question:
My understanding is that Fred Weinhaus, in his scripts, always has this kind of numerical preprocessing done by the shell (the scripting language), not by ImageMagick itself.
Are you able to have your scripting language do basic arithmetic and push the result over to IM?

For some reason it doesn't work yet, which is strange because a batch variable like %deblur% is correctly parsed. So probably something to do with text versus numerical.

I'll post something on the Users Forum. This, really, is more of a scripting language question than an IM one, I think, but hopefully someone will know.

Maybe, but I do see code examples that do exactly what I'm trying, it only doesn't work in a batch script (assuming correct porting to windowese). For example this should correctly feed a calculation of a pixel value to a label (in unixese command line code):

convert rose:  -set option:mylabel '%[pixel:u.p{12,26}]' -delete 0 \
          label:'%[mylabel]'    label_fx_indirect.gif

P.S http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=26006

I'll be watching that as well. Thanks for thinking along, I really like the suggestion for a variable blur, so I'd like to get it working, either via script precalculation or (preferably) an in-line "Percent escape" convert calculation.

Cheers,
Bart

[Bart_van_der_Wolf]

Bart:
See http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=26006#p113878. Please thank Alan Gibson (a.k.a. snibgo, so putting a link to im.snibgo.com would be nice, just like giving a link to Fred Weinhaus' scripts page) in your script's header. He's helped twice now.

Nicolas (and Alan) thanks. That works like a charm!

EDIT: This issue was solved and corrected (by adding "-precision 16" without the quotes) in the re-updated Version 1.2.0.
The only concern I have is that the precision is limited to only a few significant digits. This is what an amount of 100 is parsed to when it is finally used in the convert command:

-define filter:blur=0.885491 -filter Lanczos

Maybe something inside the convert command will use a higher precision than what the batch precision allows ...


The current corrected code parses as:

-define filter:blur=0.88549061701764

as intended.

I've added Alan Gibson to the credits, and will upload the new script version (1.2.0) shortly (just need to do some more code clean-up, an have a coffee).

BTW. As you may have noticed, I've modified the formula to a shorter version (1-3290*%Deblur%/2873127) that should give exactly the same result. I just prefer 'Rational number' calculations to preserve precision in floating-point environments as long as possible and delay going into floating-point, because 'Real number' decimal fractions will internally not be exactly the same as typed (depends on machine precision). This also often allows to substantially shorten formulas.

Cheers,
Bart

[NicolasRobidoux]

...
BTW. As you may have noticed, I've modified the formula to a shorter version (1-3290*%Deblur%/2873127) that should give exactly the same result.
...

It's done in floating point whether you like it or not from the get go. (And, actually, this is a good thing, B/C 199/200 = 1 in integer arithmetic.)
Please use

1-0.0011450938298236*%Deblur%

Irrelevantly faster and probably more accurate. (I've not checked how the formulas are parsed by IM.)
P.S. Hair splitting apologies. Feel free to ignore.

[Bart_van_der_Wolf]

New version (1.2.0) attached.

Added was the possibility for users to also adjust the amount of sharpening when upsampling (currently based on EWA Lanczos filtered resampling and a Gaussian deblur). Negative amounts will blur the image, positive amounts will sharpen.

Changed was the blending gamma (was 2.0, now it's 3.0) for better reduction of dark edge undershoots.

Alan Gibson's name was added to the credits for code optimization. Thank you Alan!

Some minor tweaks to clean up the code were done as well, but there are more significant fundamental changes/improvements that have yet to be made to further improve the output quality even further. It's a work in progress!

Cheers,
Bart

P.S. With only 1 download, I've updated Version 1.2.0 without adding a new version number. The internal calculation of the Deblur value was increased to full 16-bit significant digit precision.

[NicolasRobidoux]

Bart:
Two quick comments, that may or may not be correct:
1) I think that the DoG parameter should be the same for both linear light and gamma light. The reason is that, roughly, we want the key "crossings" to match so that the heuristic that suggests picking one or the other based on luminance have a slightly stronger footing. I understand that in principle "crossings" depend on the colorspace. But not much, I think.
2) Maybe suggesting that normal sharpening is between 50 and 100 across the board is a good thing, since I suspect that the very best all purpose EWA Lanczos may actually be a bit softer than LanczosRadius, and a bit sharper than LanczosSharp.
P.S. Maybe this was a bit opaque. Basically, I want the halos produced in linear light and gamma to be aligned as much as possible so that the selection process implied by the luminance weighted blending does the right thing most of the time.

[fdisilvestro]

Hi,

Bart: Thank you very much for your effort.
I have started experimenting with it, just downloaded the last version (1.2.0)

Started with an png 16 bit file with embedded sRGB
Downsample, specifying x800; yes for optimized and 50 for sharpening

Results in two warnings:

1) "environmental variable deblurAmount not set"

I checked the script and it looks that it is missing an "=" in the finish part, so I added it and now it does not show the warning (apparently that variable is not used when selecting optimized down-sampling method

:finish
REM Clear environment variables
SET deblurAmount=

2) Even if the original file has sRGB embedded, I receive the following warning, which does not prevent the program to complete. The resulting file does not have a profile but opens correctly assigning sRGB in PS.

convert.exe: no color profile is available `C:\Users\Francisco\Pictures\Test res
ize\IMsource.icc' @ error/meta.c/WriteMETAImage/2326.
convert.exe: UnableToTransformColorspace `C:\Users\Francisco\Pictures\Test resiz
e\IMsource.icc' @ warning/profile.c/LCMSExceptionHandler/459.
convert.exe: ColorspaceColorProfileMismatch `icc' @ error/profile.c/ProfileImage
/578.

I don't know if I'm doing something wrong.

Regards

P.S. still too early for me to comment about the results, I need to play with it more.

Regards

[Bart_van_der_Wolf]

Bart:
Two quick comments, that may or may not be correct:
1) I think that the DoG parameter should be the same for both linear light and gamma light. The reason is that, roughly, we want the key "crossings" to match so that the heuristic that suggests picking one or the other based on luminance have a slightly stronger footing. I understand that in principle "crossings" depend on the colorspace. But not much, I think.

Nicolas, I d have to have a look at that. The reason that they are currently different is that while the gamma is still applied, the slope of an edge gradient has also changed, also in the mid-tonal region where the current blend will later cross when blending in linear light. That would suggest that also the detail that was spread over the neighboring pixels has a changed relative weight, and would require more/or less weight to deconvolve.

But I will review that again later anyway, because now that we have established a workable solution to employ user variable parameters, I might tweak the deconvolution radii to be a bit more adaptive for images that were resized to 50-100% of their original size.

It may also be interesting to be able and occasionally use the deconvolution for upsampling by selecting the down-sampling optimized filters with deconvolution. Currently the radius of the DoGs is fixed to a 7x7 support with a fixed High-pass filter radius that is used for deconvolution. That makes it under-dimensioned for enlargements, but boosting the amount can still produce interesting results I remember that the Jigsaw piece looked rather clean when I tried it a few versions ago, but the algorithms have change in the mean time so I'd have to do that again to see what it looks like now. With a more appropriate support and radius it would be more effective, but also slower. As far as I remember, the (de)blur function just mis-matches the number of lobes and produces less or more halo as a compensating mechanism, unlike properly dimensioned deconvolution (probably better done in the frequency domain, so IM7, due to the larger radii and kernel supports needed).

2) Maybe suggesting that normal sharpening is between 50 and 100 across the board is a good thing, since I suspect that the best EWA Lanczos may actually be a bit softer than LanczosRadius, and a bit sharper than LanczosSharp.

Done, will show up being changed in the next update. I just put 64 there as a memory jogger to signal the approximate correlation with one of the 'named' filters. There's no absolute need to keep that connection, it's more important how the output looks, whatever setting is needed for the particular image content.

Cheers,
Bart

[NicolasRobidoux]

Bart: See the P.S. to my last post.

[Bart_van_der_Wolf]

Hi,

Bart: Thank you very much for your effort.
I have started experimenting with it, just downloaded the last version (1.2.0)

Started with an png 16 bit file with embedded sRGB
Downsample, specifying x800; yes for optimized and 50 for sharpening

Results in two warnings:

1) "environmental variable deblurAmount not set"

I checked the script and it looks that it is missing an "=" in the finish part, so I added it and now it does not show the warning (apparently that variable is not used when selecting optimized down-sampling method

Hi Frank,

Thanks for the good bug analysis, there was indeed an '=' missing. Not that it really mattered (all resampling was already done at that point), it seems like these variables are being discarded from the environment anyway since the script is ending all processing at that point in time, but it was something I missed. I've just corrected that for the next update. I did want to leave that bit of housekeeping cleanup in place, as a reminder, and maybe for future subroutine calls.

2) Even if the original file has sRGB embedded, I receive the following warning, which does not prevent the program to complete. The resulting file does not have a profile but opens correctly assigning sRGB in PS.

I don't know if I'm doing something wrong.

I don't think it's something you/we can do a lot about, it has to do with how ImageMagick deals with assigning color Profiles to PNGs, which were originally without profile capability, or with an sRGB profile that's not standard. I could capture the attempt to reassign the original profile to the PNG (or assign an sRGB if none is present), but maybe I can use an available switch that triggers IM to just do as told. The warning is just that, a warning that something didn't go as instructed, and it only happens because I try to re-assign the original profile. Having to do it by hand is annoying though, so I'll review the details (I had a switch in one of the earlier versions, which I removed, that might do it).

Thanks for pointing these issues out, luckily minor ones, but they still went to the todo list.

P.S. still too early for me to comment about the results, I need to play with it more.

Please do. Likes as well as dislikes, they are all useful feedback. I haven't posted any direct comparisons with e.g. Lightroom or Photoshop myself yet, because the tool's output quality is still improving, but it might be nice do post an occasional interim comparison.

Cheers,
Bart

[NicolasRobidoux]

I believe that if you enlarge more than a little, EWA BC-splines lose to EWA Lanczoses (3-lobes by default) unless you really really don't want a second halo.
I would love to be proven wrong. (EWA with a soft Keys (c small) + deconvolution?)
P.S. I also believe that in general one is better off resampling with a suitably sharp filter so that one not have to sharpen much after that. But I would not be surprised if actually it is better to push things through a strongly anti-aliasing filter first, then restoring perceptual sharpness.

[Bart_van_der_Wolf]

I believe that if you enlarge more than a little, EWA BC-splines lose to EWA Lanczoses (3-lobes by default) unless you really really don't want a second halo.
I would love to be proven wrong. (EWA with a soft Keys (c small) + deconvolution?)
P.S. I also believe that in general one is better off resampling with a suitably sharp filter so that one not have to sharpen much after that. But I would be surprised if actually it is better to push things through a strongly anti-aliasing filter first, then restoring perceptual sharpness.

I do not have all the answers either. I do know that sharpening will usually also sharpen or (with deconvolution) even restore artifacts if enough evidence is left, so having few artifacts does help either way. However, there are other ways of dealing with artifacts like over/under-shoots than blurring or filtering.

That's why I was investigating blending of Clipping prevention layer differences. That would allow to use a relatively sharp filter, but adaptively dampen the halos especially those that come close to the clipping boundaries when a further contrast boost is not really needed.

These kind folks also use (amongst other choices) Lanczos 3 based resampling, but with interpolation clamping.

Cheers,
Bart

[NicolasRobidoux]

Opinion: Although a number of people have had a somewhat successful time using limiters to minimize undershoots and overshoots (including me with the NoHalo interpolation method), I believe that it is extremely difficult to put together a strong enough limiter that does not introduce aliasing.
I have little interest in following this direction at this point.

[NicolasRobidoux]

Bart:
Opinion: Sooner or later there will be a need for versions that take in Adobe RGB and deal with it correctly (one that keeps things in Adobe RGB, others that convert to sRGB), and versions that produce 8 bit RGB (or Adobe RGB), it this tool is truly meant for "web publication".

[Bart_van_der_Wolf]

Bart:
Opinion: Sooner or later there will be a need for versions that take in Adobe RGB and deal with it correctly (one that keeps things in Adobe RGB, others that convert to sRGB), and versions that produce 8 bit RGB (or Adobe RGB), it this tool is truly meant for "web publication".

Fully agree, although I have yet to test how much improvement this will make compared to a 'round-trip' in 'assumed sRGB', where the original profile is reassigned to the image afterwards. After all, we are creating loads of totally new pixels, but they are (mostly, with some damage control) interpolated, and should stay close to the original real data. But you are correct that a fully color-managed (assuming there is an embedded profile in the image ) processing is preferred.

It is high on my ToDo list. Currently I'm not too happy with how PNG embedded profiles are treated by IM, JPG/JPEG seems okay, as is TIFF although they may still generate TAG warnings (probably to do with the version of the LIBTIFF library). I saw that Alan Gibson (snigbo) also has color management on his long ToDo list, perhaps because it's not all that simple to do (or just less urgent for him), given all possible situations one can encounter.

In photographic everyday practice we can be confronted with all sorts of profiles, such as device independent profiles (e.g. sRGB, ProPhoto RGB, Beta RGB), and device dependent profiles (output modality profiles, e.g. display, printer/paper), and even missing or incorrect profiles. And different operating systems may store the installed versions at different locations, as do some applications in yet other locations.

Currently, I save the originally embedded profile (if embedded) and reassign it afterwards, but some user interaction would be nice, as would the optional conversion to a different profile be. It will create a much larger script file though, due to the various scenarios one may need to tackle, but we/I could start with the basics.

Cheers,
Bart

[Bart_van_der_Wolf]

I have attached an updated version (1.2.1) .

Some code cleanup was done. The user prompts were somewhat re-worded, in an attempt to better reflect the fact that both types (Up/Down) of resampling are optimized with user adjustable sharpening. I also tried to suppress some non-fatal warning messages that IM would generate, but which have not influence on the result. Also the User defaults are identified a little better (I hope) in most prompts.

The more important addition is the option to use user definable deconvolution for all methods. When the user defines a sharpening amount of '0' or less (which essentially blurs the image), the option to add deconvolution sharpening is automatically presented after the resampled result is produced and saved. This allows to grab a copy of the file before additional sharpening, while the script waits for user input.

I'm trying to improve the human interface as to which values one should enter for the 'best' results (perhaps by supplying calculated defaults), but for the moment one could start with the resampling factor as radius, and 50 or more for the amount. So a 3x (300%) upsampled image would probably best use a Blur radius input of 3 (will be converted to the actual DoG value to use). When boosting the amount above 50, some halo may become visible (which would not necessarily hurt the image if printed), so then a smaller radius would also reduce that while still attempting to sharpen. Larger amounts than 50 are probably needed for very large upsampling anyway, and it's subject matter dependent, so some experimentation is in order. For downsampling a radius setting of 1 to 2  gives good results, and the amount will control the level of crunchiness.

Cheers,
Bart