Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 03:41
    strasdat commented #1846
  • Jan 27 17:17
    fintelia commented #1848
  • Jan 27 07:08

    HeroicKatora on master

    Exhaustively match in ColorType… Merge pull request #1848 from f… (compare)

  • Jan 27 07:08
    HeroicKatora closed #1848
  • Jan 27 03:21
    fintelia edited #1849
  • Jan 27 03:21
    fintelia opened #1849
  • Jan 27 02:44
    fintelia opened #1848
  • Jan 26 17:54
    fintelia commented #1846
  • Jan 26 09:03
    HeroicKatora commented #1846
  • Jan 26 04:20
    EstebanBorai closed #1251
  • Jan 25 23:44
    fintelia commented #1846
  • Jan 25 23:00
    fintelia commented #1846
  • Jan 25 22:31
    strasdat edited #1846
  • Jan 25 20:28

    HeroicKatora on master

    feat: less restrictive FlatSamp… style: rustfmt Merge pull request #1847 from s… (compare)

  • Jan 25 20:28
    HeroicKatora closed #1847
  • Jan 25 12:41
    strasdat synchronize #1847
  • Jan 25 08:23
    strasdat opened #1847
  • Jan 25 07:50
    strasdat edited #1846
  • Jan 25 07:37
    strasdat opened #1846
  • Jan 24 18:00
    zaynetro commented #1482
HeroicKatora
@HeroicKatora
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.
HeroicKatora
@HeroicKatora

We just reached 1 million downloads. From crates.io:

Stats Overview
1,000,260 Downloads all time

Feels somewhat surreal

Yuki Okushi
@JohnTitor
Congrats!
Jacob Rosenthal
@jacobrosenthal
Hey all, any guidance on getting the image data as a buffer/pixels by column instead of row? Seems like theres something here with FlatSamples and NormalForm::ColumnMajorPacked but not sure how to put it all together yet
HeroicKatora
@HeroicKatora
You've basically gotten to the correct structs
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.
arthmis
@arthmis
Hello, do the decoders handle conversion from sRGB to RGB? Specifically the jpeg decoder.
HeroicKatora
@HeroicKatora
They don't. Or, I'm not entirely sure. It's somewhat awkward
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
arthmis
@arthmis
Ok, thank you. I skimmed through the decoder and it doesn't seem to handle srgb, though I'm probably missing something.
Conner
@ZargorNET
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: example (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?
HeroicKatora
@HeroicKatora
@ZargorNET Sorry for the delay, it's probably better to open an issue on imageproc as this channel is for main image.
zero-systems
@zero-systems
Hello, Is it possible to asynchronously read image? I have actix-multipart crate, which helps me gathering multipart data from http, but I don't see any things which can help me generating thumbnails on the fly. is it possible to do this with image-rs crate?
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
Kunal Mohan
@kunalmohan
Hi! I am somewhat new to using the image crate. I have been facing problem with the load_from _memory function. Doesn't it support jpeg images?
Mahdi Robatipoor
@robatipoor
hi
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();
}
i got error message
thread 'main' panicked at 'called Result::unwrap() on an Err value: Format("wrong data size, expected 3714816 got 2786112")'
How I Can Fix This
HeroicKatora
@HeroicKatora
Hi, have you checked if the decoded buffer you receive into 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.
Mahdi Robatipoor
@robatipoor
thanks
        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 use crate image and png
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
```
Mahdi Robatipoor
@robatipoor
error
panicked at 'called `Result::unwrap()` on an `Err` value: Format("wrong data size, expected 106964 got 80223")
Jorge Carrasco
@carrascomj_gitlab
You're trying to write a RGBImage with a RGBA encoder. You can check in the error that 80223/3+80223 = 106964; that is, one channel (alpha) is missing per pixel
HeroicKatora
@HeroicKatora
You don't need to calculate the length yourself.
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())?;
Mahdi Robatipoor
@robatipoor
@carrascomj_gitlab thanks
@HeroicKatora thanks
Rupansh
@rupansh
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
    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
HeroicKatora
@HeroicKatora
I'm assuming you have an image buffer as in 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 O(width ln width) (typically square root of your image) but you don't have to do any index correction during removal
Chehui Chou
@deadshot465_gitlab
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.
Chehui Chou
@deadshot465_gitlab
I tried load_from_memory_with_format but to no avail
HeroicKatora
@HeroicKatora
Very likely the jpeg is actually corrupt. Do you know what produced it?
Many implementations have varying strategies for recovering but that incurs a lot of complexity.
And I'm afraid no-one had enough time to deal with that.
You can try djpeg or convert -verbose to see if any warnings or errors occur in other decoders
Chehui Chou
@deadshot465_gitlab
It's some base64-encoded texture files embedded inside glTF 3D models
Should I first try to decode it using base64 crate before constructing a JpegDecoder?
HeroicKatora
@HeroicKatora
Certainly image won't magically know that it happens to be base64 encoded.
I doubt that what you're passing to image is still base64-encoded as otherwise the decoder should complain much sooner.
Chehui Chou
@deadshot465_gitlab
Ok. I will try to decode it first and see if it fixes
Thanks
Martin Tomasi
@GyrosOfWar
hi there, i was wondering if there's an elegant way to convert a DynamicImage into an image buffer containing Rgb<f32> (instead of whatever the original representation was)? If there is one, I haven't been able to find it so far
HeroicKatora
@HeroicKatora
@GyrosOfWar I'm afraid there is no elegant way, that is a single statement or so for the conversion. In any case I would DynamicImage::into_rgb()and go from there. Then probably convert it into the vec container and map each pixel.
Martin Tomasi
@GyrosOfWar
alright, yeah, i was sort of expecting that
Raphael
@ruffson
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?
HeroicKatora
@HeroicKatora
I didn't get around to review it fully, no.
My first impression is that it's a breaking change and seems tacked on with free methods and little interaction.
Maybe just add the missing Tags first
Raphael
@ruffson
Ok. It is not a breaking change. Non-GeoTIff images can be opened fine. I'll wait for a review, no rush. Thank you!
HeroicKatora
@HeroicKatora
It's not? Hm, maybe I did misread the code on a first glance :)
Raphael
@ruffson
Haha maybe.
Raphael
@ruffson
Also I think I spotted a regression in image-tiff. Until a few weeks ago, I was able to load normal sized TIFF images with over 300MiB after I increased the buffer limits. Now, I get a InconsistentSizesEncountered error in expand_strip() because for whatever reason at some point a strip that was read is bigger than all the others. I don't really have time to do much debugging, I just observed that the new of LZWDecoder reads more bytes than a strip contains at some point, first few runs are fine. Has anyone any idea what could've changed that caused this?