Jpeg loading refactor #435
Conversation
Should be supported by all GL. Thanks to CrystalP for the help with DirectX
TODO: Get rid of the need for libexif, this is simple enough to do ourselves. TODO: Add a simple encoder for writing files
|
As an aside, maybe you'll want to look at replacing cximage entirely with graphicsmagick (http://www.graphicsmagick.org/). I hear they are like "libav" but for still images. graphicsmagick has things desirable to us, namely, a much more active upstream, an upstream that maintains support for every conceivable device on the planet (at least they claim), and Python bindings. There's probably other things too, but this is things that stood out to me skimming through their website. graphicsmagick can use libjpeg for jpeg support, so I imagine libjpeg-turbo could also be used. |
|
Ok, so apparently, imagemagick has gone through a bunch of improvements since I last checked and looks like a better alternative to graphicsmagick now (www.imagemagick.org). They have IOS support and PythonMagick uses them now, and they use libjpeg for jpeg support. |
|
Sounds good to me, anything to rip out cximage. But beware, cximage uses libjpeg too. It's the overhead of the lib itself that causes the slowdown. |
|
I did a patch which used magick instead of cximage but it was a nightmare for windows apperantly, it worked just fine for linux (probably osx too) though. http://trac.xbmc.org/ticket/8992 |
|
I asked @topfs2 quickly on IRC if imagemagick would be a possibility: If we can abstract this away in the future with some cross-platform lib that doesn't sacrifice too much speed, you certainly have my blessing to revert this. But for now, the gains are too big to pass up. And since we're not introducing any new dependencies, I don't think it can hurt. |
|
Pushed in b8b6eec. |
|
I think it's worth another look (imagemagick I mean) as far as windows support goes. It seems activity has picked up for imagemagick, and whatever problems that might have existed before might have been addressed by now. |
On all platforms other than IOS, we use cximage to load jpegs. It is incredibly slow. Using libjpeg(-turbo) directly results in a speedup of around 2x on average, and much higher for larger images.
I believe i have osx/win32/ios/linux acks already, just wanted to do a quick pr to be sure that no one had any fundamental concerns. @jmarshallnz We discussed this a while ago when I first started poking at it, and I believe you were ok with it as long as the exif orientation was working. It currently uses the libexif that we build, and is verified working, but I'd like to rip that out and add a quick function to grab it from our source imagebuffer, that way we avoid an unnecessary file open.
Other than that, I'm quite confident in this as a drop-in for what we have. If decode fails for any reason, it falls back gracefully to cximage.
Will push this in a day or two barring a good reason not to.