Update on fuzzit: A corpus for png has been uploaded and is going to be integrated in ci image-rs/image-png#168. There's some unknown issue actually starting the respective fuzzer on the infrastructure but the main developer assured me he'd look into it tomorrow. (He's being incredibly responsive).
If everything is running there the we can use that as a template of sorts other fuzzing processes.
You've basically gotten to the correct structs
The idea is to setup an output buffer and corresponding column major packed metadata in
The idea is to setup an output buffer and corresponding column major packed metadata in
FlatSamples (there are only few helper methods here, but column_major_packed for the common case. Otherwise you have to do this by hand, sorry.) Then you can reference that buffer as a mutable image with as_view_mut/ViewMut and copy over pixel by pixel. Not optimal from an ergonomics perspective but saves you from manually working out indexing schemes.
jpeg in particular since the decoder crate is not developed by image-rs
Wikipedia suggest that the matter is even more peculiar: https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format#Color_space
Hey, I know that this is a question regarding imageproc but because it builds on image, I hope that somebody can help me.
I observed that draw_text doesn't scale correct. When I multiply my font width times the char count, the resulting width is much larger than the text itself:
(ignore the green box, but the red box is important).
Am I doing smth wrong or is my font (Oswald from Google Fonts) not suitable?
I observed that draw_text doesn't scale correct. When I multiply my font width times the char count, the resulting width is much larger than the text itself:
Am I doing smth wrong or is my font (Oswald from Google Fonts) not suitable?
it's very important, because opening even 0.5 MiB image takes almost infinite and generating thumbnail too... So I think I have to make thumbnail on the fly
extern crate png;
use png::{Decoder, Encoder};
use std::fs::File;
use std::io::{BufReader, BufWriter};
fn main() {
let file = File::open("interview.png").unwrap();
let buff_reader = BufReader::new(file);
let decoder = Decoder::new(buff_reader);
let (info, mut reader) = decoder.read_info().unwrap();
let mut data_image = vec![0; info.buffer_size()];
// do somthing ...
reader.next_frame(&mut data_image).unwrap();
let file = File::create("interview2.png").unwrap();
let ref mut buff_writer = BufWriter::new(file);
let mut encoder = Encoder::new(buff_writer, info.width, info.height);
encoder.set_color(png::ColorType::RGBA);
encoder.set_depth(png::BitDepth::Eight);
let mut header = encoder.write_header().unwrap();
header.write_image_data(&data_image).unwrap();
}thread 'main' panicked at 'called
Result::unwrap() on an Err value: Format("wrong data size, expected 3714816 got 2786112")'How I Can Fix This
Hi, have you checked if the decoded buffer you receive into
A color type of rgb would perfect fit the numbers in the error. Note that
data_image actually has rgba color type and bit depth of eight?A color type of rgb would perfect fit the numbers in the error. Note that
write_image_data does not do the transformation of adding an alpha channel internally.
let rgb_image :RgbImage ; // ...
let img_data = rgb_image.clone().to_vec();
let w = rgb_image.width();
let h = rgb_image.height();
let png_image = vec![0;img_data.len()]; // <- how calculate len png_image ?
let ref mut buff_writer = BufWriter::new(img_data);
let mut encoder = png::Encoder::new(buff_writer, w, h);
encoder.set_color(png::ColorType::RGBA);
encoder.set_depth(png::BitDepth::Eight);
let mut header = encoder.write_header().unwrap();
header.write_image_data(&png_image).unwrap();I want to encode type RgbImage to png image but the problem I have is I do not know how to calculate the data png_image length
```
You don't need to calculate the length yourself.
Instead, use
Instead, use
DynamicImage for the conversion.let rgb_image: RgbImage = /* */
let rgba_image: RgbaImage = DynamicImage::ImageRgb8(rgb_image).into_rgba();
// .. same as you create the encoder.
png.write_image_data(&rgba_image.into_vec())?;
@HeroicKatora thanks
Hello I am trying to implement seam resize
Deleting seam along the width seems to be working fine but I can't figure out what's wrong with it when I try to delete them along the height.
Here's the code for deleting a single seam
Deleting seam along the width seems to be working fine but I can't figure out what's wrong with it when I try to delete them along the height.
Here's the code for deleting a single seam
fn nuke_seamline_h(&self, buf: &mut Vec<u8>, image: &mut Vec<u8>, width: usize) {
let mut min_idx: usize = 0;
let mut min: u8 = 255;
let mut seam = BTreeSet::<usize>::new();
for i in (0..(buf.len()-width+1)).step_by(width) {
if buf[i] <= min {
min_idx = i;
min = buf[i];
}
}
seam.insert(min_idx);
while (min_idx + 1) % width != 0 {
let tedge = min_idx < width;
let bedge = min_idx + width >= buf.len();
let midi = min_idx+1;
let mid = buf[midi];
let bef = if !tedge { buf[midi-width] } else { 255 };
let aft = if !bedge { buf[midi+width] } else { 255 };
let mut min = bef;
let mut t_minid = midi-width;
if mid <= bef {
min = mid;
t_minid = midi;
}
if min <= aft {
min_idx = t_minid;
} else {
min_idx = midi+width;
}
seam.insert(min_idx);
}
for (rem, i) in seam.iter().enumerate() {
image.remove(*i - rem);
buf.remove(*i - rem);
}
}
The resulting image looks like this
buf is the gradient of the image by the way
I'm assuming you have an image buffer as in
In
For the aforementioned layout this holds true for row-by-row removal as each row has increasing indices and removes exactly one pixel.
But if you traverse the same layout column by column then the first column might remove a pixel at the end of the buffer so the next column now removes the wrong pixel.
image, i.e. the buf is always stored row-major? This would significantly affect the indexing correction in the last loop.In
*i - rem it assumes that exactly rem pixels have been removed prior to the one to-be removed in any iteration.For the aforementioned layout this holds true for row-by-row removal as each row has increasing indices and removes exactly one pixel.
But if you traverse the same layout column by column then the first column might remove a pixel at the end of the buffer so the next column now removes the wrong pixel.
I'd personally sort the indices before removing them and then remove them in strictly inreasing order.
This is an overhead of
This is an overhead of
O(width ln width) (typically square root of your image) but you don't have to do any index correction during removal
Anyone knows what causes the
failed to fill whole buffer error? I try to use image to decode a JPEG and read into a buffer, but it keeps showing me this error. I checked that the buffer length and total_bytes() is the same, and I have no problem getting dimension and color types from the stream, so I think there are no problems in decoding.
Still I don't know what causes the
failed to fill whole buffer error.
You can try
djpeg or convert -verbose to see if any warnings or errors occur in other decoders
Should I first try to decode it using
base64 crate before constructing a JpegDecoder?
Thanks
Hi there, I do not want to pressure anyone but are there any concerns about image-rs/image-tiff#100 on the
image-tiff repo implementing support for GeoTiff?