Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 20 07:22
    linrio opened #558
  • Nov 11 09:24
    ScriptTiger commented #549
  • Nov 10 17:26
    ScriptTiger commented #549
  • Jul 10 14:29
    dclunie commented #557
  • Jul 10 14:23

    jonsneyers on master

    Notice for JPEG XL Merge pull request #554 from sa… (compare)

  • Jul 10 14:23
    jonsneyers closed #554
  • Jul 10 14:23
    jonsneyers commented #554
  • Jul 10 14:21
    jonsneyers commented #557
  • May 29 21:05
    dclunie commented #557
  • May 29 20:53
    bjorn3 commented #557
  • May 29 20:48
    bjorn3 commented #557
  • May 29 20:47
    dclunie opened #557
  • May 23 13:06
    bjorn3 commented #556
  • May 23 13:04
    yuffon commented #556
  • May 23 13:04
    yuffon commented #556
  • May 23 11:09
    bjorn3 commented #556
  • May 23 09:42
    yuffon opened #556
  • Apr 29 11:52
    bjorn3 commented #555
  • Apr 29 11:47
    QLaHPD commented #555
  • Apr 29 09:05
    bjorn3 commented #555
The Jared Wilcurt
@TheJaredWilcurt
@TobiasKnauss I would be curious if the flif.exe is faster or slower than your DLL approach. or if there is no noticable difference in performance
Pieter Wuille
@sipa
there shouldn't be any difference if the exe and dll are compiled with similar optimizations
The Jared Wilcurt
@TheJaredWilcurt
:+1:
Pieter Wuille
@sipa
the overhead of calling an exe is probably negligable compared to the actual compression algorithm
Jon Sneyers
@jonsneyers
yes, it is
Jon Sneyers
@jonsneyers
by the way @TobiasKnauss, about "3) the flif_import_image_RGBA() swaps R and B. " – this is probably because on Windows, pixel buffers are usually BGR instead of RGB (it's the old little-endian vs big-endian thing).
TobiasKnauss
@TobiasKnauss
@jonsneyers Yes, on Windows it's BGRA (https://stackoverflow.com/a/8104553). Is it different on other systems? Is there a way to make FLIF "compatible" to the Windows byte order? This would speed up the copying of image data a lot prior to the actual encoding.
@TheJaredWilcurt : I compiled the flif library using the "dl_make_vs.bat"
@sipa "the overhead of calling an exe" should be some tens of milliseconds, which is nothing even on my medium-sized images that take 5 seconds. It would only be relevant at encoding of tiny PNG images that take about 100ms.
Tests with different values of interlace and learn-repeat finished. Results on various kinds of image data are too long to post it here, but I can send it to anybody who's interested.
Summary for the 1280x960x8bpp:
image.bmp    1280x960xFormat8bppIndexed : image=1228800 bytes, sourcefile=1229878 bytes, sourcefile/image=100,087728%
Interlaced  = 1, LearnRepeat = 3, encoding: 00:00:04.4502546, file=430089 bytes, file/image=35,000732%  file/sourcefile=34,970%
Interlaced  = 0, LearnRepeat = 3, encoding: 00:00:04.2122409, file=433344 bytes, file/image=35,265625%  file/sourcefile=35,235%
Interlaced  = 0, LearnRepeat = 1, encoding: 00:00:01.5380880, file=435377 bytes, file/image=35,431071%  file/sourcefile=35,400%
TobiasKnauss
@TobiasKnauss
I just tested with Interladed=0 and LearnRepeat=0, and... wow! This is fast now! And it's still quite small:
Interlaced  = 0, LearnRepeat = 0, encoding: 00:00:00.1940111,  file=477835  bytes, file/image=38,886312%  file/sourcefile=38,852%
Zoey Riordan
@ZoeyR
IS the spec for JPEG XL released already or is that a WIP too?
ika4
@ika4
I'm having some trouble getting good results out of FLIF. I have a set of BMP images at 128x128, so every image is 12kb. If I convert these images to WEBP they all compress and have filesizes lower than 12kb. But if I convert them to FLIF they are all larger than 12kb. On bigger files FLIF always seems to beat WEBP but on this imageset FLIF is doing worse than the uncompressed BMP files.
with my WEBP conversion I use -z 9 (highest lossy compression level) and with FLIF I use -E=100
ika4
@ika4
using more iterations and stripping some data seems to help , but now it's kind of a toss-up between the two, certain images are doing better than others
The Jared Wilcurt
@TheJaredWilcurt
@ika4 I think if you turn of interlacing it may help for smaller dimensions. Though I believe be default interlacing is disabled on tiny images. but I'm not sure how "tiny" is defined in the spec
Jon Sneyers
@jonsneyers
JPEG XL draft spec is here: https://arxiv.org/abs/1908.03565
Pieter Wuille
@sipa
5 different entropy coders?
Jon Sneyers
@jonsneyers
@ika4 you can try -N -B
Zoey Riordan
@ZoeyR
how close is this to the final spec do you know?
Jon Sneyers
@jonsneyers
@dgriffen that will depend on ISO ballot comments and core experiment results
but probably there will still be quite some difference
Zoey Riordan
@ZoeyR
fair enough. It would probably be a waste of time for me to write a rust implementation based on the draft then I'm guessing?
Pieter Wuille
@sipa
oh, no 6
brotli, ANS, sANS, BAC, huffman, ABRAC
Jon Sneyers
@jonsneyers
I personally would like to get rid of some entropy coders (I think 3 different ones are needed, but no more), the Brunsli mode (dedicated jpeg recompression; this can also be done in the normal kPasses mode), and the dedicated lossless mode
basically everything after page 135 should be removed in my opinion, but I'm having a hard time convincing the Google team :)
I want to keep Brotli, ANS and ABRAC.
Zoey Riordan
@ZoeyR
well at the very least I'll reserve the rust crate name so no one else poaches it
Jon Sneyers
@jonsneyers
(MABEGABRAC is basically the same thing as MANIAC, by the way)
The Jared Wilcurt
@TheJaredWilcurt
:tada:
This is good progress
mo0nsniper
@mo0nsniper
How is the compression from PIK used in Jpeg XL? In FUIF I understand that the same algorithm is used both for Loossless and Lossy compression.
Jon Sneyers
@jonsneyers
JPEG XL (at least the current version of the spec) has 4 modes, which basically correspond to pik-lossy, pik-lossless, fuif, brunsli
Andrew Kvapil
@viluon
Hi, pardon the question, but is FLIF dead?
The Jared Wilcurt
@TheJaredWilcurt
@viluon FLIF is a filetype. There are tools to convert from other file types to it, and tools to view those files. It is open source so anyone can contribute to it to improve it, or create their own encoding/decoding tools based on the spec and existing source code.
Active development efforts seem to have moved from it to FUIF and JPEG XL, which will have FUIF essentially built in, and FUIF has many ideas that are taken from FLIF
aeriksen
@aeriksen
UGUI_FLIF doesn't seem to do anything. Running on MacOS
aeriksen
@aeriksen
It doesn't convert
Andrew Kvapil
@viluon
@TheJaredWilcurt yes, it is these active development efforts that I was talking about.
TobiasKnauss
@TobiasKnauss
any news regarding the standardization of JPEG XL and a demo implementation?
cathugger
@cathugger
The Jared Wilcurt
@TheJaredWilcurt
Hype
Neil Sandage anagram"Nile_EdenAgs" Hamilton+Sandys
@NEdenags_twitter
I want to replace JPEG, since FLIF is better than JPEG, how soon Fuji Camera, and Replace Motion JPEG aka MPEG video? ~ any guess about h.264 h.265 or VC1 or my favorite Matroska
The Jared Wilcurt
@TheJaredWilcurt
@NEdenags_twitter All of the good ideas from FLIF and FUIF are being added into JPEG-XL.
Jon Sneyers
@jonsneyers
JPEG XL will have slightly better lossless compression than FLIF, and it will decode about twice as fast on single-core and be parallelizable. Lossless encode is still rather slow atm, we still need to improve that.
We took MANIAC from FLIF, turned it into MA-ANS, and made it significantly more powerful: it also does lz77-style references, it has a predictor and multiplier per MA context, and more predictors and MA properties.
Jon Sneyers
@jonsneyers
The FLIF/FUIF-based mode in JPEG XL is called "Modular mode", and it is used for various things: lossless mode, the DC (1:8 image) in lossy mode, alpha and other extra channels, and all kinds of internal auxiliary images in lossy mode (the adaptive quantization map, block type selection map, chroma from luma coefficients, custom quantization tables, filter strength maps).
Version 0.1 was released last week. Plan is to reach 0.2 soon (bw-compatible bitstream), then 0.3 (stable libjxl api) by January, and hopefully we can get in the next Android and in Chrome somewhere in 2021.
The Jared Wilcurt
@TheJaredWilcurt
omg :heart: :heart: :heart: :heart: :heart: :heart:
this is extremely exciting