jimp
jimp copied to clipboard
oliver-moran
Collaborators wanted!
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
How effectively can we help to integrate pull requests?
- test it;
- evaluate code quality; (how?)
- other detail?
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
@oliver-moran it seems like @Iwasawafag has also been contributing actively. Another community maintainer to add?
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
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?
@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.
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?
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.
If anyone like Telegram and want to talk about Jimp, I would like to do so! Call me! :slightly_smiling_face:
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...
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?
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
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.
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.
@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.
@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.
Hi folks, We are building a new testing infra for Jimp. Please see it at the tests branch and feel invited to contribute.
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.. :)
@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. :wink:
I would be happy to start writing tests using Mocha (at least for Node at this stage).
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
I would love to help with this!
However, I struggle with writing tests, so may need some help there :/
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.
@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 :)
@coyotte508 I think the first step would be to figure out if we need to back out the current code base to the most recent release (see e.g. #274). Much has been rewritten since the May release. I suspect the fact that someone rewrote it may have something to do with Jimp going dormant. Someone took a huge risk apparently (?) without first discussing it with other collaborators.
@jtlapp I definitely agree good communication is needed between the collaborators. I would need to check in with all of them. I would also update the readme / docs with the appropriate build instructions / requirements.
There's still a lot that can be done without touching the code itself (cleaning up the issues...).
It appears that 0.2.27 was the last version to function in a browser without having to introduce workarounds.
I've written an extensive tool for developing GIFs based on Jimp. I'm now in the process of replacing the Jimp dependencies. Even were Jimp backed out to the last stable build, I wouldn't want to use it. It's not written with efficiency in mind, and it shows a lack of understanding of basic programming patterns. For example, synchronous functions take callbacks, and there are async constructors taking callbacks. At least the 0.2.27 code was clean. The current code is unmaintainably sloppy.
It'll be a while before I make my code publicly presentable. It's still evolving to suit my needs.