Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 07:48
    johannesvollmer commented #1404
  • 07:40
    johannesvollmer commented #1404
  • 07:40
    johannesvollmer commented #1404
  • 07:15
    tristanphease synchronize #1624
  • Nov 28 03:51
    tristanphease synchronize #1624
  • Nov 27 14:34
    simon-frankau closed #1627
  • Nov 27 14:34
    simon-frankau commented #1627
  • Nov 27 11:18
    HeroicKatora commented #1627
  • Nov 27 11:14
    simon-frankau opened #1628
  • Nov 27 11:10
    simon-frankau opened #1627
  • Nov 27 10:28
    johannesvollmer closed #1622
  • Nov 27 10:27
    johannesvollmer commented #1622
  • Nov 27 10:27
    johannesvollmer commented #1626
  • Nov 27 09:37

    HeroicKatora on master

    update exr version to 1.4.0 Merge branch 'master' into upda… Merge pull request #1626 from j… (compare)

  • Nov 27 09:37
    HeroicKatora closed #1626
  • Nov 27 07:30
    shikharvashistha commented #1619
  • Nov 27 07:26
    shikharvashistha commented #1619
  • Nov 27 07:26
    shikharvashistha commented #1619
  • Nov 27 07:26
    shikharvashistha commented #1619
  • Nov 27 07:24
    shikharvashistha synchronize #1619
5225225
@r522:matrix.org
[m]
I think other limits would be tripped long before that limit
but I might as well check that limit too
or make a new limit for "maximum number of IFDs"
HeroicKatora
@heroic_katora:matrix.org
[m]
I'm pretty sure that go's image-tiff trips over this as well :D
https://github.com/chai2010/tiff
At least this one does
5225225
@r522:matrix.org
[m]

nice

what error should it throw if we see a repeat?

make a new variant to FormatError like IfdOffsetRepeated?

also is there a reason we're not using #[non_exhaustive] on the enums other than "it wasn't around when the enums were written"?

I tried running clippy on the codebase and like half the warnings are about manual non_exhaustive

HeroicKatora
@heroic_katora:matrix.org
[m]
No, there is no other reason than compatibility for not using non_exhaustive
I'd say that a new variant is good, and I like the idea of having maximum IFDs as a strategy as well.
Hm, actually a nicer strategy to avoid memory exhaustion as well..
HeroicKatora
@heroic_katora:matrix.org
[m]
5225225: I suppose a simple strategy would be to use a limit in the fuzzing loop.
Most issues should show up with a limited number of ifd's and we might generally expect the runtime environment to somewhat limit the number of iterated ifds. I mean, we don't internally iterate over the ifds in a loop, it's the loop around next_image that does
That is, changing the loop from while to for _ in 0..128 or similar
Grant Handy
@grantshandy
Hi I'm trying to make a utility that changes the perspective of an image.
It'll take the corners of a quadrilateral and then change the contents of the quadrilateral into a rectangle by manipulating the perspective. Does image have this functionality? Are there other crates that do this? Or should I try to do the math myself.
HeroicKatora
@heroic_katora:matrix.org
[m]
Grant Handy
@grantshandy
Thanks!
I'll take a look at it
Grant Handy
@grantshandy
I'm back
Has anyone ran into any issues with image-rs and webassembly?
Hey I'm trying to upload an image to my site then feed it to webassembly, is this the right way to do it? I'm manipulating the image with the image crate by the way.
#[wasm_bindgen]
pub fn resolution(value: &[u8]) -> String {
    log(&format!("bytes: {}", &value.len()));

    let image = ImageReader::new(Cursor::new(value));

    let (x, y) = match image.into_dimensions() {
        Ok(data) => data,
        Err(e) => {
            let e = format!("image-rs error: {}", e);
            error(&e);
            return e;
        },
    };

    return format!("image-rs: {}, {}", x, y);
}
<input type='file' id='button'>
<p id="resolution"></p>
        var button = document.getElementById('button');

        button.addEventListener('change', (event) => {
          let file = event.target.files[0];
          const reader = new FileReader();
          reader.readAsArrayBuffer(file);

          reader.onloadend = function() {
            let x = reader.result;
            console.log(x);

            let uint8view = new Uint8Array(x);
            let res = resolution(uint8view);
            document.getElementById('resolution').innerHTML = res;
          }
        });
This compiles fine but it isn't working, this is the error I'm getting
ArrayBuffer(20525)
wasm.js:93 bytes: 20525
wasm.js:96 image-rs error: The image format could not be determined
So it's getting the correct number of bytes but for some reason the image crate isn't getting it right?
HeroicKatora
@heroic_katora:matrix.org
[m]
It's not always possible to determine the format from the contents alone.
You to explicitly choose one option on ImageReader :
  • ImageReader::with_guessed_format
  • ImageReader::set_format (e.g. combined with ImageFormat::from_extension)
Reader::open automatically does the second one for you to mimick the behavior of image::open.
Grant Handy
@grantshandy
Ah okay thank you
I fixed it with "with_guessed_format". Thank you so much.
Marek Miettinen
@marikka
Hi! Do you know of any more usage examples beyond what's in https://github.com/image-rs/image/tree/master/examples ? I'm interested in mapping grayscale images to grayscale images of the same dimensions, so I'm doing something along the lines of for (input_pixel, output_pixel) in input.pixels().zip(output.pixels_mut()) and then accessing the u16 in the Luma<u16> with input_pixel.0[0]. I'm wondering if there's a better way?
Marek Miettinen
@marikka
Another question: Are there functions or a related library that could be used for combining image "layers" of identical dimensions. Either blend two or more grayscale images together, or create an RGB image from three separate grayscale images. I would assume this is very common and exists somewhere, but I can't seem to find it.
poly000
@poly000
8435e5dde71190ef9592028fcc1b9d16fdfa6071.gif
How should I make the GIF generated by GIFEncoder separate each frame instead of overlaying it every time?
3 replies
Chris
@caemor
Hi! Is there an easy way to make an png image square (add transparent background where needed) and the resize it to a smaller size? (e.g. an 2556x1234 image should be made to a square 2556x2556 and then scaled down to 400x400)
I only found resize(_*) which does the second step, but I would also need some centered canvas size change function.
1 reply
poly000
@poly000
@caemor create a new ImageBuffer in size 2556x2556 and overlay previous one on?
Chris
@caemor
Thanks got it working with the overlay.
5225225
@r522:matrix.org
[m]

hey sorry for basically abandoning the fuzz fixes pull request for... far too long

anyways, i implemented the IFD cycle checking

as implemented, read_header and read_ifd have a new error state where if we ever see an IFD offset twice, we return it.

I've not set any form of limit on the size of the hashmap, so it can grow unbounded, but every entry we add must actually exist in the file (as in, a file can't add thousands of entries to the hashmap while only being hundreds of bytes long, unlike OOMs where we allocate a buffer of a specific size given by the file), so this might be fine?

cc HeroicKatora

one open question is if we should be using loop or for _ in 0..128 in the fuzzer

i think you said earlier to make it limited, but I'd argue that clients probably will be reading off images as an iterator without any form of limit, so if we constantly return valid images, they'll get stuck in loops

or in other words, an infinite loop of valid images is our bug

1 reply
the fuzzer seems to not run into infinite loops even with loop, and at least with the default settings of 4KB max input size, seems to not fail at all anymore
5225225
@r522:matrix.org
[m]
also, CI tests on 1.34.2, which fails on a lot of our dependencies, so that'll probably need to be bumped
1 reply
a lot being 2 that i've seen (itertools and flate2)
image-rs/image-tiff#141 is the PR, for reference
HeroicKatora
@heroic_katora:matrix.org
[m]
The largest downside I can see from that is that, of course, there might be errors beyond the number, whichever we choose.
5225225
@r522:matrix.org
[m]

IMO the limit there that they have should only be for limiting the amount of real images they care about

we should have a finite number of images in a valid file, if there's an infinite amount the file is invalid (and we report an error in that case)

or in other words, if we take input.len() limited number of images, and return once there's no more images / there's an error, we should be free to insert a panic at the end of that loop, since it's impossible (to my knowledge) to validly encode more than 1 image per byte
i'm fine with changing the fuzzer to limit the count again, I just feel that we shouldn't be saying that infinite loops when taking images is not a bug in image-tiff
1 reply
5225225
@r522:matrix.org
[m]

that works

doesn't protect against internal infinite loops (and ultimately, an infinite loop and a panic is the same, just infinite loops take longer to trigger the timeout)

which defaults to 1200 seconds but I generally set to a few seconds
1 reply

uhhh I don't think libfuzzer has a config file

I could make a shell script that calls cargo +nightly fuzz decode_image -- -timeout=5 or whatever

HeroicKatora
@heroic_katora:matrix.org
[m]
Say we treat all decoding throughput of <1kB/s as a bug. Ah, hm, then it'd need to be dynamic anyways for that goal.
Okay, anyways, shell script sounds good. I'd mention it in the readme as well.
5225225
@r522:matrix.org
[m]
we could check the current time, decode the image, then check the time again?
might add some overhead to each fuzzing run though