image-rs / image-png Goto Github PK
View Code? Open in Web Editor NEWPNG decoding and encoding library in pure Rust
Home Page: https://docs.rs/png
License: Apache License 2.0
PNG decoding and encoding library in pure Rust
Home Page: https://docs.rs/png
License: Apache License 2.0
This crate still refers to the old title 'afl-coverage'
I don't see it being used.
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:
cargo test
on nightly
with minimal-versions
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.
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.
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.
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);
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.
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.
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
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?
@nwin I need ownership to assign teams. See PistonDevelopers/piston#968
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.
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
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!
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?
"*" dependencies won't be permitted on crates.io. This can be fixed now.
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);
Would be nice to get some automated testing going
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'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.
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.
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
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.
I would like access to a png's textual metadata. Is there a way to get access to the iTXt, tEXt, and zTXt chunks?
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
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?
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 ?
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.
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?
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
.
Reported in image-rs/image#593.
This would be helpful for Servo.
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
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?
Decoding the following image results in FormatError("invalid uncompressed block len")
:
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.
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.
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
TransparencycHRM
Primary chromaticities and white point (#243)gAMA
Image gamma (#243)iCCP
Embedded ICC profilesBIT
Significant bitssRGB
Standard RGB colour space (#260)tEXT
Textual datazTXt
Compressed textual dataiTXt
International textual databKGD
Background colourhIST
Image histogramsPLT
Suggested palettetIME
Image last-modification timeNot 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
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.
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.
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!
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.
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.
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.)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.