Why do people use jimp?

[hipstersmoothie]

I'm interested in why people use jimp and don't reach for other tools.

For the server it makes sense, including native deps can be challenging or not possible and jimp being all javascript means it can run anywhere javascript can.

For the browser what jimp is makes less sense for me. I understand it's a all in one image manipulation package so it can be a sort of utility knife, but the browser itself has pretty powerful tools for exactly what jimp does:

• a browser can decode image really easily
• you can use canvas to manipulate images
• you can then encoding the image in png (at least varies by browser)

So maybe it's just because it works good enough without worrying about that last point

@quanglam2807
@marvinruder
@danielholmes
@nopeless

[danielholmes]

My main use case is a product that I'm rendering which includes a bunch of image manipulations. I want this to be done on the frontend (for the end user in a kind of editor app) as well as the backend (for outputting preview image files, instruction manuals for the custom product, etc). So in short, it appeals to me because I can write code that runs in both the browser and on the server.

[nopeless]

1. Legacy & Outdated tutorials (I am guessing that this is the biggest reason)
2. Plugins
3. If it works, it works. Simply do not care about performance

I personally started using Jimp because it was a popular library (1)

I can see why 2 is useful

Maybe next version should just be a canvas wrapper

[marvinruder]

I am using Jimp in a React app that allows users to upload a profile picture. Jimp crops the image to a square of a certain pixel size while retaining aspect ratio using cover() (a function I missed in other libraries), reduces its quality, converts it to JPEG and stores the now much smaller image in a base64-encoded string, which is then sent to the server. I like to do these tasks on the client side, so that the upload takes much less time.

I can do this in just a few lines of code with Jimp, and unlike other libraries it works in the browser, not just in Node, so I went with it. I didn’t know about the Canvas API, but after a first look it sounds to be more focused on drawing rather than for transforming and encoding existing images.

[quanglam2807]

We are using Jimp in Node.js and Electron (main process/Node.js) environment. It mostly to process app icons images (adding frames, removing transparency, etc) and convert images to different formats.

We could use libraries like https://sharp.pixelplumbing.com/ but since we need to distribute our Electron apps across multiple platforms and architectures, compiling and distributing sharp native package correctly across these environments introduces multiple issues. As a JS-only library, Jimp is much better for us to work with.

[Spiri0]

I'm not using jimp at the moment but I want to. Canvas has two big weaknesses for me. The first: canvas can only be 8 bit. That may be good enough for the RGB color space, but images are also excellent, very efficient databases for other purposes and a channel resolution of 8 bits is simply not enough.
Second: canvas is not worker capable. There is the offscreencanvas that works, but it is also limited to 8 bits. A third weakness of canvas, which hasn't bothered me yet, is that canvas has a size limit. Was that 16k? I'm not sure. For historical reasons, canvas has serious weaknesses for modern techniques.

[kozmoz]

I'm using Jimp in Node.js and Electron. the application has label printing functionality, so I wrote a NPM package that does just that; printing to a Dymo label printer. To create the label, it starts as an image that's created by Jimp.

For who is interested, this is my Dymo label printer project that has Jimp as a dependency. https://github.com/kozmoz/node-dymo-printer

[Spiri0]

Here are three screenshots of the nice things I can do with jimp. Of course I can't do this with jimp alone, but a good 16 bit image data loader that is worker compatible without dependencies is of great use when it comes to loading elevation data.
I then process this data in a very complex app that I developed with three.js. I can visit Mars anywhere.

From orbit

closer

I can fly without interruptions to the surface

For this I use 131k. I don't load it all at once, so my computer would never be able to handle it, but rather like Google Maps does. This means that I stream very large amounts of maps through the workers, which three.js can then process. And in the workers, jimp can use its performance to retrieve the image datas, heights, normals, colors, ... from map databases.

I'll try to get the app online. But I will have to host my own server because I need to be able to configure the server specifically.
In any case, a good image loader that can do more than 8 bits is an excellent system for retrieving large amounts of data