Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 11:03
    kubouch labeled #1039
  • 11:03
    kubouch opened #1039
  • 02:03
    lazypassion commented #1038
  • 02:01
    lazypassion commented #1038
  • Sep 22 16:40
    fintelia commented #1038
  • Sep 22 15:56
    lazypassion commented #1038
  • Sep 22 03:59
    yvt commented #1038
  • Sep 22 02:34
    Mabinogiysk closed #1027
  • Sep 22 01:52
    fintelia commented #1038
  • Sep 22 01:31
    lazypassion labeled #1038
  • Sep 22 01:31
    lazypassion opened #1038
  • 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
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?
HeroicKatora
@HeroicKatora
@cooperspencer Opening the webp and then saving the resulting DynamicImage as png should work
Andreas Wachter
@cooperspencer
@HeroicKatora thanks. May I ask how exactly? I opened it with:
let img = image::open(&blub);
what do I have to do after that?
sorry for the stupid question, but I am still getting used to Rust...
@HeroicKatora ok found it. I forgot the .unwrap().
The only think I see is that it is in grayscale, but I read that the library doesn't fully support webp.
Is it ok for me to ask if the library will fully support webp in the future?
HeroicKatora
@HeroicKatora
That's already in the works, you can track progress here image-rs/image#952
Some bug leads to wrong colors, that needs to be resolved but it can fully handle the image structure itself.
HeroicKatora
@HeroicKatora
It should also be noted that there is a minor difference between 'full webp' and 'full vp8'. webp is the container format and vp8 is the actual image data encoding (more information on Google's own page. While the PR mentioned works on decoding colors from vp8, the riffcontainer permits other data streams as well (EXIF metadata, animations, ..) and I don't think there is a plan to support these extensions.
That's probably more information than you bargained for ^^
Andreas Wachter
@cooperspencer
no, that information works well for me. Thanks. As a matter of fact, my pictures are vp8. So I will just wait for the new version of image and then I will change my program accordingly. Again thanks for the info and keep up the good work
HeroicKatora
@HeroicKatora
The exact next version (0.22) might not yet include that change but should have the required interface so that it can be added in a 0.22.1, without another SemVer breaking change. Different parts progressing at different speeds :smile:
SnoozeTime
@SnoozeTime
Hi there,
Is there any ongoing effort for this image-rs/image#940 ? If not, I might try to tackle it if you accept PR/provide code review :)
HeroicKatora
@HeroicKatora
A PR would be appreciated, a few requested features simply stall due to limited available time. When ready, request review on the PR and someone should come along. If not, ping me I guess.
And by a few features I mean a large portion of them ^^
SnoozeTime
@SnoozeTime
Great thanks!
SnoozeTime
@SnoozeTime
alright :o , modifying the dynamic image to include 16bits images requires quite a lot of work
HeroicKatora
@HeroicKatora
Yes, unfortunately :|
The best way to start would probably be to explicitely not involve DynamicImage but only expose this directly through the reader.
DynamicImage is a bit of a mess that needs cleanup of its own
SnoozeTime
@SnoozeTime
I see, so I can allow loading the ImageBuffer, Luma<u16> directly via whatever codec loader. Then, when the DynamicImage is cleaned, we can allow loading 16bit grayscale with the nice api
I've successfully loaded and saved PNG grayscale 16-bits, but I need to clean up the mess a bit :D
HeroicKatora
@HeroicKatora
:+1:
Yuki Okushi
@JohnTitor
Hi, are there any plans for the next release of imageproc? imageproc::drawing::draw_text(_mut) doesn't seem to work well with the dependencies image v0.22.1 and imageproc v0.18.0 (image v0.21 or master branch of imageproc works fine). This issue has been fixed in master branch of imageproc, I think.
HeroicKatora
@HeroicKatora
Not yet. imageproc performance is substantially lower if we avoid all the unsafe functions (the GenericImage::unsafe_get_pixel etc) and so we're discussing undoing their deprecation. Kind of unfortunate, it seems we overestimated the replacements and llvm.
:/
Yuki Okushi
@JohnTitor
Oh, okay, thanks!
HeroicKatora
@HeroicKatora
Ugh, Travis build broke on a timeout downloading crates. At least this shows that the notifications work!
Yuki Okushi
@JohnTitor
Hmm, webhooks also picks up my fork repository?
HeroicKatora
@HeroicKatora
It picks up anything that runs on Travis, connected to the repo. So if you have an active PR it will run Travis and should appear here
Not sure why canceled appears after the merge, not a big deal though