Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 01 09:34
    ziemek99 commented #551
  • Nov 21 15:04
    ziemek99 closed #475
  • Nov 21 15:04
    ziemek99 commented #475
  • Nov 21 15:03
    ziemek99 labeled #475
  • Nov 21 15:03
    ziemek99 labeled #475
  • Nov 21 14:07

    ziemek99 on v0.4

    (compare)

  • Nov 21 14:06

    ziemek99 on master

    v0.4 release (compare)

  • Nov 21 14:05
    ziemek99 commented #551
  • Nov 21 13:58
    ziemek99 commented #420
  • Nov 21 13:56
    ziemek99 labeled #420
  • Nov 21 13:56
    ziemek99 closed #350
  • Nov 21 13:56
    ziemek99 commented #350
  • Nov 21 13:56
    ziemek99 labeled #350
  • Nov 21 13:21
    ziemek99 added as member
  • Sep 29 00:39
    QLaHPD closed #555
  • 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
Stephan Vedder
@feliwir
it doesn’t mention fuif though
Stephan Vedder
@feliwir
it doesn’t go into details at all
Simanto Rahman
@Simanto_Rahman_twitter
I have been trying to get ImageSharp to include FLIF to their supported formats. Only problem is the licensing. They are using Apache2.0 and FLIF encoder is under GPLv3 I believe. As soon as the community finishes the encoder for production level use, other projects can start putting it into their framworks.
I myself am unable to utilize FLIF server side due to the same reason.
Stephan Vedder
@feliwir
Just use MIT license for FLIF
problem solved
GPL sucks😂
The Jared Wilcurt
@TheJaredWilcurt
I'm using MIT for node-flif however it ships with a copy of a built flif.exe and also uses flif-wasm which uses ISC. So I'm not sure how all that works
Zoey Riordan
@ZoeyR
Sadly the encoding-side of flif doesn't really have a specification on how the maniac tree is trained or I would be able to work on an MIT/Apache2.0 licensed encoder.
Stephan Vedder
@feliwir
I‘d totally contribute aswell to a C/C++ encoder
But i won’t contribute to GPL stuff
Zoey Riordan
@ZoeyR
Unfortunately my project is Rust so you'd be at a bit of a disadvantage.
Simanto Rahman
@Simanto_Rahman_twitter
Im still enthusiastic about managed implementations. I talked to one of the main contributors of ImageSharp and their only hiccup was the licensing. They use apache 2.0 for Image Sharp and the encoder is under full power of GNU Public License (which is definitely understandable). I personally am trying to implement the entire FLIF basics into ImageSharp just to play around with it on my personal (non-commercial) projects.
Zoey Riordan
@ZoeyR
@Simanto_Rahman_twitter yeah the licensing gets a bit interesting. If there was a formal spec for the encoding process then there wouldn't be much of an issue since you could just implement according to the spec and avoid using any of the existing code, which should allow you to license it however you want. However, since there is no spec, the code itself is the documentation so its much more of a gray area.
Simanto Rahman
@Simanto_Rahman_twitter
Well once the development process finishes, a formal Spec would do the trick wont it?
Zoey Riordan
@ZoeyR
right, although it would be nice if there was a rough spec right now for encoding, there already is for decoding.
Pieter Wuille
@sipa
generally specifications define the format, not so much the procedure for creating
because implementers are free to use whatever algorithm, as long as the result is a valid file
Zoey Riordan
@ZoeyR
I suppose, although training the maniac tree seems like a big part of the benefit of FLIF.
Pieter Wuille
@sipa
right... but also probably the place where the biggest improvements can be found
Simanto Rahman
@Simanto_Rahman_twitter
Btw the FLIFSharp link in readme is broken and the project no longer exists
The Jared Wilcurt
@TheJaredWilcurt
made a PR to remove it
Simanto Rahman
@Simanto_Rahman_twitter
Great I'm waiting for the project to reach maturity and updated license to implement them in a library like ImageSharp which should be neat because it will be fully managed and pretty close to the native speed through the optimization effort of ImageSharp's internal mechanism.
Simanto Rahman
@Simanto_Rahman_twitter
#519 still seems to be an open issue. Are we still open on that discussion?
alan2here
@alan2here
Hello
alan2here
@alan2here
Is it just me on at the moment?
matrixbot
@matrixbot
exothermic Hey everyone
The Jared Wilcurt
@TheJaredWilcurt
yo
alan2here
@alan2here
yo :)
Oblomov
@Oblomov
A quick question: is there a technical description of how animation is implemented in FLIF written somewhere?
matrixbot
@matrixbot
exothermic Is FLIF not going anywhere still?
matrixbot
@matrixbot
hrjet I am right now at some cross-roads in my career and can re-start my contributions to FLIF. But I need some motivation. Are there significant users / deployments of FLIF?
The Jared Wilcurt
@TheJaredWilcurt
I think the format needs more attention and support before better adoption will occur
matrixbot
@matrixbot

hrjet Typical catch 22, eh?

I see a number of security issues blocking the inclusion in Debian, which would have been a great boost for adoption. But for people already aware of FLIF, my hunch is that security is not a blocker.

The Jared Wilcurt
@TheJaredWilcurt
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
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