3
votes

I am working on a web script that handles image processing using ImageMagick. It takes relevant parameters, executes an ImageMagick command at the command line or shell depending on OS, and passes the raw image data back to the script. The language of the web script is obviously not pertinent.

Simple use cases include: convert -resize 750 H:/221136.png - which just resizes the input image to 750 width and outputs the raw data to the console. More complex use cases involve rotating, resizing, cropping/panning, and drawing.

The script works great and is quite fast for PNG, GIF, and JPEG inputs, even at fairly large (4000x5000 resolutions). Unfortunately my input data also includes JPEG-2000. A 10-15 Megabyte JPEG2000 takes a truly insane amount of time for ImageMagick to process, in the order of 10-15 seconds. It is not suitable for live, on the fly conversion.

I know quick conversion of JPEG-2000 to JPEG for web output is possible, because a piece of Enterprise software I work with does it fairly on-the-fly. I'm not sure which library they use--the DLL/so they use is DL80JP2KLib.dll/.so. Looking it up, it seems that a company called DataLogic makes this, but they don't seem to have any obviously relevant programs on their site.

Ideally I'm looking for a solution (plug-in?) that would either enable ImageMagick to convert these high resolution JPEG-2000 images on-the-fly like it does with PNG, GIF, or JPEG... or a separate command utility that I can run in advance of ImageMagick to convert the JPEG-2000 to an intermediate format that ImageMagick can process quickly.

The servers that will run this script have 32 gigs of RAM and beefy processors. Assume that speed of conversion is more important than resource usage efficiency. Assume also that while I need some semblance of quality, image lossyness is not an urgent thing. Licensing requirements and/or price are not important, except that I need to be able to test it myself for speed on a few sample files before we buy. The ideal solution is also (relatively) OS independent

I tried an application from Kakadu Software and it's fairly quick, in the order of 3-4 seconds, but that's still not fast enough. If it's not possible to get below, say, one second, I will look at batch converting files in advance.

I have uploaded a representative file (JPEG-2000, ~8MB) to MediaFire: http://www.mediafire.com/?yxv0j6vdwx0k996

1
I don't know it at all, but have you tried gimp scripting? A plugin exists at registry.gimp.org/node/16241fge
I haven't, but production version Gimp doesn't do JP2K by default and at first glance the GIMP JP2K plugin uses the Openjpeg library (code.google.com/p/openjpeg). Openjpeg offer their own binary command line utility that has, frankly, pretty crummy performance for the use case of live conversion. Maybe 10-15 seconds per file again, and like Kakadu only outputs to intermediate formats like .raw or .bmp which will still need to be processed by ImageMagick.aaron
I'm looking at this from a different prespective; while 10-15 seconds does seem like a long time, setting user expectations is a big part performance perception. Test a pop-up notification 'JPEG-2000 input takes longer to process, should complete in 10-15 seconds'; if you have sophisticated users, that may be all you need. Good luck!shellter
@shellter The thing is, I don't really need to set user expectations. As I mentioned in my original question, I'm already using enterprise software that does JPEG-2000 on the fly for web serving. Using the exact source files that I'm trying to process myself, in fact. But because the enterprise software is compiled, doesn't take arbitrary inputs, and doesn't document the library it uses (like I mentioned, DL80JP2KLib.dll/.so) I can't do it through there.aaron
Yes, I did read your question, and I did say 'here's a different prespective'. If that doesn't work for you, I understand. Good luck in your search.shellter

1 Answers

1
votes

I found exact image to be much faster in the past.

http://www.exactcode.de/site/open_source/exactimage/

Mark Tyler (original author of mtPaint) once split out the excellent graphics handling parts into a separate library (mtpixel ...since abandoned as a separate project, but included in mtcelledit @ its Google code home)