Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 22 15:47
    Jacherr opened #1466
  • Apr 21 18:15
    schanur closed #1465
  • Apr 21 18:15
    schanur commented #1465
  • Apr 21 17:14
    aschampion commented #1465
  • Apr 21 17:11
    schanur opened #1465
  • Apr 14 15:14
    fintelia commented #1464
  • Apr 14 14:16
    alexkirsz opened #1464
  • Apr 14 00:56
    CensoredUsername unlabeled #1463
  • Apr 14 00:56
    CensoredUsername labeled #1463
  • Apr 14 00:13
    CensoredUsername opened #1463
  • Apr 12 23:38
    CensoredUsername commented #1060
  • Apr 12 13:43
    HeroicKatora commented #1462
  • Apr 12 13:40
    HeroicKatora edited #1462
  • Apr 12 13:39
    HeroicKatora reopened #1462
  • Apr 12 13:33
    cbrownsey closed #1462
  • Apr 12 13:21
    cbrownsey edited #1462
  • Apr 12 13:14
    cbrownsey opened #1462
  • Apr 10 19:18
    fintelia closed #1354
  • Apr 05 14:06
    HeroicKatora synchronize #1448
  • Apr 05 13:45
    HeroicKatora synchronize #1448
arthmis
@arthmis
I actually took the code and put it into a trait and implemented it for RgbaImage. It performed 15% faster. So that was an unexpected bonus.
Niklas Kunz
@mntns
Hi! I'm also experiencing the regression in image-tiff that @ruffson described on oct. 29. expand_strip() seems to read 0 bytes of the first strip. If the LZW decoder changed for 0.6.0, the first place to get deeper into debugging it would probably the lzw crate?
HeroicKatora
@HeroicKatora
@mntns If you have a reproduction that would be great, yes.
I'm really unsure how the described problem would happen due to a failure of the lzw decoder since the compression of each expand_strip call is independent and does not share decompression state as far as I know. I'd first look at the integration code.
Raphael
@ruffson
Ah yes, its quite bad, many simple geotiff example files cannot be read (any more). I did not have time to dig more into it. Would it help if I provided a tiff image that fails to be parsed by LZWReader::new(...)?
HeroicKatora
@HeroicKatora
If you can upload a failing image to an issue that would help immensely, yes.
Even better if it were one that we can re-distribute as part of the test suite but that is by no means necessary :)
Raphael
@ruffson
Okay, sure, I'll do it later today! :)
Oh while I am here, @HeroicKatora are there any obstacles regarding my geotiff PR?
HeroicKatora
@HeroicKatora
It would be neat if you resolve the conflicting file with a rebase but other than that; Only me missing that this review was still in my backlog ^^
Niklas Kunz
@mntns
@ruffson: Great, if you open an issue, I'll also add my reproduction to it :)
Raphael
@ruffson

It would be neat if you resolve the conflicting file with a rebase but other than that; Only me missing that this review was still in my backlog ^^

Alright, will do!

@ruffson: Great, if you open an issue, I'll also add my reproduction to it :)

Cool, I'll ping you when I did it.

HeroicKatora
@HeroicKatora
Great to hear from you both
Raphael
@ruffson
Oh and another newby question: The Limits struct in the TIFF decoder mod.rs has a private field _non_exhaustive which means I cannot simply create a new struct with Limits{...}, what is the idiomatic way of creating a new Limits struct outside of this module if you want to change e.g. all three default values? Creating a struct with Limits::default() and then changing each field one by one?
HeroicKatora
@HeroicKatora
Yes, that's the idea.
Raphael
@ruffson
Ok thanks
Raphael
@ruffson
Ok here it is @HeroicKatora @mntns image-rs/image-tiff#106
(the image data might take a bit to download because it is on my server with rather bad upload speed at the moment)
HeroicKatora
@HeroicKatora

Interesting. So the examples are all too long?
That's weird but maybe not too bad.. What would happen if we were to truncate?
This may have previously worked incidentally.

while bytes_read < compressed_length && uncompressed.len() < max_uncompressed_length {
    let (len, bytes) = decoder.decode_bytes(&compressed[bytes_read..])?;
    uncompressed.extend_from_slice(bytes);

Since the lzw library decodes symbols word-for-word it's not unlikely that we hit exactly the right length.
The new library decodes fixed size chunks

HeroicKatora
@HeroicKatora
(slight clarification: with examples are too long I mean that the apparent size of uncompressed is larger than max_uncompressed_length)
The Geotiff2 example is also curious since 2570*3 = 7710 so that might be 'corrupt' with the wrong buffer.byte_len?
Raphael
@ruffson

That's weird but maybe not too bad.. What would happen if we were to truncate?

Okay I'll try that later!

Raphael
@ruffson
Sorry I am pretty busy right now, not sure how much time I have for this in the next weeks. What about your example @mntns ?
Niklas Kunz
@mntns
Thanks for the reminder, @ruffson. I just added a large example image with which the error also appears to your GitHub issue. I'll also try looking into it during the upcoming week, but my situation time-wise is similar.
Raphael
@ruffson
Okay, thank you!
Raphael
@ruffson
Thank you for the PR @HeroicKatora I promise that I will spent some time on the weekend to look into this again!
HeroicKatora
@HeroicKatora
I'll patch up the review concerns as well. With regards to color treatment we need to have a separate discussion/implementation in any case.
Danilo Bargen
@dbrgn
Hi, is there a way to convert a GdkPixbuf to an image-rs buffer?

According to the docs: https://developer.gnome.org/gdk-pixbuf/unstable/gdk-pixbuf-The-GdkPixbuf-Structure.html#image-data

Image data in a pixbuf is stored in memory in uncompressed, packed format. Rows in the image are stored top to bottom, and in each row pixels are stored from left to right. There may be padding at the end of a row. The "rowstride" value of a pixbuf, as returned by gdk_pixbuf_get_rowstride(), indicates the number of bytes between rows.

HeroicKatora
@HeroicKatora
Have you found https://docs.rs/image/0.23.12/image/flat/struct.FlatSamples.html?
If it is possible to describe a GdkPixbuf with a SampleLayout then it is possible to copy the pixels out from the buffer
Danilo
@dbrgn:matrix.coredump.ch
[m]
Thanks!
Dakota
@codabrink
How do you create a DynamicImage from an RgbImage? I'd like to write it to a vec in a jpeg format in memory.
The documentation isn't clear on how to handle it
Dakota
@codabrink
Figured it out.. still new to Rust. let img = DynamicImage::ImageRgb8(img);
HeroicKatora
@HeroicKatora
Yes, that was quick. Exactly right :+1:
Danilo
@dbrgn:matrix.coredump.ch
[m]

Hi, I got stuck a bit when trying to implement a combined transformation...

How do I get from a GenericImageView to an ImageBuffer (without any modification) without iterating over rows/cols and calling get_pixel / set_pixel? (That seems really inefficient to me)

Also, is there a good way to combine multiple transforms efficiently without copying each time?

For context, I'm implementing EXIF rotation. This means that depending on the input parameter, we'll do nothing, rotate, flip or rotate + flip.

Rotating by 0 and 180 degrees as well as flipping can be done in-place, so no copying would be necessary. The buffer could be modified in-place.

Rotating by 90 and 270 degrees however always requires a copy, because the image may not be square.

Right now the APIs seem to take &self and return a new ImageBuffer. Do you have a good way to solve this? We could use something like fn rotate(&mut self) -> RotationResult with enum RotationResult { Modified, Copied<ImageBuffer> }, but that seems very ugly from an API point of view.

HeroicKatora
@HeroicKatora
flip and rotate180 have in-place variants that should be more efficient than copying. As far as combining goes, I don't think we have a good solution. I had some vague ideas for an expression-based DSL that might allow this but nothing specific and too complicated for image itself anways.
I'm also fairly sure the GenericImage-based interface is not at all optimized for this work. For example, as you've observed, it isn't efficient to iterate pixels individually but that's pretty much all you can do with the generic interface and what's done internally. Also the layout would—I guess—be more efficient (cache oblivious) if it were a recursive, space-filling curve of macroblocks of pixels instead of row-by-row or col-by-col but that requires an extra conversion of layouts and is somewhat specialized.
There's a lot of room for improvement and specialization that's not in image currently.
If you want to go for serious speed, you could go the route of GL/Vulkan rendering the images instead. Basically offputting the design work on efficient layouts and pipelines to spir-v/graphics card vendors
Danilo
@dbrgn:matrix.coredump.ch
[m]

@HeroicKatora: thanks for the reply! sorry, I somehow missed it.

then I guess I'll do the implementation locally only for now. would be nice if multiple transformations could be combined in the future!

zwerdlds
@zwerdlds
Could someone give a suggestion for moving betwen ImageBuffer and a GTK(-rs) PixBuff? Preferably without copying data or unsafe
HeroicKatora
@heroic_katora:matrix.org
[m]
Hm, have you tried the flat:: module? It's not possible to go between the buffers them without copying since each of them is an owning buffer, with their own allocations strategy. But you can certainly create a view on a GTK buffer which implements GenericImage.
fintelia
@fintelia:matrix.org
[m]
ImageBuffer also deref's into a slice, so it might be as simple as PixBuf::from_bytes((*img_buf).into(), ...)
humbletang
@humbletang:matrix.org
[m]
Hi there! I'm trying to use the image crate to export a texture for a gpu particle system, is there a way to store decimal values in an rgb image? I've been thinking of multiplying by a large constant and then trying to use the Rgb16 type but I wanted to ask around here first if there's a better approach.
1 reply
HeroicKatora
@heroic_katora:matrix.org
[m]
I treat the rgb value as a 3-digit number in base 2**16, basically.
Another approach: you can use grayscale with enough bit-depth as well if you store them as TIFF. The rgb-encoding trick is a hack to fit the bits into the usual formats offered by the GPU's texture buffer interface.
Tomáš Král
@tomaskral:matrix.org
[m]
HeroicKatora: Hi, I've been working on decoding tiled Tiffs. I've generated a few test images using Imagemagick, but I can't figure out a way of actually verifying the pixel checksum I get out of the tests... Is there any program that can calculate that ?
1 reply
Tomáš Král
@tomaskral:matrix.org
[m]
(so far I've just been dumping the pixels into a PGM, just for a rough check)
HeroicKatora
@heroic_katora:matrix.org
[m]
Or, convert to pgm and view that :)
It's just a bit more tedious in bulk