Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    John Cupitt
    @jcupitt
    Yes, I'm sad too, I liked jxl much better than avif.
    avif encode has become quite a bit quicker in the last 12 months, which is good.
    Kleis Auke Wolthuizen
    @kleisauke
    Removing libjxl from libvips OSS-Fuzz test environment is not a issue for me.
    I looked at those OSS Fuzz reports a few days ago, and was unable to reproduce them without sanitizers, which is odd. vipsheader reported jxlload for them.
    Note that some OSS-Fuzz issues are duplicated between reports, since we use vips_image_new_from_buffer() on each fuzzer.
    This only seem to happen when OSS-Fuzz is unable to provide a proper stack trace (AFAIK, OSS-Fuzz removes duplicates based on this).
    8 replies
    We might consider using the loader that matches the saver, so for example jpegsave_buffer_fuzzer uses vips_jpegload_buffer(), and adding an additional loader fuzzer that uses vips_image_new_from_buffer() and doing vips_avg() on that. This ensures that we get at most 1 duplicate.
    Kleis Auke Wolthuizen
    @kleisauke
    John Cupitt
    @jcupitt
    hooray! nice!
    ... tab completion is getting better:
    $ vips relational_const ~/pics/k2.jpg x.v less<TAB>
    less    lesseq
    John Cupitt
    @jcupitt
    if JXL is going, perhaps we should try to improve our AVIF support? maybe a load/save pair built directly on libavif or equivalent?
    things like HDR and animations are probably going to be easier to support well without libheif interposing
    Kleis Auke Wolthuizen
    @kleisauke
    PSA: images.weserv.nl is currently being throttled by Cloudflare, wsrv.nl is not affected - see: weserv/images#360
    heifload/heifsave variant on libavif sounds good to me (or perhaps it should be called avifload/avifsave?).
    John Cupitt
    @jcupitt
    yes, I think avifload/save, perhaps at a higher priority than heifload/save
    Kleis Auke Wolthuizen
    @kleisauke
    It looks like some distros still doesn't include the latest version (v1.0.2) of highway, see e.g. https://repology.org/project/highway-simd-library/versions.
    So, I thinking about deferring the SIMD integration w/ highway to libvips 8.15. This also gives us some time to benchmark and test this correctly (specifically morph, reduceh, and the perf regression noted in https://github.com/libvips/libvips/discussions/2757 ).
    https://github.com/libvips/libvips/compare/master...kleisauke:libvips:simd-highway
    Note that this implementation currently only works for targets with fixed-size vectors (so ARM SVE[2] and RISC-V V still uses the C-paths), see e.g. commit kleisauke/libvips@140f05f. Although, liborc also does not support 'scalable' vectors (size unknown at compile time).
    I might consider still supporting liborc, and preferring the highway implementation if available (just as we do with spng and libpng).
    John Cupitt
    @jcupitt
    ok, sounds reasonable
    .... there's a new php-vips with some php-ffi memory leaks fixed
    php-ffi is surprisingly leaky, unfortunately :(
    Kleis Auke Wolthuizen
    @kleisauke
    I was wondering whether libvips 8.14 will be released around Christmas, or if we intent to ship it in early 2023? (There's no due date on the 8.14 milestone).
    (since I'd like to inform Highway's maintainer of my intention to integrate that into libvips 8.15)
    John Cupitt
    @jcupitt
    oh, no idea!
    I was thinking of december some time, for a six month cycle
    perhaps we should feature-freeze in the next couple of days, then do a week or so of testing and stabilization
    any thoughts from anyone?
    also: it looks like I have another job, this time working on openslide (!!), so I'll probably have less free time from december
    would someone else like to take over libvips for the 8.15 cycle?
    Kleis Auke Wolthuizen
    @kleisauke
    Shipping around December and introducing a feature freeze sounds good to me.
    Congrats on your new job! :tada:
    I'll see if I can make a PR for the remaining openslide patches - libvips/build-win64-mxe#48
    Kleis Auke Wolthuizen
    @kleisauke
    I may (or perhaps in cooperation with someone else) be able to take over the 8.15 cycle if no one else wants to.
    (still have plenty of free time left as a student, I wanted to begin graduate on Nov. 7, but the graduation committee rejected the company where I wanted to start.. :sweat_smile:)
    Kleis Auke Wolthuizen
    @kleisauke
    ... informed the Highway maintainer in comment https://github.com/google/highway/pull/1019#issuecomment-1322482024.
    John Cupitt
    @jcupitt
    great!
    OK, let's merge the few outstanding PRs over the next week, then aim to feature freeze next weekend and issue an alpha (as long as nothing terrible is found etc.)
    ok, the 8.15 job is yours! I'd be delighted to hand over to you, if you have the time
    thanks very much!
    I'm amazed graduation committees can reject companies ... why is it their concern where you work?
    Kleis Auke Wolthuizen
    @kleisauke
    They were concerned about supervision and felt the graduation assignment was not complex enough. Anyway, the next start moment is in the third period (January 30; you can start twice in each semester), so hopefully I'll find another company for a 9-month(!) graduate internship (I'll probably post something on LinkedIn soon).
    Kleis Auke Wolthuizen
    @kleisauke
    ... the same university also thought I could finish wasm-vips in less than 2 weeks(!) arguing that "you can easily compile everything to WebAssembly".. As a result of that, and other things that went wrong at our university, I had little motivation left to finish it.
    Kleis Auke Wolthuizen
    @kleisauke
    For reference, you can create a self contained release tarball in Meson by doing:
    $ meson setup release_build -Ddoxygen=true -Dgtk_doc=true -Dvapi=true
    $ meson compile -Crelease_build
    $ meson dist -Crelease_build
    $ ls release_build/meson-dist
    vips-8.14.0.tar.xz  vips-8.14.0.tar.xz.sha256sum
    
    # alternatively, to produce vips-8.14.0.tar.gz instead
    $ meson dist -Crelease_build --formats gztar
    FWIW, I'll email Remi this week in advance with a new patch for the vips spec file that moves the build to Meson (he was a bit reluctant last time I did this - libvips/libvips#2879).
    1 reply
    Kirk Martinez
    @kmartinez
    New job John? new challenges and programming fun no doubt! I finally got 12 core adm zen4 thing running (post covid post flu!) and it now tops the old-school benchmark!) more impressive is the meson full build time! I haven't seen evidence of avx-512 instructions yet but this cpu actually uses avx-256 so maybe the compiler realiases that

    m@ubuntu22:~/vips-8.13.3/build$ time meson compile
    [1/492] Generating libvips/iofuncs/vipsmarshal_c with a custom command
    INFO: Reading ../libvips/iofuncs/vipsmarshal.list...
    [2/492] Generating libvips/iofuncs/vipsmarshal_h with a custom command
    INFO: Reading ../libvips/iofuncs/vipsmarshal.list...
    [492/492] Linking target fuzz/mosaic_fuzzer

    real 0m13.467s
    user 1m8.532s
    sys 1m4.807s

    Kirk Martinez
    @kmartinez
    @kleisauke - sounds more like the issues typical with year-in-industry for the unliky few..
    John Cupitt
    @jcupitt

    New john John?

    Well, an extra job heh. I'm doing two days a week at the moment for a German company, and this is another two days for Harvard. Only for six months though

    wow your 12 core machine is quick! the high clockspeed helps process start I guess
    my threadripper is quicker for libvips compile, but slower on that benchmark
    Kleis Auke Wolthuizen
    @kleisauke
    Good news, Highway has implemented another op with commit google/highway@dda5739 allowing the simd-highway branch to run on 'sizeless' vectors, i.e. ARM SVE[2] and RISC-V. See also the discussion in PR google/highway#1019.
    I'll look into testing/benchmarking SVE on an AWS Graviton3-based instance. RISC-V is currently being tested under QEMU's user space emulation (due to missing support for vector save/restore in the Linux kernel).
    John Cupitt
    @jcupitt
    oh, interesting!
    I must reread your new vector branch, I feel a bit out of touch :(
    2 replies
    heh gdb on ubuntu 22.10 now automatically downloads debug info for all system libraries on demand o.O
    modern features? on MY linux debugger???!!
    Kleis Auke Wolthuizen
    @kleisauke
    Indeed, this has also been available on gdb provided by Fedora for some time, I'm not sure which version this was added.
    BTW, how's the post-mortem debugging experience on Ubuntu nowadays? I recently realized that you can just do coredumpctl debug, which takes me directly into gdb for the last crashed executable. I can directly see the backtrace there.
    No more manually fiddling with these core.* files every time there's a crash or an assertion that starts to fail, which makes debugging much easier. :)
    John Cupitt
    @jcupitt
    oh, I didn't know that, let me try