Collaborators wanted!

[oliver-moran]

Folks,

When I created Jimp in 2014, I didn't expect it to become such an important part of so many projects. Over the last few months, there have been so many great feature requests, issues raised and pull requests.

That's wonderful. It shows that there is a real community behind this project. That's something that I never imagined in 2014. I am humbled and grateful to everyone who has committed their time, energy and expertise to the project.

At the same time, it's clear that the significance of Jimp has moved beyond my abilities to actively administer the project on my own. So I am looking for GitHub collaborators with a view that in time Jimp will move into genuine community ownership.

With that in mind, I've invited the @strandedcity to become a collaborator. He/she has been the driving force behind the browser version.

If anybody else is willing to take on the work of bug fixes, integrating pull requests, etc. please says so below.

For now, I'll keep publish rights to NPM but in future I hope to share that with the community too.

Oliver

[aurium]

How effectively can we help to integrate pull requests?

• test it;
• evaluate code quality; (how?)
• other detail?

[strandedcity]

Oliver,

Congrats on Jimp's success! You've fostered a great piece of work, and I'm likewise humbled to become an ongoing part of it. It's great that Jimp has become such a useful and popular project (4,500 daily downloads on NPM, wow!). I see people have been using it in Electron apps as well, which is also very exciting.

Real life has been crazy for me lately, but I'll try to make sure to carve out some semi-regular time for the Jimp community once things clear up next month. I see there are all sorts of pull requests and issues live; the sign of a healthy and vibrant community project for sure. Community projects need love and attention of course, and I'll try to bring both.

Thanks so much for creating the community, I'm honored to be a part of it!

Phil

[strandedcity]

@oliver-moran it seems like @iwasawafag has also been contributing actively. Another community maintainer to add?

[iwsfg]

I do not know much about inner workings of many operations in image processing, so I doubt I'm a good candidate for the role. Never heard of a Convolution Matrix for instance, not until I came across #185.

Personally, I'm fine with just sending Pull Requests from time to time

[strandedcity]

Fair enough, though the image processing Jimp does (up until that PR) is relatively straightforward.

@oliver-moran one other question here... When I contributed before, I was able to run the tests to make sure I wasn't breaking anything, but now the tests don't seem to compare the Jimp output to anything. They test that the various functions run, but there's no way to know the results are correct. Am I missing something?

[oliver-moran]

@iwasawafag I never heard if it either, so your help is as good as mine :-)

@aurium good questions!

Test it

There is a test script but, like @strandedcity says, it does nothing more than run through every method and makes sure that nothing throws an error.

I suggest we need genuine unit tests that does the above but also checks the outcome. This isn't hard. Jimp itself can check one image against another. All we need is to check the output of the current script against a set of images representing the expected outcome.

Would be nice to automate these unit tests before accepting pull requests.

Evaluate code quality (how?)

The code quality of PRs have been very high. The most only refactors I've done have been to integrate with the philosophy and API pattern that Jimp was originally written in.

That's a very soft concept to evaluate but at the same time we all know the importance of a consistent philosophy/pattern in an API.

Perhaps a contributors' style guide would help?

Other detail?

Something to look out for is that changes have come in the form of feature requests/bug fixes and sample code rather than proper pull requests.

I've added @aurium and @iwasawafag to the list of GitHub contributors.

[iwsfg]

This was a little sudden. I can't promise to be very active here on a regular basis as I have other projects that needs love, but I guess you could use an extra pair of hands, so I'm going to accept this generous offer. Thanks for putting your trust in me, I'll try my best to be helpful.

I would like to ask few questions as well:

What's the scope of the project?

There isn't a single issue with label "Wontfix", not many pull requests rejected either and features suggested in issue tracker vary from highter level manipulations like drop shadow effect to drawing API. So I find it hard to tell if originally it was supposed to provide low level API for image manipulation or should it be offering highter level APIs as well?

Also what is the main concern? Is it keeping file size reasonable or adding more syntax sugar to make it easier to use instead? If it's latter - it may get too heavy for use in browsers one day. Should modular architecture be considered for some features? Maybe something like image.draw.lineTo(x, y) as far as syntax goes.

And how do Collaborators should decide where they're taking the project?

Should new features be discussed on the issue tracker first and possibly wait for your (@oliver-moran) approval then submited as Pull Request or everyone is free to work on whatever they feel like?

[aurium]

Thanks @oliver-moran!
I can work on unit tests, beginning on next week.

[oliver-moran]

I find it hard to tell if originally it was supposed to provide low level API for image manipulation or should it be offering higher level APIs as well?

IMHO it's as low level as Gimp. So any individual method that's useful in image manipulation is fair game - but if a feature starts to get a life of its own then it should be spun out as a separate project.

For example, in the past there was a stab at creating a command line interface. Initially, it was assumed that the CLI would be part of Jimp itself. However, a decision was taken that it would be better to have Jimp as one project and the CLI as another.

I would take the same perspective with something like a high level drawing API. It sounds like something that is worthy of an project by itself. Likewise, if the number of "special effect" API, like drop shadows and the like, start to grow out of control then maybe these should be spun out as separate (optional) packages too.

Also what is the main concern? Is it keeping file size reasonable or adding more syntax sugar to make it easier to use instead?

I'm a UX guy. So I come from the perspective that if you need sytatic sugar to make it easier to use then the problem is that it's hard to use.

Philosophically, I think a Unix approach to each method is best. Each method does one thing. Does one thing only. And does that one thing well.

Should new features be discussed on the issue tracker first and possibly wait for your (@oliver-moran) approval then submitted as Pull Request or everyone is free to work on whatever they feel like?

Don't wait for me. I trust your (community) judgement. It's the only way. Ping me when you want a release to NPM.

The only thing I ask is that backward compatibility is maintained unless there is a (well thought through) decision to jump major/minor version number.

I can work on unit tests, beginning on next week.

Thank you! I think this is the top priority. If we could get automated integration testing for each pull request up and running then I think that would be brilliant.

[aurium]

I see Jimp much alike GEGL, where real work happens. Jimp may learn something from that project.

[aurium]

If anyone like Telegram and want to talk about Jimp, I would like to do so! Call me! 🙂

[abritinthebay]

Open to helping!

Re: code quality. Things like ESLint standards really help not just from a consistent style point of view but also avoiding bad practices.

For a library like this Benchmarks would make sense too: does a PR slow down a function? Is it faster on certain file sizes? Etc.

Looks like testing is probably the main place to start now tho...

[rafaelcastrocouto]

Hey guys, I've just found out jimp (it's awesome) and after some google I could not find any editor.
Is there a editor/playground/"photoshop like"/wysiwyg that's using jimp?

[iwsfg]

If anyone like Telegram and want to talk about Jimp...

How about IRC? I would love to use it to ask other contributors about what stopping us from accepting some of those pull requests that don't have any problems with them?

I would like to start accepting those and if person submitted them does not respond in a long time – modifying as I feel needed and accepting them anyway.

Is there a editor/playground/"photoshop like"/wysiwyg that's using jimp?

Not that I know of. Honestly, I doubt somebody will try to build one on top of Jimp. In browser WebGL is available and it's much faster and for standalone application native code will always win over JS. As for "playground" - RunKit works, but still requires writing code - it's not a graphical editor. Can displaying images though. Example. Is this what you're looking for?

That said, we should probably include a snippet to be loaded in RunKit by default

[patdavid]

Don't know if you're familiar with pixls.us, but it's a Free Software community for photographers and digital artists. You might be able to find some helpful folks over in the community: https://discuss.pixls.us

There's devs from various projects hanging about and some tinkerers that might have some time to help.

[vicary]

I have a few contributing projects and they are doing well by throwing all feature and general discussions into google group and gitter.

You guys may want to take a look on Google Groups (mailing list) and gitter.im for that very purpose.

[rocketinventor]

@vicary Gitter is good b/c it has some Github integrations but, Google Groups is a weird platform to use if everyone already has a GitHub profile.

[iamropo]

Looking to experience some great stuff, count me in.

[oliver-moran]

@abritinthebay - I like the sounds of that. You're a contributor.

@iamropo, @patdavid and @rocketinventor - Welcome!

@rafaelcastrocouto - There's no UI. The library is intended for manipulation of images purely through JS code. An interactive console/playground would be an interesting thing to make tho to explore the methods.

[aurium]

Hi folks,
We are building a new testing infra for Jimp. Please see it at the tests branch and feel invited to contribute.

[giorgionetg]

Hello world!
I would like to help, right now, I'm just studying and watching... But I will check new issues and, with time in my hands, try to solve.. :)

[aurium]

@giorgionetg @abritinthebay @iamropo and all interested people: you should see the issue #227 and will be great if you could help with tests on tests branch. 😉

[thewizarodofoz]

I would be happy to start writing tests using Mocha (at least for Node at this stage).

[rafaelcastrocouto]

I'm running out of time to keep this alone, so I'm dropping this here so it might get some help and bring JIMP a little closer to the public!

demo: https://rafaelcastrocouto.github.io/jie/
code: https://github.com/rafaelcastrocouto/jie

[Ojas-Gulati]

I would love to help with this!

However, I struggle with writing tests, so may need some help there :/

[jtlapp]

I'm adding support for GIF animations, but I have to decide whether to extend Jimp or wrap it. I'm worried about putting a lot of effort into a PR, because the PRs are piling up unreviewed.

If I don't hear from a project collaborator, I'll write a separate module that wraps Jimp. (But I'm also worried about creating a dependency on Jimp.)

Update: I suspect that if it can be done by wrapping, then it should be done by wrapping. I'll give it a whirl. The Jimp static methods are essentially wrappers, after all.

[coyotte508]

@oliver-moran I'd like to help maintain this project. I see there are a lot of issues that are not really issues and need to be closed, so I'd like to clean those up. The only issues being closed at the moment are those closed by their author. Maybe also point out obvious problems with pull requests. In short, clean up the issues/pull requests and make the pull requests easier to review.

That would be a first thing to do, and maybe I would look at PR and merge them, but if I do it would be with all the proper review and safeguards. At first I will likely add a tag to the PRs I consider ready to be merged, and merge them after a further review and a delay.

Anyway, I'm not making any claim to singlehandedly maintain this project, but I want to do my part and help clean up a bit the noise :)

[jtlapp]

At present it only works in node.js, but I'll add JSdocs so I can get it up. Rushing to it now...

[srameshr]

I need it just to run it on nodejs

[jtlapp]

Okay, getting this all documented was today's project. Let me know if you run into any trouble. Thanks for pinging me to get this out. Package gifwrap, for working with GIFs in Node.js.

[srameshr]

@jtlapp Thank you and god bless you.

[jtlapp]

Heads up new gifwrap users: I'm finding myself needing more colors than the 256 per-frame limit that GIF imposes, so I'm planning to abstract gifwrap to support APNG (animated PNG) as well. gifwrap is only at v.0.6 right now. I could be making some changes that might break compatibility with the existing API. I'll try to keep those changes to a minimum though, as I myself have a ton of code already using the current API. And I'm wondering if I should rename the package at that time, so it doesn't seem to falsely indicate that it's exclusive to GIFs.

[oliver-moran]

Hey, folks, it's been a year since I opened this thread. I haven't been following it but I see there has been a lot of positive discussion on the issues threads and plenty of pull requests - but no commits in six months, and no merge requests pulled.

That indicates to me that there's potential for a very healthy community here but something is missing. What do we need to do?

[jtlapp]

Great to hear from you @oliver-moran! Numerous issues were introduced with the most recently published release, and more issues introduced into the current master, which is not yet published.

I think the best thing to do is to revert back to 0.2.27, which is the last version to work in a browser (not requiring node.js). Then work forward from there.

The current code base is messy and does weird things like asynchronous constructors, which are neither promise compatible nor ES8 compatible.

My experience trying to extend jimp to write gifwrap also taught me a few things about how to make jimp more accessible to extension, but I'd like to start from a more solid code base.

[coyotte508]

I'd say let more people manage issues, so they can clean them up and do a triage of PRs. Set clear guidelines on what you want for compatibility (node version etc.).

I'm not that available anymore but I'd still be happy doing a little cleaning / management (i.e. close resolved issues, adding tags to PR etc). Let others focus on the code, @jtlapp seems to be a lot more familiar with the internals of jimp for example.

Anyway, just my 2 cents :)

[jtlapp]

Or perhaps just get 0.2.28 working with browsers. Here are the commits from v0.2.27 to 0.2.28. (It was a bit confusing to pull up this delta because the 0.2.28 tag is missing the preceding 'v'.)

[oliver-moran]

The browser issue in 0.2.28 is a recurring nasty. It appears to break for me with each build without any change.

It fixed if we moved to ES6 IIRC but I was reluctant to do so for compatibility reasons. With support for Node.js 4 ending in April that's probably not a concern anymore.

[jtlapp]

Also, I think the best way to have jimp working at maximal performance in both node and the client is to delegate buffer management to a plugin (e.g. callbacks), rather than to slow the client down by having webpack emulate node's Buffer. That way the plugin can use Buffer, Uint8Array, Buffer emulation, or whatever, as desired.

A maximally sophisticated solution would hide buffer management behind an API, so that anything algorithmic that might benefit from making it buffer-implementation-specific could go behind the API. E.g. blits could greatly benefit from Buffer's copy() method.

[jtlapp]

I'll work on a solution for gifwrap and report back. Buffer's copy() method is easy to emulate in the client without performance loss, but buffer.readUInt32BE() and buffer.writeUInt32BE() are not. These latter methods should be abstracted into some sort of generic color-copy API, at least if it's important that Jimp run at maximum possible performance on each platform.

[oliver-moran]

FYI I've granted collaborator access to @edi9999 after a request on Twitter.

[mbwhite]

Just come across Jimp and I think it would work well for a personal project; however the browser issues documented above are blockers. Specifically I want to be able to create Jump instance based on already loaded base64 string from an image. (that I've not got to work yet btw). Still investigating though.

[iqbalhood]

I think maybe this is not very important right now, but can I contribute to make a logo for this project?

[edi9999]

Sure @iqbalhood ! That would be great !

[hipstersmoothie]

@edi9999 do you need help verifying pull request? If you add me as a collaborator i can start merging some of the low hanging fruit.

[hipstersmoothie]

I would really like to help modernize the codebase a little bit too!

[Jefwillems]

Hello everyone,

I just stumbled upon this beautiful library and saw this issue. If you still need any help maintaining/ bug fixing, i have some free time i could spend on this project.

[hipstersmoothie]

@Jefwillems Feel free to start coding! I have merge right and will respond quickly

[hipstersmoothie]

@jtlapp the state of jimp is much better. are there any changes you want?

[rafaelcastrocouto]

Going to update jie (source) to check the improvements and make use of this thread again to ask for some help, since I really believe jimp deserves a user interface.
Cheers @hipstersmoothie

[hipstersmoothie]

Really awesome implementation @rafaelcastrocouto!

[hipstersmoothie]

@rafaelcastrocouto if you have any more questions or requests though please open a new issue. This one is getting a little long.

[tjwds]

👋🏻 Hello! I'm happy to help manage issues / PRs, if you'll have me.

[CarlosEspinozaCap]

Please add me so I can make changes to update this to function on React 18

[hipstersmoothie]

I'm working on making this easier. Will have news soon!

[hipstersmoothie]

issue is pinned to the repo!