Why was JPEG encoding/GIF decoding removed?

[Someguynamedpie]

I relied heavily on the latter in an active project of mine and jpeg encoding was also semi-necessary in another. Seems pointless and I can't find any information on why these were removed.

[zorg]

They replaced a bloat library (DevIl) with more specialized code; for what it's worth, Löve's mostly a game framework, and to be Frank**, lossy encoded images used as textures in games is something no one should ever do*.

That said, many people here use Löve for other purposes also; maybe someone will write a gif decoder someday... though iirc it may already exist somewhere.

*Except for artsy games.
**I'm not actually Frank, rather a real Dick

Temporal Paradox Edit: pgimeno did it.

[Someguynamedpie]

That doesn't seem like a valid reason to me. I require GIFs because I load images from the web in my love app, but it seems to be the love developers like to remove features so I'll just steer clear.

[zorg]

I require GIFs because I load images from the web in my love app

The web is wrong in using jpeg and gif compressed images because lossy compression makes everything worse.

it seems to be the love developers like to remove features so I'll just steer clear.

That doesn't seem like a valid reason to me.

As i said, libs might exist, and if not, someone will sooner or later create them to fill a featural gap, but for games, which is the main point here, they were a subpar format.
Then again, it's your choice.

[slime]

Gif loading never really worked - it only loaded the first frame of the gif at best.

Why do you need JPEG encoding? It was removed because it was a large dependency for no real use. Lossy jpeg screenshots of games are typically not really what you want to save (users can always re-export to jpeg if they really want, of course).

Keep in mind LOVE isn't an image processing framework, it's a game framework. Support for every image format is not at all one of its goals. I'd even recommend using compressed texture formats like DXT5, since they have substantial memory and performance benefits compared to PNG/jpeg/etc, when loaded and rendered.

[Someguynamedpie]

The jpeg encoding requirement was for a small project that recursively encoded things so it was pretty minor.
The single-frame decoding of GIFs was all I needed in my main project -- the place I download the gifs from to display them are single-frame anyway; and I was working on a pure LuaJIT GIF decoder but its not really feasible without proper LZ inflation.

For high quality games, exporting of JPEG screenshots is usually preferable due to PNGs encoding not being optimal for high color variations.

Out of curiosity, why does it matter how large the dependencies are? DevIL is a hefty library, yes -- but does that matter? Its fast, decodes a ton of formats for a wide variety of uses so its not limiting whatever the developer may intend, etc. I don't see why using "love is a game framework" holds any weight since it gives plenty of raw power giving it much more use than just as a game dev platform. If thats for some reason the entire idea around it, then the smaller filesize argument goes out the window because most games can have a hefty number of assets.

[Someguynamedpie]

On the web, GIF is a much more optimal format than the alternative of APNGs and is more optimal and efficient still for smaller animations for various web components as opposed to webms and similar. Likewise to JPEGs-- PNGs of photography are much larger in filesize than their JPEG counterparts so it will keep its rightful place on the web as well.

[airstruck]

On the web, GIF is a much more optimal format than the alternative of APNGs

Not sure what you mean by "optimal" or how this is relevant to Love, but apng's 8 bit indexed images allow partial transparency, unlike gif's 1-bit alpha, and still result in smaller files than gif. And, of course, apng supports a high-color format which looks a hell of a lot better than gif for any image with more than 255 colors, as well as other formats like greyscale which gif does not support. With apng you have the choice of either looking better than gif and being smaller than gif, or just looking way better than gif. In fact, gif is inferior to png in pretty much every way, except maybe browser support.

For high quality games, exporting of JPEG screenshots is usually preferable due to PNGs encoding not being optimal for high color variations.

The only time a lossy format is ever preferable is when you want to save space/bandwidth. To say that jpeg is "usually preferable" in this situation implies that disk space is usually very limited or expensive. I don't think this is the case. If it is the case, surely there's (usually) at least enough disk space to do the initial export in a lossless format and let the user convert it to a lossy format and delete the original if they choose to.

[bartbes]

I was working on a pure LuaJIT GIF decoder but its not really feasible without proper LZ inflation.

Thankfully LÖVE 0.10.0 can do just that!

Out of curiosity, why does it matter how large the dependencies are? DevIL is a hefty library, yes -- but does that matter? Its fast, decodes a ton of formats for a wide variety of uses so its not limiting whatever the developer may intend, etc.

Of course it does matter. But what also matters is that it has an annoying license, the LGPL, and it was always slightly annoying to work with. In 0.9.x we had already written extra loaders, to support compressed data formats, so we had the infrastructure to easily replace it, and we did. All of DevIL was replaced with only two new bindings, yet we retained support for all major formats. We decided not to add support for GIFs because they never animated in the first place (nor does love have the infrastructure for it), and it's a relatively poor image format for just about anything.

We also dropped support for Kodak PhotoCDs, by the way. And apparently mp3s.

I don't see why using "love is a game framework" holds any weight since it gives plenty of raw power giving it much more use than just as a game dev platform.

But it is! Just because you can use it for other things doesn't mean it's not a game framework. There's no reason to explicitly limit what you can do with love, but when we decide what to add, change or remove we really only have in games in mind.

[Someguynamedpie]

Unless LOVE can decode LZW, you can't decode GIFs (and lzw uses enough bitshifting to make it a large enough pain to make in Lua). I don't think its unreasonable to support GIFs while still ignoring animated GIFs given how poor of a format it would be for games. And actually, I was under the impression that DevIL was under the BSD license -- seeing that its LGPL is garbage and I can understand why it was removed (hell, seeing that is going to have me remove it from my game engine as well) I'll just fork LOVE and adjust the things I need with it I suppose -- but that'll make it hard to support the other platforms it does now. I'm not a fan of considering LOVE as a game-exclusive engine because it has uses as a scientific tool -- especially because you can theoretically use it with TORCH, as well as love being a moderately nice platform to make utilities and applications.