Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:21
    HeroicKatora edited #1433
  • 08:21
    HeroicKatora closed #1628
  • 08:21
    HeroicKatora commented #1620
  • 08:21
    HeroicKatora commented #1620
  • 08:20
    HeroicKatora closed #1624
  • 08:19

    HeroicKatora on master

    Refactors and adding lossless b… Added stuff to deal with transf… Fixed bit reader, added lots of… and 18 more (compare)

  • 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)

HeroicKatora
@heroic_katora:matrix.org
[m]
So, texel = indivisible unit of the format, pixel = indivisible unit of your display
More or less
Raphael
@ruffson
Ah okay sounds much more sane.
Owen Walpole
@owenthewizard
Hey guys, is there a way to convert an image to another non-const ColorType? Something like this:
let color = image.color();
let img = image.to_rgba8();
// do stuff with RGBA8 image...
let img = img.into::<color>();
HeroicKatora
@heroic_katora:matrix.org
[m]

I'm not entirely sure if I understand exactly what you intend to your code to do. Since Rust does not have dependent typing (types that depend on values), I don't think that would work. You can't use color in the type context of a generic parameter. So, no, there is no such way where color can influence the type of img on line 4. However it might be feasible to have the last line produce a DynamicImage with the previous variant again, as in:

let img = DynamicImage::from(img).convert_into(color);

That's not implemented either but, theoretically, something like this could be possible in Rust.

Moggers
@Moggers
hey hey, https://en.wikipedia.org/wiki/Silicon_Graphics_Image I've found myself in the unfortunate situation of needing to convert SGI images to jpeg for thumbnails, I don't think there's currently support for this, is anyone familiar with the format already?
fintelia
@fintelia:matrix.org
[m]
Not familiar with the format, but based on http://paulbourke.net/dataformats/sgirgb/sgiversion.html, it looks like it wouldn't be too difficult to write your own parser. Once you have the raw RGB data loaded, it shouldn't be much of an issue to use image to write it out as a jpeg
Moggers
@Moggers
oh man I was hoping someone else would do the work for me, I'll see if I can implement it and then open a PR
5225225
@r522:matrix.org
[m]

Hey, I'm working on fixing the issues found by the fuzzer for image-tiff, and am running into an infinite loop when doing

loop {
    decoder.next_image().unwrap();
    assert!(decoder.more_images());
}

using

pub fn goto_offset_u64(&mut self, offset: u64) -> io::Result<()> {
    dbg!(offset);
    self.reader.seek(io::SeekFrom::Start(offset)).map(|_| ())
}

indicates that offset is always 8, so it's re-reading the same ifd every time.

From reading the format, it seems like it has a next_ifd field, so it's basically a linked list.

My question is how should we handle this? Have a HashSet<u64> or something in the decoder, and bail out if we try to go to an ifd that we've seen before? Or mandate that the next ifd offset must be at least 1 byte ahead of the current one, so we'll always be making progress in the file?

pinging HeroicKatora

HeroicKatora
@heroic_katora:matrix.org
[m]
5225225: Huh, interesting failure mode. I would go for a HashSet because the standard does not forbid offsets that go backwards
By the way, I wonder how other decoders react
5225225
@r522:matrix.org
[m]

it'd be interesting to see if some decoders reject offsets that go backwards

yeah, i'll go with the hashset of offsets (and maybe respect the intermediate buffer limit for the size of it)

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