eliotjones / biggustave Goto Github PK

Hello @EliotJones , Thank you for the library!

Is there a possibility of writing data in the png file? We wanted to store metadata something similar to the badge baking option available in - https://github.com/concentricsky/openbadges-bakery

Thanks in advance.

Hello again @EliotJones!

PNG images of Color type 3 may contain what the specification calls "simple transparency" - alpha values associated with the palette entries. These alpha values will be contained in single chunk of type tRNS, which must follow the PLTE chunk. The tRNS chunk will contain a series of one-byte alpha values corresponding to the entries in the PLTE chunk. This is described by the PNG Specification at 4.2.1.1.

BigGustave does not handle this part of the specification. I've added it on my end, and have submitted f9af15c if you would like to include it in upstream.

This PR might also fix the issue identified in #7, if that issue is associated with Color type 3. Alternatively, #7 might be caused by lack of transparency support for Color type 2. For Color type 2, the transparent color is represented by a tRNS chunk of length 6 that is not associated with a PLTE entry. f9af15c does not add this functionality.

I've got these door and while reading pixel by pixel alpha component is 255 on each one.
I've tried saving this PNG in GIMP without background color, but it doesn't help.

Using Visual Studio 2019 Community + BigGustave v1.0.3 from NuGet

Code snippet:

var stream = File.OpenRead(path);
Png image = Png.Open(stream);

Console.WriteLine("X = 255 / SPACE = 0");
for (int y = 0; y < image.Height; ++y)
{
	for (int x = 0; x < image.Width; ++x)
	{
		Pixel px = image.GetPixel(x, y);
		if(px.A == 255)
			Console.Write("X");
		else
			Console.Write(" ");
	}
	Console.WriteLine("");
}
Console.WriteLine("\n");

have any solution on read write chunk (eg itxt) like https://www.nayuki.io/page/png-file-chunk-inspector
would even pay for it

Hi @EliotJones,
I've found a problem with your lib trying to decode this file:

I was using a simple loop to read pixel by pixel the file but something in the output wasn't correct so I tried to simply copy the image into a new one, with this code:

var stream = File.OpenRead("test.png");
var image = Png.Open(stream);
var streamOut = File.Create("testOut.png");
var builder = PngBuilder.FromPng(image);
builder.Save(streamOut);
streamOut.Close();

The output image is this:

The input file seems to be ok (you can inspect it here)
With other files (created using the same process) this problem doesn't shows up.

Any thoughts?

Thanks

Hi @EliotJones,

BigGustave's PngOpener class throws an exception and does not return a Png object if it encounters trailing data after an IEND chunk. The exception is thrown at PngOpener.cs:44.

The W3C PNG specification at 3.2. states that the IEND chunk serves as the end-of-file marker, and BigGustave follows this requirement.

However, I think it is the common convention among PNG readers to ignore trailing data after IEND, and to return a valid image, if one has been successfully unpacked, upon encountering the IEND chunk.

If BigGustave were to follow this convention, then I think the easiest change to make would be to replace the throw statement on PngOpener.cs:44 with a break statement. Conditionally, one could disable throwing an exception using a static features boolean, and/or log a debug message using whatever method you would prefer. For my purposes, I do not care if there is trailing data and so I simply break at 44.

Thanks again for your great work on this library!

Hi @EliotJones, thanks for this excellent library. I found a minor error while loading PNG images on this end, and am submitting a suggested fix.

A PNG file that is not paletted (header.ColorType != 3) can nonetheless have a PLTE header chunk. See the W3C PNG (Portable Network Graphics) Specification at 4.1.2. I do not know for certain, but I think this functionality is intended to be used as a suggested palette for rendering a 24/32-bit PNG in 8-bit color depth.

When BigGustave opens a PNG file with a PLTE header chunk, it will override the header.ColorType and use the palette to interpret the raw pixel data. This will either cause an exception to be thrown or cause unexpected behavior, depending on the values of the raw pixel data and the number of entries in the palette. I am attaching a sample PNG file that will cause an exception to be thrown when opened.

I have also proposed a very simple fix as Pull Request #2 on this repository: don't use the palette unless (header.ColorType | ColorType.PaletteUsed) == ColorType.PaletteUsed.

Thanks again for your work on this library! I am using it to replace a dependency on System.Drawing in an asset pipeline for a game I am working on.

SamplesPerPixel seems to return 0 on at least some 256 color images, resulting in some of the lines having incorrect filter applied.

Suggested fix might be adding a case for "case ColorType.PaletteUsed | ColorType.ColorUsed":

		switch (header.ColorType)
		{
			case ColorType.None:
				return 1;

			case ColorType.PaletteUsed | ColorType.ColorUsed:
			case ColorType.PaletteUsed:
				return 1;

			case ColorType.ColorUsed:
				return 3;
			case ColorType.AlphaChannelUsed:
				return 2;
			case ColorType.ColorUsed | ColorType.AlphaChannelUsed:
				return 4;
			default:
				return 0;
		}

Hi @EliotJones,

In the released library version 1.0.2 there are some File.WriteAllBytes(@"C:\temp\... calls present, which cause the library to fail.

For example in PngBuilder.cs on line 30.

Best regards,
Michael

When indexed color and transparent background are used together. If the program saves it as read, it will have vertical stripes where it should be on a transparent background.

The error file and source are enclosed.

Class1.zip

logo.zip

When opening the attached image after applying the patch from issue #13 (#13 (comment)), the library fails while reading the image.
The image is interlaced using Adam7.

Currently we make invalid ZLib data using the DeflateStream with a couple of hardcoded bytes appended. We should instead wrap the DeflateStream output with the expected header and checksum as detailed here: https://stackoverflow.com/a/2331025/1775471

Compression of data happens here: https://github.com/EliotJones/BigGustave/blob/master/src/BigGustave/PngBuilder.cs#L104

The resulting image should be compatible with https://tinypng.com/