Quality Problems with Mipmaps about bcnencoder.net HOT 9 CLOSED

Seems like the ImageSharp team might add the option for resizing the image with non-premultiplied alpha based on your issue. I can add the option to the encoder once they update the package.

from bcnencoder.net.

Ah, you're correct. I'll fix it today.

I'm not sure if it should be ||, since that would mean the last mip might be something else than 1x1. I guess I could check how other encoders handle tall or wide textures.

A bit of a shame that we switched off of ImageSharp right when they added this, but at least they now have the feature if someone needs it.

from bcnencoder.net.

I'll look into it.

from bcnencoder.net.

Hey,

Sorry that this took so long, but I've looked into it a little more closely now and it seems that the difference in mipmaps stems from the resizing algorithm used. Most likely whatever program encoded the original image was using a nearest-neighbor-style resizing algorithm, while mine uses ImageSharp's default resizing function (which probably uses some kinda blending of pixels).

For what it's worth, the mip3 in the expected output folder has way more beige and brown colors than the original image in the corresponding spots, while the colors look more accurate proportionately in BcnEncoder's output.

I think adding an option in the encoder for which resizing algorithm to use could be something beneficial, but it doesn't seem like a too big of a problem for now.

from bcnencoder.net.

No worries, thanks for looking into this. I guess it's just odd to me that there's such huge black bands after a resize from 64x64 to 32x32. I see now that it is due to ImageSharp. Looks like by default ImageSharp uses bicubic interpolation.

I guess it's easy enough to try my own resizing techniques and feed each mip separately into your encoder for now.

I thought it might be a bug in ImageSharp since using bicubic scale image in Gimp produces very different results.
SixLabors/ImageSharp#1498

from bcnencoder.net.

Hey, since ImageSharp is not used for resizing in 2.0.0, would you like to try and see if this is still an issue in the new version?

from bcnencoder.net.

There's a bug in MipMapper.cs in loop at line 85. If the maxNumMipMaps is a number such that mipWidth or mipHeight do not become one, then the output remains 0. This in turn causes result at line 37 to be an empty array.

https://github.com/Nominom/BCnEncoder.NET/blob/master/BCnEnc.Net/Shared/MipMapper.cs#L85

Also, I'm wondering if the statement mipWidth == 1 && mipHeight == 1 should use || not &&. Although this may be a moot point if the method has to be rewritten in a different way.

Once I made a temporary fix I was able to confirm that this issue is resolved. Also, probably doesn't matter anymore, but ImageSharp just had a new release (1.0.3) that should fix the original problem too.

from bcnencoder.net.

New version is up in nuget with a fix.

from bcnencoder.net.

Looks like the problem has been fixed. Thanks!

from bcnencoder.net.