Bug: resize treats non-black 0 % opaque pixels wrong

[krilbe]

Hi,

I've noticed that when I export a PNG from CorelDRAW X5, "empty" areas are exported with RGBO = (255, 255, 255, 0), i.e. 0 % opaque white. It seems a bit unorthodox - I assume the common way to store "empty" pixels in a PNG is RGBO = (0, 0, 0, 0), i.e. 0 % opaque black.

But I also assume that the PNG specification says nothing about the RGB value for 0 % opaque pixels, so the PNG from CorelDRAW should be handled correctly by PaintShop Pro. Unfortunately this is not the case.

If I open the PNG from CorelDRAW in PaintShop Pro X7 and resize it (using Bicubic), it weighs in the "whiteness" of the 0 % opaque pixels, when it calculates the RGB values for the new resized edge pixels. This results in a halo around the edges, that clearly should not be there.

This is very easy to test. A similar image with RGBO = (0, 0, 0, 0) for the 0 % opaque pixels do not cause any halo.

I would expect Corel to fix this bug in the next release/service pack for PaintShop Pro, and preferably also change the PNG export in CorelDRAW to make empty areas use RGBO = (0, 0, 0, 0).

Note: I fear that the resize bug is actually worse than I describe here, but have not tested it. When calculating a new RGB value during resize, a old pixel with < 100 % opacity should have its RGB value weighted by the opacity during the calculation. If this were the case, the RGB value of pixels with opacity = 0 would not make any difference. But what about an edge between 100 opaque blue and 50 % opaque red? A new pixel that covers 50 % red and 50 % blue of the old image should have RGB = (128, 0, 255, 192), right? I fear that PSP will instead produce RGBO = (255, 0, 255, 192), forgetting that the R component should be weighted with the 50 % opacity. Anyone care to do the test?

[hartpaul]

Not sure that this bug will surface with PSP only users.
But, have you tried loading your image with the wrong transparency data into PSP, adding another transparent layer beneath it and then doing a merge down. This should retain transparency and hopefully convert the transparent areas to (0,0,0,0).

[krilbe]

OK, I did a simple test. Here are the steps:

1. New image 100x100 px, raster bg, RGB 8 bit, transparent.
2. Brush square, size 50, hardness 100, density 100, thickness, 100, rotation 0, opacity 50, foreground color RGB = (255, 0, 0).
3. Using that brush, paint the left half of the image 50 % opaque red.
4. Change opacity to 100 and fg color to RGB = (0, 0, 255).
5. Using that brush, paint the right half of the image 100 % opaque blue.
6. Resize image to 3x3 px using bicubic and sharpness = 0.
7. Inspect the middle column of pixels. It has RGBO = (188, 0, 188, 191).
8. Try the same in GIMP. The middle column of pixels have RGBO = (92, 0, 163, 187).

GIMP is the one that produces the more correct result. The 100 % opaque blue is weighted in the calculation causing the edge pixel to be more blue than red, as it should. PSP on the other hand produces an edge pixel that has equal amounts of red and blue.

To emphasize the error, try using 1 % opacity for the red. In this case PSP produces edge pixels with RGBO = (188, 0, 188, 129) while GIMP produces RGBO = (2, 0, 253, 121). PSP now is very obviously wrong. Before resize the redness is hardly visible anywhere, but after the resize, the edge pixels are clearly lilac (50 % red and 50 % blue). This would be the equivalent of a red halo around the blue area, if you think of this as a blue area on a red but almost transparent background. GIMP produces a correct result, where the edge pixels are almost only blue, and no red halo effect can be seen.

Now, please Corel, will you fix this in PSP?

[krilbe]

Not sure that this bug will surface with PSP only users.
But, have you tried loading your image with the wrong transparency data into PSP, adding another transparent layer beneath it and then doing a merge down. This should retain transparency and hopefully convert the transparent areas to (0,0,0,0).

Please see my other comment posted just now. It is a simple and clear demonstration of the resize bug using ONLY PSP.

[krilbe]

As another clear example, repeat the same steps as above, but place the 1 % red on the entire image (i.e. cover the entire image with 1 % opaque red), then place a single 50 px 100 % opaque blue square in the middle of the image. No red can be seen since the 1 % opacity of the red background makes the red color almost invisible. Right?

Now, resize to e.g. 25x25 px. Suddenly there's a distinct red halo around the blue square.

THIS IS BAD FOLKS!

[LeviFiction]

I got some interesting numbers here

I tried it in four different programs, Photoshop, PSP, GIMP, and Paint.net

Paint.net - 80,0,174,194
Photoshop CS5 - 134, 0,121, 187
GIMP - 67,0,188,202
PSP - 176,0,204,207

Photoshop and PSP are actually pretty close in the sense that red and blue are intermixed almost evenly.

[krilbe]

Paint.net - 80,0,174,194
Photoshop CS5 - 134, 0,121, 187
GIMP - 67,0,188,202
PSP - 176,0,204,207

Photoshop and PSP are actually pretty close in the sense that red and blue are intermixed almost evenly.

You seem to get figures that differ from the ones I got. Did you really follow the steps exactly?

Anyway, which of the resulting images does best resemble the one you had before the resize? That's what actually count's, isn't it?

I know Photoshop is considered THE image editor out there, but that doesn't really mean it does the best job in every aspect.

The current PSP algorithm cannot be aceptable. It's easy to create examples that produce really weird results. For example, create an image that is 100x100 px and contains vertical stripes, 3 px wide each, where every other stripe is RGB = (255, 0, 0, 2) and the others are RGB = (0, 0, 255, 255). This image is almost all blue and just a little red. Now resize it to 25x25 px in PSP using bicubic and sharpness = 0. The resulting image is... magenta! This cannot be okay, can it? RGB of the resulting image vary slightly, but average somewhere around RGB = (185, 0, 185, 128). The resulting image should of course be almost all blue.

[LeviFiction]

Anyway, I posted the wrong set of numbers. Those were from my original experiment. And the differences come from being incapable of drawing straight lines. I used selections to create the image that I used for my next experiments. And I used the exact same PNG in each software. I just wasn't paying attention when I copied them over.

Photoshop - 128,0,128,72 and 81
Gimp - 92,0,163,187
Paint.net - 88,0,165,188
PaintShop Pro - 188,0,188,191

Photoshop created more of a matrix resulting in two of the pixels being more transparent than the middle one.

[krilbe]

From those figures I'd say that Adobe has made the same mistake with Photoshop as Corel has with PaintShop Pro.

I'll give you some clear examples of why this is wrong.

1. Stripes that change color. This is the striped image that I described earlier. The blue stripes are 100 % opaque. The other stripes are actually 100 % red but 1 % opaque, RGB = (255, 0, 0, 2).

The original striped image.

Stripes.png (469 Bytes) Viewed 7313 times

Downsizing this image should result in an image that's mostly blue and about 50 % opaque, because the original image has a lot of blue in it, but only a small fraction of red. Anyone disagree?
Downsizing to 10x10 px, here's what PSP produces:

The striped image downsized using PSP.

StripesDownsizedPSP.png (205 Bytes) Viewed 7313 times

And here's what GIMP produces:

The striped image downsized using GIMP.

StripesDownsizedGIMP.png (190 Bytes) Viewed 7313 times

It's pretty obvious that GIMP produces an image that looks a lot like the original, but PSP does not.

The same effect can actually be seen in PSP by simply zooming out on the original striped image, so the zoom feature has the same bug as the resize. The more you zoom out, the more magenta it looks. How can anyone argue that this is correct?

Next example in the next post...

[krilbe]

Next example:

2. Red halo around blue square. This is the square example I described earlier. The background is RGBO = (255, 0, 0, 2) and the square is RGBO = (0, 0, 255, 255).

The original square image.

Square.png (428 Bytes) Viewed 7312 times

Resizing it should still look like a blue square on an almost transparent red background. Anyone disagree?

This time I tried upsizing it instead. Here's what PSP produces:

Square upsized with PSP.

SquareUpsizedPSP.png (864 Bytes) Viewed 7312 times

And here's what GIMP produces:

Square upsized with GIMP.

SquareUpsizedGIMP.png (638 Bytes) Viewed 7312 times

PSP produces a very conspicuous red halo around the blue square. How can anyone argue that this is correct?

[krilbe]

Another experiment, now upsizing the striped image.

The original striped image.

Stripes.png (469 Bytes) Viewed 7312 times

Upsized using PSP.

StripesUpsizedPSP.png (1.18 KiB) Viewed 7312 times

Upsized using GIMP.

StripesUpsizedGIMP.png (444 Bytes) Viewed 7312 times

PSP produces an image that has so much red in it that the stripes are more magenta than blue. Not a great similarity to the original, is it? But GIMP's image looks very much like the original.

How can anyone argue that PSP does it right or does a better job than GIMP?

[krilbe]

With these examples in mind, I'd like to hear some arguments in favor of PSP. I sure can't find any.

Please don't come dragging with Photoshop. I don't care about Photoshop. It dominates the market, yes, but that doesn't mean it's free from bugs or some kind of definition of what's right.

If you're still not convinced that PSP's resize is buggy, or at least not very good, what evidence would it take to convince you? What is your reasoning behind your standpoint?

This bad resize feature is not a corner case. It affects every single resize operation on an image that has different levels of opacity in different pixels.

Frankly, I can't understand why it's so darn difficult to get anyone to see that PSP doesn't do this right.

[hartpaul]

This has gone of for some time with this "bug"
You have found a limitation.
Plenty of programs and tools have limitations if you look for them.
eg PSP yopu can't resize to 200000 by 200000 pixels/
That is a bug???... a limitation.
Learn to avoid those limitations. Don't resize an image if it has partial transparency. Get the size right first before you introduce partial transparency.
It is not a " bug" that many would find important , least of all Corel so I seriously doubt that they will spend lots of time searching for a solution if Photoshop with all its money and developers cannot solve the same problem.
Or are you saying we should all drop PSP and go over to Gimp because we cannot resize with a partial transparency.
If you find a "bug" that affects a good percentage of users then yes that may be attended to.

In another thread some people are finding a problem with PSP and Vista, which would probably be higher up the queue for things to do than this problem.
I use windows XP and if eventually PSP Xn does not work with that then I will have to accept that as a future limitation and only use earlier versions.

By the way using PSP8 I tested your blue square on a 1% red transparent background and a halo does not occur there. I zoomed in to 5000% and using a 1 pixel brush marked in alternate different colours a line 10 pixels in and 10 pixels outside the resized square.
Using the dropper tool set at 1 pixel samples the background remained at R255 G0 B0 O0 1% right up to 1 pixel out from the edge and changed to R0, G0, B255, O255 , 100% one pixel in from the edge. So no blended pixels there.

With PSPX7 I had a similar result horizontally and a 1 pixel halo vertically (yes thats 1 pixel) .( I started with a 1000 pixel square and 100 pixel blue square and resised to 100 pixels.)
At the top it was R203 G0, B51, O 52 20% and Bottom R51, G0, B203, O204, 80% and within the blue square it was 0,0,255,255,100%. So I do not think I will worry about a 1 pixel halo.
Using your 100 pixel square with a blue square inside and resizing to 25 pixels square I had a halo all around with R63,G0,B191,O191,75% and again this difference was only in 1 pixel.
I doubt that working with images at 1000 pixels + this will make any real difference.

[krilbe]

Well, all I can say is that mathematically, the solution is dead simple. Also, being a programmer, I cannot see any reason why this change would take more than half an hour to fix, including updating of affected test cases. All that's needed is to weigh the RGB values of old pixel with their opacity before passing them on to the actual resize calculation.

Regarding importance, certainly it won't affect anyone working with photo retouching, but as soon as you cut something out as a selection and compose a new image of parts, and as a result have an image with non-uniform opacity, any resize will produce bad results with a conspicuous halo. Anyone working with for example graphics for websites will have this problem.

I would consider correct and proper handling of transparency/opacity and resize to be very basic and important features in any image editor. To have them perform this bad is simply not acceptable. It's like having deformed characters in a Word document whenever you use a font above or below a certain size.

Bug or limitation? Call it what you want, but the fact is that the images that PSP produces when resizing any image with non-uniform opacity is quite clearly not very close to the original, and certainly not as close as it could be with a very simple fix. A one pixel halo might not matter for a large photo, but for e.g. regular web graphics it's catastrophic.

I, for one, will not upgrade my PSPP X3 (which also has this bug, btw) until this is fixed, and in the meantime will probably use GIMP.

[LeviFiction]

Krilbe, I have reported this directly to Corel. If they see fit to fix it they will. (I don't have an "in" with them, but I do have contact information for their product manager and he's passed on my suggestions before)

Though I do wonder if this has always been or if it's a development with Corel. After all PSP used to be the software everyone suggested you use if you wanted to do web graphics. So if this problem existed even back then it was hardly catastrophic.

Fact of the mater is Krilbe, I have done lots of photo-manipulations and resizing of graphics with non-uniform opacity and it has not been catastrophic. I've even made web graphics. But I've never noticed anything that's been horrible or non-workable. Photoshop is a great example of why this isn't such a horrible option because professional designers don't see a catastrophic problem with it. It has nothing to do with Photoshop being supposedly perfect, it has to do with it hasn't killed someone's work. It hasn't stopped them dead in their tracks and made the software unusable.

Does this problem exist? Yes. Has Corel been notified? Yes. Would it be great if Corel saw it as a problem and worked to correct it? Yes.

Thank you for taking such a passionate stance. Glad to know you want the software to succeed.