Reported in image-rs/image#593.

The afl fuzzer target in ./png-afl currently exits with SIGABRT as soon as any decoding errors occurs, causing AFL to think for example "CRC mismatch" is a crashing input file.

Decoding the following image results in FormatError("invalid uncompressed block len"):

https://github.com/servo/servo/blob/master/tests/wpt/css-tests/css21_dev/html4/support/white_color.png

Would be nice to get some automated testing going

https://github.com/image-rs

Hi, I'm trying to port an image processing algorithm to the web with wasm-bindgen. The first step is to read a png image. I used this crate for that and it worked so thanks for that! I've set up a minimal working example to use png in wasm. The issue I have is that the decoding takes roughly 0.1s on my machine in wasm for a 640x480 png while being orders of magnitude faster on native code (cf perf screenshot below).

Any idea of what might be causing this issue?

I would like access to a png's textual metadata. Is there a way to get access to the iTXt, tEXt, and zTXt chunks?

I tried to search in the document, and the search didn't seem to work. (Seems to be due to the network.)

How to set resolution?

When opening the png file found at http://st1.skybet.com/static/bet/img/cross-sell/sky-poker.png (mirrored here) an index error occurs.

Stack backtrace using examples/show.rs:

stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::slice::slice_index_len_fail
             at /checkout/src/libcore/slice/mod.rs:748
  10: <core::ops::range::Range<usize> as core::slice::SliceIndex<[T]>>::index
             at /checkout/src/libcore/slice/mod.rs:879
  11: core::slice::<impl core::ops::index::Index<I> for [T]>::index
             at /checkout/src/libcore/slice/mod.rs:730
  12: <alloc::vec::Vec<T> as core::ops::index::Index<core::ops::range::Range<usize>>>::index
             at /checkout/src/liballoc/vec.rs:1575
  13: png::decoder::expand_paletted::{{closure}}
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/mod.rs:455
  14: png::decoder::expand_paletted
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/utils.rs:33
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/mod.rs:452
  15: <png::decoder::Reader<R>>::next_interlaced_row
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/mod.rs:273
  16: <png::decoder::Reader<R>>::next_row
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/mod.rs:238
  17: <png::decoder::Reader<R>>::next_frame
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/mod.rs:229
  18: show::load_image
             at ./show.rs:23
  19: show::main_loop
             at ./show.rs:64
  20: show::main
             at ./show.rs:194
  21: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:99
  22: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:59
  23: main
  24: __libc_start_main
  25: _start

The Limits struct should limit buffer size instead of image dimensions. With image-rs/image#860 I had remove the limits in order to decode large images, with a limit on buffer size one could decode huge images while keeping a reasonable limit on memory usage.

Also see discussion in image-rs/image-tiff#29.

Why should I use this over https://github.com/PistonDevelopers/image ?

I'm trying to open a 16 bits grayscale png image as displayed by the file command here:

$ file icl-depth/0.png
icl-depth/0.png: PNG image data, 640 x 480, 16-bit grayscale, non-interlaced

The Rust code I'm using is:

fn main() {
    // Load 16 bits PNG depth image.
    let img_file = File::open("icl-depth/0.png").unwrap();
    let decoder = png::Decoder::new(img_file);
    let (info, mut reader) = decoder.read_info().unwrap();
    let mut buffer = vec![0; info.buffer_size()];
    reader.next_frame(&mut buffer).unwrap();

    // Display info.
    println!("width: {:?}", info.width);
    println!("height: {:?}", info.height);
    println!("bit depth: {:?}", info.bit_depth);
    println!("buffer size: {:?}", info.buffer_size());
}

Returns an 8 bits decoder instead of 16 bits decoder:

width: 640
height: 480
bit depth: Eight
buffer size: 307200

How can I use the png crate to read 16 bits grayscale images?

On big endian systems I'm getting FormatError("Checksum mismatch!") when I try to decode the same images that work on little endian systems. It seems like endianness isn't handled correctly somewhere.

This is one of the files that fails to be decoded: https://i.imgur.com/mOM85Gh.png

I see you also have encoder functionality. The piston crate in fact gives its to its users, so I assume its mature?

Would it be possible to update the github description of the repo and the description in Cargo.toml to reflect that?

I'm coming from a discussion in IRC where someone erroneously assumed (probably due to this misinformation) that this crate can only decode.

Thanks!

This would be helpful for Servo.

For:

[dependencies.png]
default-features = false
version = "0.14"

I get:

   Compiling png v0.14.0
error[E0463]: can't find crate for `deflate`
 --> /home/yeet/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.14.0/src/common.rs:2:1
  |
2 | extern crate deflate;
  | ^^^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

Seems to have been added by 4776792, and definitely looks incorrect to me; common.rs says "shared", so can't have non-default stuff like that in it?

(I'm on modern Ubuntu, recent nightly Rust. Almost certainly irrelevant.)

There's a crc32 implementation in src/crc.rs

A duplicate also lives in tests/check_testimages.rs

This issue is for reusing the code from src/crc.rs and deleting the duplicated code in tests/check_testimages.rs

My PNG is indexed but this crate reads it as RGB so buf is being filled with RGB bytes instead of palette indices.

$ pngcheck chariot-nope-64x64.png
OK: chariot-nope-64x64.png (64x64, 8-bit palette, non-interlaced, -22.7%).

let png_path = "/path/to/this.png";
let f = std::fs::File::open(png_path).expect(&format!("Failed to open {}", &png_path));
let decoder = png::Decoder::new(f);
let (info, mut reader) = decoder.read_info().expect("Failed to 'read_info' ???");
let mut buf = vec![0; info.buffer_size()];
reader.next_frame(&mut buf).expect("Failed to read frame");

// This fails!
assert_eq!(png::ColorType::Indexed, info.color_type);

https://github.com/PistonDevelopers/image-png/blob/104b08036bf926d10fa96cec40b3134d337cccbf/src/decoder/mod.rs#L328 is suspect.

If I need to hack together a workaround myself I will, or if someone will help me fix the actual issue and get that merged I'm more than happy to do so.

Progress on a project of mine is stalled while this is an issue.

Perhaps I am using the library incorrectly. I would be happy to be corrected and close this.

Getting this error when attempting to publish 0.4.0:

target/package/png-0.4.0/src/decoder/stream.rs:14:5: 14:12 error: couldn't read "target/package/png-0.4.0/src/decoder/../../inflate/src/lib.rs": No such file or directory (os error 2)
target/package/png-0.4.0/src/decoder/stream.rs:14 mod inflate;
                                                      ^~~~~~~
failed to verify package tarball

Caused by:
  Could not compile `png`.

The error does not occur with cargo build.

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 image-png Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @bvssvni
• @eddyb
• @nwin

This png file reproduces the issue: http://en.blitzortung.org/Flags/eu.png
To reproduce, run examples/show.rs in debug mode, or enable overflow-checks in Cargo.toml

I tried to report this directly to the inflate crate, but I couldn't manually craft a rust file that crashed.

Stack trace:

thread 'main' panicked at 'attempt to subtract with overflow', /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/inflate-0.2.0/src/lib.rs:583:27
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::panicking::panic
             at /checkout/src/libcore/panicking.rs:51
  10: inflate::InflateStream::run_len_dist
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/inflate-0.2.0/src/lib.rs:583
  11: inflate::InflateStream::next_state
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/inflate-0.2.0/src/lib.rs:863
  12: inflate::InflateStream::update
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/inflate-0.2.0/src/lib.rs:1053
  13: png::decoder::stream::StreamingDecoder::next_state
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/stream.rs:362
  14: png::decoder::stream::StreamingDecoder::update
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/stream.rs:169
  15: <png::decoder::ReadDecoder<R>>::decode_next
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/mod.rs:109
  16: <png::decoder::Reader<R>>::next_raw_interlaced_row
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/mod.rs:428
  17: <png::decoder::Reader<R>>::next_interlaced_row
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/mod.rs:254
  18: <png::decoder::Reader<R>>::next_row
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/mod.rs:238
  19: <png::decoder::Reader<R>>::next_frame
             at /home/mateon/.cargo/registry/src/github.com-1ecc6299db9ec823/png-0.9.0/src/decoder/mod.rs:229
  20: show::load_image
             at /shared/dev/rust/image-png/examples/show.rs:23
  21: show::main_loop
             at /shared/dev/rust/image-png/examples/show.rs:64
  22: show::main
             at /shared/dev/rust/image-png/examples/show.rs:194
  23: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:99
  24: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:59
  25: main
  26: __libc_start_main
  27: _start

Most uses of transmute are useless and security hazards, they should be replaced by something less magical. For examples the various transmute calls in from_u8 methods can be replaced entirely by safe code.

I'm working on a game and I'm using this crate (through the image crate,) to load two 1024 by 1024 textures on startup. In debug mode this takes around 1.4 seconds on my admittedly old/underpowered machine. (The game loads much faster in release mode.) So, I had a look at the source to see if there was any low-hanging fruit optimizations to be had. I found this line where a new vector is being allocated and copies being made, just to effectively remove elements from the start of the vector. I haven't found a simple way to speed that up but I thought I would share what I have found.

I looked for a way to optimize the operation and found this stackoverflow page. It suggests either replacing the line with something like self.current.drain(..rowlen);, replacing the Vec with a VecDeque or using a custom data structure.

I tried self.current.drain(..rowlen); and didn't get measurably different results (it's still copying the elements). I also tried swapping out the Vec with a VecDeque but that seems to be non-trivial. There is an implementation of the custom datastructure here but the author themselves describes it as unfinished. The custom data structure more or less just keeps track of the offset into the front of the Vec so that might be the easier way to go.

There is an integer overflow in https://github.com/PistonDevelopers/image-png/blob/99383650e1a440bb14c54987938676c8f54d3bc6/src/decoder/mod.rs#L51

Aside of posing dangers for unsafe code (which shouldn't rely on this value anyway), this overflow causes enormous amounts of memory to be actually allocated when fed to png crate via the fuzzing harness. Not just virtual memory - actual physical memory.

The worst part is, fixing this correctly requires changing the external API: the function should use checked_mul() which returns Option<usize>, and actually return either an Option or Result to the outside.

Testcase: integer_overflow_in_multiplication found via afl-rs. Steps to reproduce the crash can be found in #79 except you need to build in debug mode, without the --release flag.

I would appreciate advice on how to proceed with fixing this issue. Is adding "deprecated" marker to this function in 0.12 series and releasing 0.13 with a breaking fix appropriate? Do we need the semver trick here?

Update: libpng itself also had similar issues; see https://libpng.sourceforge.io/decompression_bombs.html for more info. Among other things, they have introduced limits on the possible size of an image by default. In Rust we can easily allow the API user to override these limits via the builder pattern.

It seems like the travis ci script does not run cargo test, is this intentional? Currently cargo test fails because of some syntax errors in examples/pngcheck.rs, this should probably be fixed asap.

Previous fuzzing attempts did not bypass crc32 checks in png and adler32 checks in inflate crates. Thus they never actually exercised the png decoding code.

I have disabled checksum verification in fuzzing mode via conditional compilation and ran cargo-fuzz. I got a crash in less than a second.

Details on this specific panic: it happens at line https://github.com/PistonDevelopers/image-png/blob/1266ec2/src/decoder/mod.rs#L450

Steps to reproduce:

git clone https://github.com/Shnatsel/png-leak.git
cd png-leak
env RUST_BACKTRACE=1 RUSTFLAGS='--cfg fuzzing' cargo run

This repo uses my fork of image-png with crc32 conditionally disabled. --cfg fuzzing in the above command disables it so that fuzzer-generated files can be tested. The file that's causing the crash is included in the repo and can be downloaded here.

Hello,

I'd like to write images so large I cannot store them uncompressed in memory.

As far as I can tell, with the current state of the library, this is impossible. It seems to me that you must either call png::Writer::write_image_data with the entire image or not at all. No other function seems to be a candidate for the functionality I'm searching for - we seem to have a StreamingDecoder but no StreamingEncoder.

I'd love to be proven wrong obviously :-) or any advice you can give for this request. It is technically possible - libpng implements it via the png_write_rows function.

I've run the in-tree AFL fuzzing harness for a minute and it has discovered a crash with the following message: memory allocation of 12884705376 bytes failedAborted

This is a full-process crash and, unlike a panic, is not recoverable.

Steps to reproduce: env RUST_BACKTRACE=1 RUSTFLAGS='--cfg fuzzing' cargo run --example show path/to/malformed/file

Testcases triggering the crash are attached: crashes.zip

Your fuzz target is very fast - it finds this crash in a few seconds in release mode and hits 1 million executions in under 5 minutes on a single core of my laptop. You really should consider fuzzing on CI to prevent these regressions.

Why is it living in the root directory? Can we delete it?

Since png depends on flate2, which relies on miniz.c, this means that to build this crate people need to have a C/C++ compiler setup, which is annoying for users on Windows who just install Rust and expect things to work.

image-rs/image#419

Currently the encoder lacks built-in support for writing metadata chunks, you can do it manually with Writer::write_chunk. However I believe that there should be a nicer high-level way of doing this.

• pHys pixel density (in progress #124)
• tRNS Transparency
• cHRMPrimary chromaticities and white point (#243)
• gAMA Image gamma (#243)
• iCCP Embedded ICC profile
• sBITSignificant bits
• sRGB Standard RGB colour space (#260)
• tEXT Textual data
• zTXt Compressed textual data
• iTXt International textual data
• bKGD Background colour
• hIST Image histogram
• sPLT Suggested palette
• tIME Image last-modification time

Not all of these are equally important, however it would be nice to have support for all of them. See https://www.w3.org/TR/2003/REC-PNG-20031110/#11Ancillary-chunks for specifications on what the chunks should look like.

See also image-rs/image#911

Im getting a thread 'main' has overflowed its stack error. Just use the sample code in docs.rs to reproduce the bug:

    // For reading and opening files
    use std::path::Path;
    use std::fs::File;
    use std::io::BufWriter;
    // To use encoder.set()
    use png::HasParameters;

    let path = Path::new(r"/path/to/image.png");
    let file = File::create(path).unwrap();
    let ref mut w = BufWriter::new(file);

    let mut encoder = png::Encoder::new(w, 2, 1); // Width is 2 pixels and height is 1.
    encoder.set(png::ColorType::RGBA).set(png::BitDepth::Eight);
     let mut writer = encoder.write_header().unwrap();

    let data = [255, 0, 0, 255, 0, 0, 0, 255]; // An array containing a RGBA sequence. First pixel is red and second pixel is black.
    writer.write_image_data(&data).unwrap(); // Save

This works in 0.5.2 but not on 0.6.1. (btw Also getting blank jpegs for image 0.12.0 (no prob on 0.10.4) that might be related but i'm too tired for today to investigate and file an issue.)

@nwin I need ownership to assign teams. See PistonDevelopers/piston#968

The command cargo +nightly test -Z minimal-versions does not succeed on Windows machines, due to resolving to version 0.0.1 of winapi. This crate version contains invalid syntax. Two options:

1. Do not execute cargo test on nightly with minimal-versions
2. Declare minimum versions that resolve correctly

This is not a definite statement, but when I compare using gdk_pixbuf_new_from_file directly, which loads in e.g. png images... but Instead I do !include_bytes(image), then decode with this png crate and feed it to gdk_pixbuf_new_from_data, then I see quite a performance difference. Those things should almost roughly do the same, no?

    let input = BufReader::new(File::open("f.png").unwrap());
    let decoder = png::Decoder::new(input);
    let (infos, rest) = decoder.read_info().unwrap();
    println!("{}", infos.color_type as u16);

# file f.png
one.png: PNG image data, 64 x 64, 4-bit colormap, non-interlaced

Output: 2, should be 3

https://github.com/PistonDevelopers/image-png/blob/554bdcf6939dd56b29b8aed987a8576c415ae484/src/chunk.rs#L57

Eq is left out of the #[derive()] list on many enums, like for example ColorType and BitDepth. Is there any reason for this? Very annoying when I just want to assert they are equal to something without having to match in a small utility program.

It was just recently updated to version 0.5.0, which included a change that makes flags private by default. Here's an example of it failing.

"*" dependencies won't be permitted on crates.io. This can be fixed now.

After putting show.rs into a new project and running the resulting binary:

# ./target/debug/show-png 4458.png  
thread '<main>' panicked at 'The `Frame` object must be explicitly destroyed by calling `.finish()`', /rustjail/.cargo/registry/src/github.com-88ac128001ac3a9a/glium-0.13.4/src/lib.rs:1220

The current builds fails on Travis due to an issue with the png testsuite?? For some reason, some file is not checked resulting in

thread 'render_images' panicked at 'reference for "\"tests\\\\pngsuite\\\\s35n3p04.png\"" is missing', src\libcore\option.rs:1038:5

Interestingly the file is not consistent and nightly fails with another image instead:

thread 'render_images' panicked at 'reference for "\"tests\\\\pngsuite\\\\basi6a08.png\"" is missing', src\libcore\option.rs:1036:5

I'm confused. Is the directory checkout incomplete or is this an issue with the glob library or with the manner we iterate the images?

I don't see it being used.

extern crate png;

use std::fs::File;
use png::HasParameters;

fn main() {
    let mut output_data = vec![0xff; 1080 * 1080 * 4];
    for x in 1080 * 1080 * 2.. 1080 * 1080 * 4 {
        output_data[x] = 0;
    }

    let output_file = File::create("out.png").unwrap();
    let mut encoder = png::Encoder::new(output_file, 1080, 1080);
    encoder.set(png::ColorType::RGBA).set(png::BitDepth::Eight);
    let mut output = encoder.write_header().unwrap();
    output.write_image_data(&output_data).unwrap();
}

out.png is expected to be an image with the top half white, opaque. Bottom half black, transparent. Instead it is an entirely white image with the bottom half transparent.

This would be useful for Servo.

I'm saving a 4-bit PNG (using this library), and identify reports it 4 bit:

Image: tmp/meta_low.png
  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: PseudoClass
  Geometry: 2048x16384+0+0
  Units: Undefined
  Colorspace: Gray
  Type: Grayscale
  Base type: Undefined
  Endianess: Undefined
  Depth: 8/4-bit
  Channel depth:
    Gray: 4-bit
  Channel statistics:
    Pixels: 33554432
    Gray:
      min: 0  (0)
      max: 119 (0.466667)
      mean: 24.0818 (0.0944384)
      standard deviation: 22.2654 (0.0873152)
      kurtosis: 7.38533
      skewness: 2.35856
      entropy: 0.627434

Not sure what "Depth: 8/4-bit" is, tbh...

When loading, I'm getting BitDepth::Eight. Loading code:

let file = File::open(path).unwrap();
let decoder = png::Decoder::new(file);
let (info, mut reader) = decoder.read_info().unwrap();
assert_eq!(info.bit_depth, png::BitDepth::Four);

@bvssvni Would you mind adding maintainers to that crate? #94 needs to be merged.

rust-fuzz/afl.rs@41d37ed

This crate still refers to the old title 'afl-coverage'