Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 06 14:03
    jonsneyers commented #513
  • Sep 03 08:44
    grinapo commented #513
  • Sep 03 07:52
    jonsneyers commented #549
  • Sep 03 07:43

    jonsneyers on master

    Fix compilation error for MSVC … Merge pull request #526 from Or… (compare)

  • Sep 03 07:43
    jonsneyers closed #526
  • Sep 03 07:43
    jonsneyers commented #526
  • Sep 03 07:43

    jonsneyers on master

    Add related project of libflif-… Merge pull request #528 from dr… (compare)

  • Sep 03 07:43
    jonsneyers closed #528
  • Sep 03 07:43
    jonsneyers commented #528
  • Sep 03 07:40

    jonsneyers on master

    Replace global variables pixel_… Merge pull request #531 from d1… (compare)

  • Sep 03 07:40
    jonsneyers closed #531
  • Sep 03 07:40
    jonsneyers commented #531
  • Sep 03 07:35
    jonsneyers commented #513
  • Sep 03 07:32

    jonsneyers on master

    Fixes for reading malformed/tru… Merge pull request #532 from d1… (compare)

  • Sep 03 07:32
    jonsneyers closed #532
  • Sep 03 07:30

    jonsneyers on master

    Fix for non-power-of-2 maximum … Merge pull request #533 from d1… (compare)

  • Sep 03 07:30
    jonsneyers closed #533
  • Sep 03 07:29

    jonsneyers on master

    add readEOS flag to BlobReader … Merge pull request #538 from md… (compare)

  • Sep 03 07:29
    jonsneyers closed #538
  • Sep 03 07:25

    jonsneyers on master

    Update README.md (compare)

The Jared Wilcurt
@TheJaredWilcurt
though, for those that just need archival lossless images, they likely are already using it, just not in a very public or visible way
matrixbot
@matrixbot

hrjet > typically other factors are of greater concern, like cpu usage for decoding, filesize of JS based decoder, total savings required to justify using a js decoder

Those are characteristics of the implementation just like the security issue. I don't think that would hinder adoption. I wonder whether the spec / algorithm itself doesn't have big appeal (judging by what is visible in the public).

The time required for decoding FLIF, for example, is a hurdle since much of the algorithm is sequential. But again, if there is good momentum, a future version of the spec could be made less sequential, for example, by supporting tiles natively.

matrixbot
@matrixbot
exothermic HEIF vs FLIF vs WebP
Denis Denisov
@denji
HEIF - HEVC(H.265) proprietary codec.
Jon Sneyers
@jonsneyers
There is a reasonably detailed spec available at http://flif.info/spec
Jan-T. Brinkmann
@JTBrinkmann
I think people are usually lazy and just go with the reference implementation without caring to make a surperior 3rd party implementation, especially as the implementation complexity increases. IIRC same happened with e.g. libjpeg.
Jon Sneyers
@jonsneyers
There's libjpeg-turbo, mozjpeg, guetzli, Thomas Richter's libjpeg, and a bunch of proprietary jpeg encoders that are all doing a better job in one way or another than the original libjpeg...
anyway, my focus currently is on FUIF, I hope to get the code released soon
The Jared Wilcurt
@TheJaredWilcurt
will FUIF be listed under FLIF-hub, or in a new space, like FUIF-hub
Jon Sneyers
@jonsneyers
New place. Probably in Cloudinary (https://github.com/Cloudinary) since that's my employer and I am working on it on company time
The Jared Wilcurt
@TheJaredWilcurt
and progressive rendering are ways to deliver aa preview on the screen
aa
The Jared Wilcurt
@TheJaredWilcurt
High Efficiency Image File (HEIC)
and the minimal metadata must render those pixels
and the minimum metdata to render those pixels
matrixbot
@matrixbot
exothermic What about HEIF + H.264 vs FLIF? Surely H.264 is free
matrixbot
@matrixbot
epetitfils Unless I missed an announcement by MPEG LA, H.264 is not free. It requires a licence and in many cases, there are royalties to be paid.
hajj3
@hajj3
you should update flif website to say that irfanview has added support: https://www.irfanview.com/main_history.htm
The Jared Wilcurt
@TheJaredWilcurt
@jonsneyers 2 PR's ready for the site: https://github.com/FLIF-hub/FLIF-hub.github.io/pulls
Ewout ter Hoeven
@EwoutH
Hi
The Jared Wilcurt
@TheJaredWilcurt
to say what?
shitu yadav
@shituyaduvanshi_twitter
hi everyone
shrikant this side..
The Jared Wilcurt
@TheJaredWilcurt
yo
matrixbot
@matrixbot
exothermic FLIF vs FUIF, just great
Boris Yakubchik
@whyboris_twitter
FLIF just blew my mind!
I discovered it when I stumbled across Phew - FLIF Image Viewer for macOS: https://sveinbjorn.org/phew
Perhaps add it to the software page? http://flif.info/software.html :smile:
Boris Yakubchik
@whyboris_twitter
I'm happy to open a PR on GitHub but it doesn't look like there's anyone merging since at least January this year.
Is the project scrapped in favor of FUIF ?
Boris Yakubchik
@whyboris_twitter

It makes sense to put full force behind FUIF then ... since FLIF's 16bit images are a no-go for photographers, and FUIF has, quote:

no inherent limitations in terms of maximum image resolution, bit depth, or number of channels.

Thank you Jon Sneyers for creating FLIF and working on FUIF
https://cloudinary.com/blog/author/jon_sneyers :bow:
:heart:
The Jared Wilcurt
@TheJaredWilcurt
Phew is listed there
The Jared Wilcurt
@TheJaredWilcurt
Boris Yakubchik
@whyboris_twitter
Awesome! Thank you for creating the PR :smile:
Really hope more people hear of the two file formats.
Looks like people at ImageCon2019 just did (May 1st - 2nd) :grin:
From what I can tell by looking at Twitter, JPEG XL is the most-likely-to-succeed new format: it had an open call for proposals and FUIF is one of the two main ones (the other is Pik by Google).
If all goes well, we'll have a synthesis of some of the best ideas from FLIF, FUIF, and Pik all in there :tada:
Jon Sneyers
@jonsneyers
I should check gitter more frequently :)
Yes, I have been working together with the google pik team a lot in the past months
JPEG XL is going to be a combination of FUIF and Pik, we have been working hard to make that work
Jon Sneyers
@jonsneyers
We're following the ISO standardization process, which unfortunately implies that for now we can't put the code in the public spot since that would force potential contributors to open source their contribution and ISO doesn't allow us to force potential contributors to do that. But so far it's just Cloudinary and Google and it likely will stay that way, and we will make our code available, royalty-free and free/open source.
TobiasKnauss
@TobiasKnauss
Hi, I've used FLIF for the first time today. I downloaded the source from GitHub and compiled the DLL using the batch file, then I created a C++/CLI test project in VS 2015 and modified the test.c for my own purpose. Then I converted a set of files to flif. I discovered 3 issues:
1) it works well on reducing file size on PNG and BMP, but the sample JPG that I used was saved as a flif with 4 times the original size.
2) it failed on a 10000x10000 PNG (AccessViolationException)
3) the flif_import_image_RGBA() swaps R and B. Is there any workaround for it instead of manually copying the BitmapData into the flif image using flif_image_write_row_RGBA8() ?
Regards, Tobias
And there's a less-important 4th issue: Encoding a flif from the JPG (which is a 2400x3600 photo) takes about a minute (x86 DLL, i5-CPU). Is it really so slow?
The Jared Wilcurt
@TheJaredWilcurt
@TobiasKnauss
  1. JPG is Lossy, FLIF is Lossless. You can apply a lossy transformation in your conversion to reduce file size, the output will be stored in a lossless FLIF format but will have been degraded in quality from the original. In the CLI you would use -Q70 to set quality to ~70% of original. -Q100is the default and is lossless, all other settings are lossy.
  2. I cannot find any reference in the FLIF spec for a maximum height/width dimension. I think I recall someone saying there is no limit on dimensions. If that is the case then you like just found a bug and should report it with a means to reproduce it.
  3. Perhaps @jonsneyers or @sipa or @hrj will know more about this, I'm unfamiliar with it
  4. The current FLIF source code is one implementation of the FLIF spec. It has not been optimized at all. So it will be very slow in comparison to encoders for more mature specs that have existed for decades and had time to be heavliy optimized (GIF/PNG/JPG/Etc)
TobiasKnauss
@TobiasKnauss
@TheJaredWilcurt
Thank you very much for your reply!
Regarding 1), I created the FLIF directly from the JPG. I just doublechecked on flif.info, it compares the compression ratio of FLIF to other lossless formats, but not to JPG. So I think I should not do that either, since it would be comparing apples with oranges, isn't it?
Regarding 2), I have tested the same file again, this time with "FLIF-GUI 0.3" Filemill.exe. It worked. Now I'm testing again with my own code, it's running now. Don't know why. The exception came directly at the call of the function, not during execution, so I think it will be fine now. It will just take some time: The test with a 4096x4096 took 2:16 min, so I expect the 10000x10000 to take about 10 min or more. The difficulty on the 4096^2 file is, that every pixel is different (it contains all 24bit colors). The 10000^2 file is similar, it contains at least some identical pixels and not all of the 24bit colors.
The Jared Wilcurt
@TheJaredWilcurt
@TobiasKnauss There is a flif.exe file (along with all required Windows files for it to run on any Windows OS) here:
https://github.com/FLIF-hub/node-flif/tree/master/executables/win32
So you can run a pre-built version of the flif CLI, in case you think your build isn't working correctly
TobiasKnauss
@TobiasKnauss
@TheJaredWilcurt I am using the DLL, not the EXE, because I want to build a C# interface around it. But that's a good idea for a doublecheck. Thanks!
The encoding of the 10000^2 file has finished, it took about 11 min. Worked as it is expected to.
Now waiting for replies of other users on the issue 3 with flif_import_image_RGBA().
Regarding 4), I will mostly encode 1280x960x8bpp images from industrial GigE Cameras. It takes 5 seconds for one image (slooow...), so I'll have to use one CPU thread for every image, because I usually get 4 images (or more) every 15 seconds.
The Jared Wilcurt
@TheJaredWilcurt
FLIF is for lossless images. Most of the time if you need photographic images stored, you are better off with a lossy format