Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 20 09:29
    Travis image-rs/image (master) errored (1493)
  • Sep 20 08:55
    JohnTitor commented #1037
  • Sep 20 08:55

    JohnTitor on master

    Fix the WebP spelling in README Merge pull request #1037 from X… (compare)

  • Sep 20 08:55
    JohnTitor closed #1037
  • Sep 20 05:52
    Travis XVilka/image (patch-1) passed (1)
  • Sep 20 04:58
    XVilka opened #1037
  • Sep 17 22:45
    HeroicKatora commented #1036
  • Sep 17 22:43
    HeroicKatora commented #1036
  • Sep 17 22:17
    fintelia commented #1036
  • Sep 17 16:32
    HeroicKatora commented #1036
  • Sep 16 23:27
    fintelia commented #1036
  • Sep 16 23:19
    fintelia commented #1036
  • Sep 16 22:23
    HeroicKatora commented #1036
  • Sep 16 21:53
    fintelia opened #1036
  • Sep 16 21:32
    Shnatsel commented #878
  • Sep 16 21:19
    fintelia commented #878
  • Sep 16 21:11
    Shnatsel commented #878
  • Sep 16 20:47
    fintelia commented #878
  • Sep 16 20:46
    fintelia commented #878
  • Sep 07 22:09
    Travis image-rs/image (v0.22.2) passed (1489)
HeroicKatora
@HeroicKatora
The problem is that GenericImage::pixels_mut() which confusingly has the same name as ImageBuffer::pixels_mut() but produces a type image::MutPixels...
lazypassion
@lazypassion
Lol yeah I'm aware I could do that, I meant literally not interact with the alpha value and only perform a transformation on the color values.
Lol, well I guess at this point my only argument for this is having an imperative style if there are no performance differences.
HeroicKatora
@HeroicKatora
The compiler will optimize that accordingly. But providing this as a utiliy sounds like a good enhancement as well.
trait Pixel {
    fn apply_without_alpha<F: FnMut(Self::Subpixel) -> Self::SubPixel>(&mut self, f: F) {
        self.apply_with_alpha(f, |x| x)
    }
}
Looks easy enough
Meaning, I'd accept PR if sent :)
lazypassion
@lazypassion
Could there also be the possibility to get an alpha_count associated constant too?
And for sure, I'll go do that. Sounds good to me, thanks!
Will the compiler optimize apply_without_alpha accordingly?
HeroicKatora
@HeroicKatora
I don't think you can default associated constants based on other yet, and it sounds awkward if one could make the numbers conflict. Although of course one could already do it already by returning more channels than ones own slice is long, etc. So maybe a good idea.
And yes, it should optimize that pretty well, and essentially be a noop on the alpha channel in all cases.
lazypassion
@lazypassion
Ok well I'll open up a separate pr for the alpha count
HeroicKatora
@HeroicKatora
I'm not completely sure yet on alpha count but we can gather some more opinions and find out :thumbsup:
Moritz Bischof
@NyxCode_gitlab
Hey, is there a way to resize the buffer of a RgbImage?
In my scenario, I cant predict how big the content I draw on the image is going to be, so I have to increase the size of the image when necessary
Moritz Bischof
@NyxCode_gitlab
hm, i guess i can get the data with image.data and then work with that..
Moritz Bischof
@NyxCode_gitlab
or is there a better way to achive this?
HeroicKatora
@HeroicKatora
Not really. What do you mean by resizing, i.e. in which direction should the image be extended? Assuming you want to preserve the data as the top-left part of the resized image, I'd write it as such:
let original = ...;
let mut new_copy = RgbImage::new(new_x, new_y);
// 0, 0 is the top-left corner of the copied-to region in the new image
new_copy.copy_from(&original, 0, 0);
return new_copy;
HeroicKatora
@HeroicKatora
If the extra copy/allocation becomes a performance concern, feel free to open an issue for tracking the operation
lazypassion
@lazypassion
does the image crate assume images are in srgb space?
HeroicKatora
@HeroicKatora
Yes. At least for the sake of impl Pixel for Rgb<_>
Something we're aware is not optimal and 'tracking' at #786
HeroicKatora
@HeroicKatora
Oh, and #598 and #575. The main issue is that adding the color space information into the type system (i.e. into ImageBuffer) is most often additional overhead while being rarely relevant except for doing computation on the image data but not for representing the values itself. Thus, I'd like to have them outside the GenericImage trait but that somehow means reworking Pixel (which has the concept of operations on value).
One of the problems is that there is no safe way to cast a Vec<_>, the underlying storage of many buffer types, even for transparent wrappers. Hence, https://github.com/image-rs/canvas . The idea being that you can—in the future—imbue a strict, color space aware type onto the buffer content without any actual overhead. Then the buffer needs to care only about representation and color space information can be added by other traits.. But still a fairly long way, I think
HeroicKatora
@HeroicKatora
I would really like to release the changes (encoder and bugfixes) rather soon. Any pending interface changes that should be included?
Stuart Haidon
@Measter
Hi, i'm trying to draw text on a &mut SubImage<RgbaImage> using imageproc's draw_text_mut function, and am getting an error that GenericImage is not implemented for [u8]
I'm using image 0.21.2 and imageproc 0.18.0
Stuart Haidon
@Measter
oh... ok
Turns out, it was a different problem
the function was accepting an &mut SubImage<RgbaImage> but should have been an &mut SubImage<&mut RgbaImage>>
Youka
@Youka
Hi there.
Is it possible to create an image with stride? I get image buffers as Vec<u8> with an offset of several bytes after each row, so i need stride > width * pixel_size.
HeroicKatora
@HeroicKatora
You could try out flat::FlatSamples, maybe that works how you'd like it to?
The idea is to fill the member of that struct with the strides, then call as_view_mut to get a type that implements GenericImage, the central trait for other operations.
Youka
@Youka
Interesting. But a bit low-level. I hoped for a similar way as imgref offers.
HeroicKatora
@HeroicKatora
I'm afraid there is no existing structure in between, just a few helpers to create the strides.
The other image types (ImageBuffer and DynamicImage) expect to have full control over the layout of samples
Youka
@Youka
Would be a nice thing for the future. Many frameservers pass buffers with memory aligned rows for better processing performance, so a few bytes offset are a low price for live rendering benefits.
HeroicKatora
@HeroicKatora
Which imgref are you referring to by the way?
Youka
@Youka
Self-named crate.
HeroicKatora
@HeroicKatora
Ah, ok
Initialization of Img from imgref doesn't seem much more complex than the FlatSamples and SampleLayout structs to me, maybe some more initialization utilities for SampleLayout would already help a lot?
Youka
@Youka
Same goes for formats as BGRX and RGBX, just taking another unused byte to have a 4 byte block per pixel which works well with MMX (SIMD).
Yeah, some convenient functions around flat samples would be great :)
HeroicKatora
@HeroicKatora
Right, SIMD is much easier with stricter alignments.
HeroicKatora
@HeroicKatora
So, if this is what you needed and there are specific helpers for creating a FlatSamples then feel free to open an issue or PR
Youka
@Youka
Alright, put in on my list. On my way now.
Thanks for your responses!
HeroicKatora
@HeroicKatora
No problem, and thank you
zhang-longfei
@zhang-longfei
Is it support android platform.
Andreas Wachter
@cooperspencer
is there a way to convert a webp to a png?