Imagesharp: Decoded image has missing rows of pixels on Android

[TodesBrot]

Prerequisites

• [X] I have written a descriptive issue title
• [X] I have verified that I am running the latest version of ImageSharp
• [X] I have verified if the problem exist in both DEBUG and RELEASE mode
• [X] I have searched open and closed issues to ensure it has not already been reported

Description

One specific image does not seem to be correctly loadable on Android. The decoded image's dimensions are correct, but the 18 bottom most rows of pixels are all set to <0, 0, 0, 0>. The image can be properly loaded on Windows, and on Android it can be correctly loaded by other image libraries. The bug is reproducable on my Sony Xperia Z1 Compact and my Samsung Galaxy Tab A 9.7. This is the image in question:

Steps to Reproduce

I have managed to create a minimal code example. This was created using Xamarin.Android on Visual Studio 2015. The project contains the image as a resource called Tree.bytes (in order to circumvent Android's resource compression on images) in the folder Resources\drawable. The first line can be commented back in to see the comparison with Android's native image loading. Here is the code:

//#define native

using Android.App;
using Android.Widget;
using Android.OS;
using Android.Graphics;
using ImageSharp;
using System.IO;

namespace ImageSharp_Bug
{
    [Activity(Label = "ImageSharp_Bug", MainLauncher = true, Icon = "@drawable/icon", Theme = "@android:style/Theme.Black.NoTitleBar.Fullscreen")]
    public class MainActivity : Activity
    {
        protected override void OnCreate(Bundle bundle)
        {
            base.OnCreate(bundle);



            Bitmap bmp;
            Stream src = this.Resources.OpenRawResource(Resource.Drawable.Tree);

#if native
            bmp = BitmapFactory.DecodeStream(src);
#else
            Image<Rgba32> image = Image.Load(src);

            Rgba32[] pixels = image.Pixels;

            bmp = Bitmap.CreateBitmap(image.Width, image.Height, Bitmap.Config.Argb8888);

            for (int x = 0; x < image.Width; x++)
            {
                for (int y = 0; y < image.Height; y++)
                {
                    Rgba32 pixel = pixels[y * image.Width + x];
                    bmp.SetPixel(x, y, new Color(pixel.R, pixel.G, pixel.B, pixel.A));
                }
            }
#endif

            ImageView view = new ImageView(this);
            view.SetBackgroundColor(Color.White);
            view.SetImageBitmap(bmp);

            this.SetContentView(view);
        }
    }
}

About the image compression: If the image is named Tree.bytes, it is not compressed and the bug happens. If the image is named Tree.png, it is compressed and gets loaded correctly.

System Configuration

The bug occurs on my Sony Xperia Z1 Compact (Android version 5.1.1) and my Samsung Galaxy Tab A 9.7 (Android version 6.0.1). The app was created using Xamarin.Android, compiled using Android 6.0 with the minimum target version 4.1.

• ImageSharp version: 1.0.0-alpha9-00058
• Other ImageSharp packages and versions:
• Environment (Operating system, version and so on): see above
• .NET Framework version: I was not able to choose a target version, as Xamarin did not give me that option. But the app uses libraries that target .NET 4.5, so that is most likely the minimum version.
• Additional information:

[antonfirsov]

@TodesBrot I wonder if someone can investigate this, unfortunately there are no mobile developers in the current team AFAIK :( Is it possible to reproduce this on an emulator?

[TodesBrot]

@antonfirsov I haven't managed to get an emulator to work yet, but I could try to investigate the bug. I'm not that well versed in graphics programming though, so I can't promise anything.

[JimBobSquarePants]

@TodesBrot Did you ever get a chance to re-investigate this?

[TodesBrot]

@JimBobSquarePants I've totally forgotten about this, so I haven't investigted anything. I'm still having trouble getting an emulator to work, but I've confirmed that the bug still happens with the current beta release of ImageSharp.

[JimBobSquarePants]

@TodesBrot Bugger... Zero idea what could cause this. 😞

[KLuuKer]

Maybe check if this also happens when running on mono

@TodesBrot could you try decoding the image and saving it as a bmp file, then move that bmp to the desktop and check if it got decoded properly? this way you can check if it's a purely a decoding issue

[TodesBrot]

After way too much time, I finally got Mono working on Windows. The bug occurs on Windows too when using Mono, so it is a framework issue rather than a platform one.

@KLuuKer I have confirmed that this is purely a decoding issue. The bottom rows are still missing when saved as a BMP file.

[TodesBrot]

I edited the PncDecoderCore code so that every time it tries to process a chunk, the chunk type gets written to the console. On .NET this results in the output "IHDR, IDAT, IDAT, IEND", but on Mono between the last IDAT and IEND, it tries to process 686 chunks with the type null. These chunks all have random lengths, such as -1763762839 or 1856068475. The amount of chunks, 686, also corresponds with the length of the last IDAT chunk, which is also 686.

It seems the bug happens when reading the last IDAT chunk. After reading this chunk, the position of the deframeStream is different between Mono and .NET. On .NET the position is 8935, and on Mono it is 8249. The difference is yet again 686.

Right after calling this.ReadScanlines when processing data chunks, the variable currentRow has different values between Mono and .NET. On .NET, the values are 540 and 560 for the two IDAT chunks, whereas on Mono both values are 542.

[JimBobSquarePants]

Thanks @TodesBrot this is really useful! 👍 There's two things we need to do then.

1. Report this upstream in the Mono bugtracker.
2. See if there is a way to force your zlib wrapper to read the last bytes (could you perhaps experiment with that?)

[JimBobSquarePants]

Looks like raising Mono issue is gonna get easier 😄

https://twitter.com/migueldeicaza/status/937769295723089921

[JimBobSquarePants]

@TodesBrot Would you be able to run a test against the latest nightly. We discovered a Mono bug which we reported and found a workaround for. I think it should have squashed the issue.

[TodesBrot]

@JimBobSquarePants I can confirm that the bug is gone now. Works like a charm! Great work!

[JimBobSquarePants]

You can thank the wizard that is @dlemstra for that one!