Writing a simple native image processing module

[Eyal Arubas]

I was looking for image processing modules which provide basic functionalities (resize, crop, rotate, etc) without any external dependencies.

I couldn't find any.

All modules out there (that I know of) depend on a local installation of ImageMagick et al.

So I started looking into rolling my own module which wraps the CImg C++ library. But then I discovered that it, too, depends on ImageMagick (at least for reading JPEGs).

So my questions are:

1. Is there such a module out there?
   
2. If not, I would like to implement one.
   
1. Any suggestion about how I should go about it?
2. Which is a good C++ image library without pre-required dependencies that I can wrap?

I considered OpenCV and QT's QImage, but both are quite large, and not specifically oriented towards basic image processing.

I realize that installing ImageMagick on a server isn't that big a deal. But I want to use the intended module in a node-webkit application (client); and I don't want to tell my users to install ImageMagick before they can use my software.

Thanks!

Eyal.

[Eyal Arubas]

Clarification:

Compile-time dependencies are (obviously) okay.

What I want to avoid are run-time dependencies; so I will be able to ship the compiled module with my application without any further installations from the user.

[greelgorke]

i just found, but haven't used so far: https://github.com/meltingice/CamanJS which is a canvas library, that can be used in node

[Ryan Schmidt]

You could look into the canvas module.

https://www.npmjs.org/package/canvas

However, although it doesn't depend on ImageMagick, it does need cairo.

[TP]

Look into the Leptonica C Image Processing Library [1] [2]. It depends on libtiff, libpng, libjpeg, zlib, and/or gifflib for its image IO. But I bet any such package also does the same thing. Why would they re-invent the wheel?

 

[1] http://leptonica.org/

[2] http://tpgit.github.io/UnOfficialLeptDocs/index.html

[Eyal Arubas]

greelgorke,

Thanks, but CamanJS for Node depends on node-canvas, which depends on Cairo - which needs to be pre-installed on the system.

[Eyal Arubas]

ryandesign,

Thanks, but I would like to avoid having to pre-install any binary dependency. Whether it's Cairo or ImageMagick.

[Eyal Arubas]

T P,

You are probably right - any such package will have some dependency. But as long as I can resolve all dependencies at compile-time, I don't care.

The point is to avoid having binary dependencies which will have to be pre-installed by the end-user.

I'm developing a desktop application which uses node-webkit, so I would like to ship one package that already contains everything.

I'll look into Leptonica. If libjpeg and the others can be statically linked to my code, that might be a good solution.

BTW, Boost's GIL also seems like a good candidate, in case any one else is interested. It also needs libjpeg, libpng, etc.

Thanks!

[Ryan Schmidt]

On Jun 11, 2014, at 10:13 PM, Eyal Arubas wrote:

> Thanks, but I would like to avoid having to pre-install any binary dependency. Whether it's Cairo or ImageMagick.

cairo is a library, not a binary.

But I also don't understand the distinction you're making between libraries and binaries. Why is it ok for you to ship libraries, but not ok for you to ship binaries?

[Forrest Norvell]

cairo is a binary, in terms of deployment. It has to be present in compiled form on the target system before anything using it from Node is installed, because the native components of those modules have to be able to link against it. I totally understand wanting to avoid complicating deployments with native dependencies.

F

​

[Ryan Schmidt]

On Jun 12, 2014, at 7:35 PM, Forrest Norvell wrote:

> cairo is a binary, in terms of deployment. It has to be present in compiled form on the target system before anything using it from Node is installed, because the native components of those modules have to be able to link against it. I totally understand wanting to avoid complicating deployments with native dependencies.

cairo is a compiled library. An npm module like canvas that uses cairo would link with it.

ImageMagick has both a library that can be linked with and the "convert" and "montage" programs that can be used at runtime. Different npm modules that use ImageMagick might use different approaches. Probably using the programs would be the more common approach.

The OP wrote:

> Compile-time dependencies are (obviously) okay.

So, can't the cairo static library be used for this?

[Eyal Arubas]

cairo is a compiled library. An npm module like canvas that uses cairo would link with it.

Yes, probably. But there's dynamic linking which happens at run-time, and there's static linking at compile-time. I bet most modules do dynamic linking, which is why Cairo / ImageMagick are required to be installed on the system. Or they just wrap the executable binaries, but that can be done with pure Javascript. 

Installation of native Node modules with npm involves compiling them on the local architecture. If I could compile everything, without any binary dependencies, it's guaranteed that everything is compatible with the local architecture (assuming the compilation goes smoothly).

The reason native modules are compiled, and not shipped as binaries, is (I presume) to allow them to be architecture-agnostic. Compiling locally guarantees compatibility, and frees the developer from managing different packages for different platforms and architectures.

So, for shipping an npm package without run-time dependencies I guess I would have to get all the sources of the dependencies and compile them with my module. This would probably require a lot of messing around with node-gyp to make sure everything compiles properly on any platform.

So, can't the cairo static library be used for this? 

Not if I want to have one module which compiles on any platform. 

But for a node-webkit application, on the other hand, I would have to manage platform-dependent packages anyway. So there's another option - get compiled binaries of the dependencies for each platform I intend to run on, and create platform-dependent packages for my application which ship with those binaries.

[Eyal Arubas]

Following this discussion I started development of an image processing module without runtime dependencies.

https://github.com/EyalAr/lwip

Features:

1. No runtime dependencies. No need to pre-install anything.
2. All image operations are done with a native C++ module.

3. Lots of syntactic sugar in Javascript land.

4. Batch operations on an image.

5. Get encoded image data as a NodeJS Buffer object.

Clone the repo and `cd lwip && npm install`.

Installation with npm will be available when v0.0.1 is released (see the milestone).

Everybody is welcome to check it out, help with development and post issues.

On Wednesday, June 11, 2014 1:33:53 PM UTC+8, Eyal Arubas wrote:

[Simon]

Very Awesome!

[Eyal Arubas]

Thanks Simon!

[Leon Li]

Just checked the project on Github, it's awesome... It's absolutely what I need. But I didn't start to use it in my project yet. But it really fits my demand. 

Thanks Eyal........!!

[Alain Mouette]

Did you know that there is already a very pppular project colled LWIP which stansd for Ligh-Wheigt-Internet-Protocol ???

Maybe you could consider changing that or people will certainly get confused

Alain

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/9d33247a-a098-4a9b-94ba-7f214a939a54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eyal Arubas]

Leon,

Glad you found it useful!

[Eyal Arubas]

Alain,

Yes I saw it shortly after I published the module.

Didn't think it's a big deal, as the "other" lwip is mostly used in embedded systems.

But if it does confuse people, I'll be open to name suggestions :)