On Tue, 2008-07-15 at 00:32 +0200, Sven Neumann wrote:

Since no one has offered to help with this bug so far, I see two options:

(1) postpone this change for 2.8 (2) commit the changes and release them with 2.5.2, revert if needed

I can certainly offer images, I'm maxed out with work & meetings & stuff this month though, so apart from that I don't have spare cycles probably until the end of the month. Sorry for not replying first time round.

Liam

I can do at least half of this task, possibly most of it.

* decide on test images: 2 landscapes
http://www.flickr.com/photos/hapal/2292885459/sizes/l/ http://www.flickr.com/photos/15082599@N08/2432037855/sizes/l/ (or size o/ ) 3 portraits
http://www.flickr.com/photos/aturkus/2091469097/sizes/l/ http://www.flickr.com/photos/manicomi/2472143804/sizes/l/ http://flickr.com/photos/newroz2005/9392539/sizes/o/in/pool-88292168@N00/ 1 cartoon
http://www.flickr.com/photos/stephendl/2536595458/sizes/o/ 1 pixel art
http://www.pixeljoint.com/pixelart/5647.htm#

* decide on tests: Scale down, single step:
50% 33% 12.5%
Scale up, single step:
133% 150% 200% 400%
Scale down, multiple steps
(to 66% x 3), (to 50% x 3)
Scale up, multiple steps
(to 133% x 3), (to 150% x 3)

* Save results of tests before applying patch * (probably) Save results of tests after applying patch * Make webpage

The one thing I definitely can't do is * Host webpage.

Hi,
I've just completed producing images without the patch (using old scaling code) for None and Linear methods. This amounts to 2*77 = 154 images totalling 110 MB. Some of these I plan to discard, for the cases where the old and new code produce the same result.

One of the photos had transparency information added to it, another which was already grey I converted to greyscale.

Remaining: * produce 77 images each for Cubic and Lanczos * (possibly) produce 77 images each for None, Linear, Cubic, and Lanczos using the patch
* (possibly) check whether scaling in Indexed modefor the pixel art produces identical results to None using RGB mode * (possibly) make webpage.

On Wed, Jul 16, 2008 at 6:30 PM, David Gowers wrote:

I can do at least half of this task, possibly most of it.

* decide on test images: 2 landscapes
http://www.flickr.com/photos/hapal/2292885459/sizes/l/ http://www.flickr.com/photos/15082599@N08/2432037855/sizes/l/ (or size o/ ) 3 portraits
http://www.flickr.com/photos/aturkus/2091469097/sizes/l/ http://www.flickr.com/photos/manicomi/2472143804/sizes/l/ http://flickr.com/photos/newroz2005/9392539/sizes/o/in/pool-88292168@N00/ 1 cartoon
http://www.flickr.com/photos/stephendl/2536595458/sizes/o/ 1 pixel art
http://www.pixeljoint.com/pixelart/5647.htm#

* decide on tests: Scale down, single step:
50% 33% 12.5%
Scale up, single step:
133% 150% 200% 400%
Scale down, multiple steps
(to 66% x 3), (to 50% x 3)
Scale up, multiple steps
(to 133% x 3), (to 150% x 3)

* Save results of tests before applying patch * (probably) Save results of tests after applying patch * Make webpage

The one thing I definitely can't do is * Host webpage.

I might be able to make a PDF.I suspect the smallest it could possibly get is 20mb.

On Wed, 2008-07-16 at 22:14 +0930, David Gowers wrote:

The one thing I definitely can't do is * Host webpage.

I can do that if you want, although gimp.org would be better. As long as it's under a gigabyte or so.

Here are some images that may help show some problems -- colour photos tend to hide problems, partly because the eye sees the subject more easily and auto-corrects flaws, and partly because the hardest thing for rescaling is often preserving both texture and sharpness. Of course, most people are working with colour photos these days...)

For potential problems with vertical artifacts, see the 1600x1200 image at
http://www.fromoldbooks.org/Green-ShortHistory/pages/0187-Remains-of-Cloisters/ (I had to resize it to 1024x768 using cubic and then sharpen)

The 1518x916 one at http://www.fromoldbooks.org/YouthsInstructer/pages/072-New-Post-Office-London/ has near-horizontal lines which are difficult.

http://www.fromoldbooks.org/YouthsInstructer/pages/181-Dunluce-Castle/181-Dunluce-Castle-q59-1447x923.jpg has diagonals and is an RGB image instead of grayscale.

http://www.fromoldbooks.org/ThomasBewick-WoodEngravings/pages/30-the-horse/1790x1307-q75.html is a fairly clean woodcut.

I have some much larger images too if you want them.

Liam

On Wed, 16 Jul 2008 17:15:38 +0200, Liam R E Quin wrote:

On Wed, 2008-07-16 at 22:14 +0930, David Gowers wrote:

The one thing I definitely can't do is * Host webpage.

I can do that if you want, although gimp.org would be better. As long as it's under a gigabyte or so.

Here are some images that may help show some problems -- colour photos tend to hide problems, partly because the eye sees the subject more easily and auto-corrects flaws, and partly because the hardest thing for rescaling is often preserving both texture and sharpness. Of course, most people are working with colour photos these days...)

I posted some good test images when I was working on the lanczos part of this code and the rotation distortions. Concentric circles and the like. These geometric patterns make any defect instantly visible whereas it may not be obvious in one operation on a photo-like image.

care should be taken not to assume the criteria is one or two simple ops on photos. Gimp vision specifies graphics as well as photos so defects in geometric shapes are highly relevant.

I also posted a woodpecker photo that had a near horizontal beak section. I found this was a very sensitive test for staircasing defects that may be relevant here.

Search bugs for lanczos or rotation to find these bug reports containing attachments.

regards.

For potential problems with vertical artifacts, see the 1600x1200 image at
http://www.fromoldbooks.org/Green-ShortHistory/pages/0187-Remains-of-Cloisters/ (I had to resize it to 1024x768 using cubic and then sharpen)

The 1518x916 one at http://www.fromoldbooks.org/YouthsInstructer/pages/072-New-Post-Office-London/ has near-horizontal lines which are difficult.

http://www.fromoldbooks.org/YouthsInstructer/pages/181-Dunluce-Castle/181-Dunluce-Castle-q59-1447x923.jpg has diagonals and is an RGB image instead of grayscale.

http://www.fromoldbooks.org/ThomasBewick-WoodEngravings/pages/30-the-horse/1790x1307-q75.html is a fairly clean woodcut.

I have some much larger images too if you want them.

Liam

Here are some images that may help show some problems -- colour photos tend to hide problems, partly because the eye sees the subject more easily and auto-corrects flaws, and partly because the hardest thing for rescaling is often preserving both texture and sharpness. Of course, most people are working with colour photos these days...)

Personally I think the test is being run under flawed conditions (using nonlinear sRGB rather than linear RGB, which produces errors of up to 50% because interpolation is done linearly despite the colorspace being nonlinear.). However, those are the conditions the user is predominantly working under. I'm considering doing a separate test run where I first convert to linear RGB and finally convert back to sRGB.

For potential problems with vertical artifacts, see the 1600x1200 image at
http://www.fromoldbooks.org/Green-ShortHistory/pages/0187-Remains-of-Cloisters/ (I had to resize it to 1024x768 using cubic and then sharpen)

The 1518x916 one at http://www.fromoldbooks.org/YouthsInstructer/pages/072-New-Post-Office-London/ has near-horizontal lines which are difficult.

http://www.fromoldbooks.org/YouthsInstructer/pages/181-Dunluce-Castle/181-Dunluce-Castle-q59-1447x923.jpg has diagonals and is an RGB image instead of grayscale.

http://www.fromoldbooks.org/ThomasBewick-WoodEngravings/pages/30-the-horse/1790x1307-q75.html is a fairly clean woodcut.

All these seem good, so I've included them. I'm currently searching for Geert's images.

Please consider adding typographic elements (logos, text) and icons/diagrams to the test images.
One of the most critic use cases where downscaling shows issues is with high contrast such as dark typography on light backgrounds. This is particularly important when working with small designs for the web (banners, for instance, which end up too blurry).

Hi,

On Thu, Jul 17, 2008 at 7:35 AM, Sven Neumann wrote:

Hi,

On Thu, 2008-07-17 at 09:19 +0930, David Gowers wrote:

Personally I think the test is being run under flawed conditions (using nonlinear sRGB rather than linear RGB, which produces errors of up to 50% because interpolation is done linearly despite the colorspace being nonlinear.). However, those are the conditions the user is predominantly working under. I'm considering doing a separate test run where I first convert to linear RGB and finally convert back to sRGB.

Please don't overdo it. All we need to know at this point is that the patch is an improvement. It doesn't have to solve all problems, it just needs to provide a somewhat better result than the old code.

Processing in linear space will happen automatically as soon as we switch all processing to GEGL. We are not going to make the legacy code even more complex than it already is. So please don't waste your time on this.

That's unrelated. I simply meant that I currently work in linear space anyway, and what I meant involves no code changes, just converting between color profiles during testing to ensure more accurate interpolation. (my point also was that it's hard to tell if it's doing something better, when the distorted interpolation presents significant artefacts obscuring it). Anyway -- okay, I won't do that.

David

On Thu, Jul 17, 2008 at 2:32 PM, Guillermo Espertino wrote:

Please consider adding typographic elements (logos, text) and icons/diagrams to the test images.
One of the most critic use cases where downscaling shows issues is with high contrast such as dark typography on light backgrounds. This is particularly important when working with small designs for the web (banners, for instance, which end up too blurry).

I believe that most blurring problems originate from incorrect gamma treatment .. the interpolation done during scaling and other operations is only accurate if done in linear RGB colorspace, whereas predominantly people use the sRGB colorspace which is nonlinear (up to 50% error can occur from interpolating sRGB values as if they were linear.). Working in "CIE 1931 D65 Gamma 1.0" colorspace and eventually converting to 'nativePC" profile to produce the final picture might well improve your results. It has made my results smoother and crisper.

(the profiles mentioned above are available from: http://www.aim-dtp.net/aim/techniques/linear_raw/index.htm)

That said, if you provide a suitable typographical test image, I will include it.
( I see no issue that a diagrammatic test image would show up that wouldn't already appear on either Liam's complex engravings or a typographical test image. So unless you demonstrate that, I will not include a diagrammatic test image)

David

Hello. I've just completed the first half of the set (all specified results before the patch). Currently image files total 66mb, I'm guessing after adding the results after-patch this will come up to ~110mb. During this testing I found one obvious bug, it remains to be seen whether the patch fixes it.
Anyway, FYI i'm attaching the bad result, which happens when scaling the kingfisher test image down to 33.33% using Lanczos scaling.

I ended up eliminating most of the upscaling results, because the amount of space used was excessive (600mb might have been the total instead, before adding the after-patch results, had I not done this!) Now the list of scales includes only:

50% 33.33% 12.5% 133% 3*66.66% 3*50%

I intend to try the patch tomorrow.

David

David Gowers wrote:

Hello. I've just completed the first half of the set (all specified results before the patch). Currently image files total 66mb, I'm guessing after adding the results after-patch this will come up to ~110mb. During this testing I found one obvious bug, it remains to be seen whether the patch fixes it.
Anyway, FYI i'm attaching the bad result, which happens when scaling the kingfisher test image down to 33.33% using Lanczos scaling.

I ended up eliminating most of the upscaling results, because the amount of space used was excessive (600mb might have been the total instead, before adding the after-patch results, had I not done this!) Now the list of scales includes only:

50% 33.33% 12.5% 133% 3*66.66% 3*50%

I intend to try the patch tomorrow.

David

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

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

Hi,
On Sat, Jul 26, 2008 at 7:08 PM, Geert Jordaens wrote:

David Gowers wrote:

Hello. I've just completed the first half of the set (all specified results before the patch). Currently image files total 66mb, I'm guessing after adding the results after-patch this will come up to ~110mb. During this testing I found one obvious bug, it remains to be seen whether the patch fixes it.
Anyway, FYI i'm attaching the bad result, which happens when scaling the kingfisher test image down to 33.33% using Lanczos scaling.

I ended up eliminating most of the upscaling results, because the amount of space used was excessive (600mb might have been the total instead, before adding the after-patch results, had I not done this!) Now the list of scales includes only:

50% 33.33% 12.5% 133.33% 3*66.66% 3*50%

I intend to try the patch tomorrow.

David

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

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

The webpages are nearly finished, I'm checking them now.

Some observations on the results of scaling:

* The old code mistreated the left and top edges, resulting in a duplication of up to 1 pixel on the left and top edge (and corresponding omittal of a row of pixels on the right and bottom edge). This looked slightly odd for upscaling, and very odd for downscaling. The new code gives results that are more predictable and more correct.

* There is still a bug present in the new lanczos code which you can easily see on the horse test image- the top row and left column of pixels acquire junk pixels (there was only pure white in the source image near there) . An example of the bug is attached. I hope this helps isolate the cause of the bug.
(this bug is not present in the old code)

David

Hi,

On Wed, Jul 30, 2008 at 10:23 PM, David Gowers wrote:

The webpages are nearly finished, I'm checking them now.

Some observations on the results of scaling:

* The old code mistreated the left and top edges, resulting in a duplication of up to 1 pixel on the left and top edge (and corresponding omittal of a row of pixels on the right and bottom edge). This looked slightly odd for upscaling, and very odd for downscaling. The new code gives results that are more predictable and more correct.

* There is still a bug present in the new lanczos code which you can easily see on the horse test image- the top row and left column of pixels acquire junk pixels (there was only pure white in the source image near there) . An example of the bug is attached. I hope this helps isolate the cause of the bug.
(this bug is not present in the old code)

OOPS! In fact, this bug is a reduced version of the same 'top+left edges stretched' bug in the old code.

I've finished checking, and am just sending off the results and webpage to Sven now.

David

Hi solar,

On Fri, Aug 1, 2008 at 6:58 AM, wrote:

On Wed, 30 Jul 2008 15:53:36 +0200, David Gowers wrote:

I've finished checking, and am just sending off the results and webpage to Sven now.
David

Thanks for all the hard work on this. A very interesting comparison. (Perhaps too many engraving type images tho').

My main interest was in lanczos results since I spent some time on this (initially intending to use it as a pixelisation filter rather than interpolation method).

One of the most interesting differences between cubic (csplines) and lanczos3 is shown here:
http://svenfoo.org/scaletest/33-9.html

the cubic scaling shows some exagerated contrasts especially on the top of the head. Almost like it has some party glitter sprinkled on it. In this example the linear may even, atypically, be preferable to cubic.

This artifact is probably a good example of the tendancy of csplines to overshoot near sharp changes. The orange part of the throat is also softer and more natural than the cubic which show fairly obvious pixelisation there.

Aside that, many of the samples show little discernable difference though the predominance of etched images , which are basically binary in tone, would not demonstate the overshoot phenomenon.

Maybe a couple of tests with block style graphics would be a useful addition. Simple graphics with areas of uniform colour.

I included a pixel art (image #8) for this purpose. I agree it's not simple -- it only has areas of uniform color. the original is found here:
http://www.pixeljoint.com/pixelart/5647.htm#; each of the two sprites have about 22 colors each; the borders are flat and comprise an additional 2 colors. The picture was by me, and I felt that lanczos performed outstandingly for downscaling -- and in general, all scaling methods did a better job of preserving the salient features of the image than the old code. Pixel art ('block graphics'?) is a pathological case for most scaling algorithyms, and no algorithym old or new performed very well on upscaling image #8.

David

On Wed, 2008-07-30 at 23:54 +0200, Sven Neumann wrote:

I've put your results online at http://svenfoo.org/scaletest/

I've tried the patch out a little.

So far it feels noticeably slower on mediumsized or large images (e.g. a 13899x8497-pixel 2400dpi grayscale scan, which Gimp reports as 230MBytes) but the results are outstandingly better.

Liam

On Fri, 01 Aug 2008 13:51:02 +0200, David Gowers wrote:

Pixel art ('block graphics'?) is a pathological case for most scaling algorithyms, and no algorithym old or new performed very well on upscaling image #8. David

yes, this is a good test for scaling alorithms. I had not really apreciated the nature of this image since, although pixel art, it does have predominantly degraded edges so it is not quite the sort of block graphic I was refering to. However, picking out some specific areas, it does give some good information on the merits of different algorithms for this kind of image.

Viewing the comparitive for 133% at 200% (in Opera) there is a noticable difference between cubic and lanczos. http://svenfoo.org/scaletest/133Z8g.png http://svenfoo.org/scaletest/133C8g.png

opening these two in adjacent tabs in opera and flipping allows direct comparison. This difference is quite marked.

Comparing directly to the original at 266% with scaled image at 200% there is an impressive restoration of detail lost to pixelisation in the orginal.

The eyebrow, hair and eye are well enhanced as it the hand on the blue figure. The staircasing on the knee and thigh of the yellow figure are also well smoothed out, though not removed completely.

All parts of this image seem to have been noticably enhanced , I think it's a good demonstration of the lanczos code.

Although downscaling is probably the more critical test (and the case that was needing most improvement) it may be informative to add another enlargement to some oddball ratio (say 3.14159) to see how the detail comes out when the result is several times bigger.

BTW , has this code been ported to the rotation operation? IIRC, that was a separte file that closely duplicated the scaling code. Maybe this would be a good point to unify the two.

In any case I'm very pleased to see the lanczos results on this image. Very impressive.

regards.