Blurring images with odd width or/and height

Solar2D Daily Builds and Public Releases
#1

I’ve found that rendering image with odd width or/and height blur the image, in case of inserting the image into group with reset transform the image renders properly

– good
local group1 = display.newGroup()
local image1 = display.newImage (“image.png”) – image.png any image with odd width or/and height
group1:insert( image1, true )

– bad (blur)
local group2 = display.newGroup()
local image2 = display.newImage (“image.png”) – image.png any image with odd width or/and height
group2:insert( cat2, false )

– or just
local image3 = display.newImage (“image.png”) – image.png any image with odd width or/and height

This is the fix (for image dimentions like 47x101 px)
image2.x = image2.width*0.5 - 0.5
image2.y = image2.height*0.5 - 0.5
with this code the image renders properly, but this is not proper solution for that problem.

To Ansca Team: is this possible to be fixed in the near future or this is just a feature?
[import]uid: 9058 topic_id: 6722 reply_id: 306722[/import]

#2

Folks, as far as I understand nobody have noticed the elephant??? The images are blurring!!! (Especially small images).
To Ansca Team: Please comment this “feature”.

Here the screenshot
Here the project [import]uid: 9058 topic_id: 6722 reply_id: 24624[/import]

#3

UP
Any comments? Somebody [import]uid: 9058 topic_id: 6722 reply_id: 25081[/import]

#4

UP [import]uid: 9058 topic_id: 6722 reply_id: 25478[/import]

#5

This has been discussed before and it is not a bug as such.

Even numbered width / height images will look crisp as each pixel of the image is being placed in 1 pixel of the screen. The image is centred from its centre so 1/2 an even number will give an even number for positioning.

Odd numbered images ( image being positioned from the centre ) will not line up with the pixels of the screen, as the division for the centre will include a 0.5 shift. This means opengl is trying to draw each pixel of the image over 2 pixels on the screen ( 1 half in each ).

This sub pixel rendering then results in blurred looking images for odd widths and / or heights.

There are a few solutions…

  1. Use even images

  2. Position odd images with a 0.5 px shift from where you think they should be

  3. Move the centre point of the image by 0.5 ( not tested that ) [import]uid: 5354 topic_id: 6722 reply_id: 25511[/import]

#6

It’s a bug, definitely. This was discussed and even logged as a bug #135, and this discussion was about a year ago. Nothing has changed.
I understand your explanation (and surely it’s correct for Corona render), but don’t you surprised with such behavior which do not happened in any 2D renderer? When you render a quad (with OpenGL) you set 4 points and you do not think is the image odd or not. If calculate these points position not relative to the center of the image, but to upper-left corner everything would be correct.

Concerning your solutions:

  1. We have about 4500 images in our game and a half of them odd. It will take a lot of time to make them all even.
    2-3. Doesn’t work if odd and even images should be places near each other. [import]uid: 9058 topic_id: 6722 reply_id: 25519[/import]
#7

Yeah I know, I posted the original bug.

You could batch process everything in Fireworks / Photoshop to get images even, adding a 1px transparent boarder where needed.

Did you try the display.newImage( “image.png”, 10.5, 10.5) to get the image not to blur? [import]uid: 5354 topic_id: 6722 reply_id: 25520[/import]

#8

Oh and it does happen in other programs.

The flash renderer was notorious for blurring and resizing images compared to the original.

In fact many images when loaded had strange boarders and other artefacts what existed until the later flash engines [import]uid: 5354 topic_id: 6722 reply_id: 25521[/import]

#9

Yes, but as I mentioned, this doesn’t work if odd and even images are close - there is gap of 1px.

Surely, we will use Photoshop for that, but anyway this is not very convenient. We could not batch process all images as there are many jpegs (without alpha channel).

I expected some news from Ansca team concerning the state of this bug. And I’m very surprised this problem does not bother anybody. [import]uid: 9058 topic_id: 6722 reply_id: 25526[/import]

#10

oh yeah, I had this issue before too. hm, I can’t remember how I resolved the issue (I don’t think I changed the image, just the code) so I better check later. [import]uid: 12108 topic_id: 6722 reply_id: 30938[/import]

#11

@jhocking: It will be interesting to know for future, as we already “fix” all textures. [import]uid: 9058 topic_id: 6722 reply_id: 30947[/import]

#12

I think what I did was pass newImageRect() numbers that were 1 pixel too big. Because it doesn’t support dynamic resolution I consider newImage() a deprecated command.

ADDITION: yep that’s what I did. The image is 55x55 and I set newImageRect() to 56x56 [import]uid: 12108 topic_id: 6722 reply_id: 30996[/import]

#13

@jhocking: I’ve checked, it looks better than just row “odd” image, but “even” image still more crisp. [import]uid: 9058 topic_id: 6722 reply_id: 31071[/import]