Hello Nicolas,

On Thu, Aug 21, 2008 at 11:18 AM, Nicolas Robidoux wrote:

http://web.cs.laurentian.ca/robidoux/misc/

contains an add-on (the gzipped tar gimptests.tgz) to the "kingfisher" test

http://svenfoo.org/scaletest/133-9.html

and the "shefoxes" test

http://svenfoo.org/scaletest/133-8.html.

Here is a copy of the README file which is found at the top level of the tar file:

---------------------------------------------------------------------------

This is an add-on to

http://svenfoo.org/scaletest/133-9.html?

and

http://svenfoo.org/scaletest/133-8.html?

from which the t*.png and 133*.png pictures were taken.

-----

Four proposed plug-ins are included.

EANBQH.c (Exact Area Natural Biquadratic Histosplines)

EANBQHgamma.c (same with gamma correction)

IBFNBQH.c (Interpolatory Box Filtered Natural BiQuadratic Histosplines)

IBFNBQHgamma.c (same with gamma correction)

Install with the usual

gimptool -install EANBQH.c

The plug-ins install themselves in the "Image" menu of the image window. The plug-ins can also be used in batch mode (passing arguments at the command line instead of using the GUI).

These plug-ins have been extensively tested but nonetheless these are PRELIMINARY VERSIONS: The plug-ins are currently being substantially rewritten for speed. (Our C programming skills have improved since these plug-ins were originally written...)

Note that these plug-ins are already fast: on a current intel laptop, they enlarge very large images a little faster than the built-in gimp bicubic.

I would be delighted to see one or more of the four integrated into the GIMP core.

-----

I suggested that it may be easier to integrate one of the above into the gimp than fixing some (still?) present problems found in the gimp lanczos code.

The "gamma" versions have to do with the following suggested added feature: Most linear (convolution-like) image operations should ideally be performed on images with gamma=1 (linear mode). However, most images are gamma corrected (gamma is usually not 1).

My suggested feature is as follows: When performing such an operation the user has an option to specifying the gamma value of the "input" (to be resized) image, as well as the gamma correction of the "output" image. If this feature was to be fully implemented, an additional pair of chained (by default) windows for the input and output gammas would be added to the GUI.

I suggest this is unnecessary; Using LittleCMS and/or GEGL, scalers can obtain linear data from the input data, provided its color profile is correctly set, and then transform this linear data back to the original colorspace when writing the result. If a profile isn't attached, it's reasonable to assume sRGB . I notice the 'Gamma' versions of these enlargers introduce haloing around some edges, while the non-gamma versions do not (or it's too little to see). A naive conversion may be the cause of this difference. If you could utilize the profile attached to the image, and generate or load a linear one, you could use LittleCMS to do the conversion in an assuredly correct way.

EANBQHgamma.c and IBFNBQHgamma.c (in the current preliminary versions) perform the resizing as if the input image is known to have a gamma=2.2 (gamma value which approximates sRGB) and the output image is to have the same gamma correction. Note that I suspect that this gamma value of 2.2 is incorrect for at least one of the two test images.

Converting from the attached sRGB ICC profile to the attached linear RGB profile produces results which are correct, IMO (for both of the LCD displays I've tried it on). Perhaps this will help.

-----

WARNING:

The "IBF" plug-ins use the "corner" image size convention, the "EA" plug-ins use the "center" image size convention (the same as the gimp's image resize as currently configured, as well as imagemagick's, for example). I could, however, produce versions of "IBF" which uses the "center" convention, and versions of "EA" which uses the corner convention. The current conventions are the most natural for each method.

-----

Personal opinion:

Besides the difference in image size convention (which, as I mentioned, can be changed) the "IBF" methods produces images which are slightly smoother than the "EA" ones, without noticeably worse blurring, and with slightly less haloing and aliasing. In my opinion, the "EA" methods probably should not be used with very noisy images, and one could argue that the "IBF" methods are better across the board, with the possible exception of images which are text-like.

-----

How the new images were produced:

After installing the plug-ins, the t8.png and t9.png images were loaded into the gimp.

t9.png was enlarged to 369x247 and right cropped to 320x247 (to mimic the cropping of the scaletest images).

t8.png was converted to RGB mode (the original is indexed) and enlarged to I did not take the time to figure out exactly how these were cropped, so I did not crop my enlargements.

For each scaling factor for each picture, my script randomly picked a

-----

Comments welcome.

IBFNBQH (not gamma version) produces the cleanest-looking result on my display.

I installed and tried the plug-ins. IBFNBQH definitely produces nicer results than Lanczos

AFAIK we already have 'too many' scaling types to be very usable, so it's more likely that one of your methods could replace lanczos.

Lastly, scaling is eventually not even going to be the responsibility of GIMP; GEGL currently implements most of the scaling types GIMP does, and will eventually be used to perform all transformations. So it you might be better off implementing your scalers for GEGL instead.