Looking for image processing library
-
Well, we have all what you need in our image processing library, but as I said in previous post, many of these filters are adapted for medical images, and it works only for grayscale images 8 and 16 bits per channel. Again, contact us if you want more details about our library ( many I had written so far :-) )
As for other proposed solution, that with Photoshop filters, which is the impediment to you ? I think you can find many free filters over the internet with what you need. And with our host sdk (in the near future we'll have Mac version) you'll be able to run these filters directly in your application without the need for AdobePhotoshop installed.
Regarding IIPL, I know it involves little image processing knowledge ...
-
We use "GraphicksMagick":http://www.graphicsmagick.org in our project, it's a more stable "ImageMagick":http://www.imagemagick.org/ fork. Most of the taks you mentioned should be doable with both of them, I did not check the list.
GM/IM has a nice C++ interface and it plays quite well with Qt.
-
[quote author="Volker" date="1317333158"]We use "GraphicksMagick":http://www.graphicsmagick.org in our project, it's a more stable "ImageMagick":http://www.imagemagick.org/ fork. Most of the taks you mentioned should be doable with both of them, I did not check the list.
GM/IM has a nice C++ interface and it plays quite well with Qt.[/quote]All this is true, but as I said in previous post, GM/IM always use 32 bits (or 64 for 16 bits per channel) alignment "PixelPacket":http://www.graphicsmagick.org/Magick++/PixelPacket.html. So, for a RGB image you (or GM/IM) need to convert in internal format, then filtering, then you must convert back to your 24 bits image. For real-time processing for example, these extra steps are not so good.
-
btw ... "Manipulate An Image":http://www.graphicsmagick.org/Magick++/Image.html#manipulate-an-image is a list of filters supported by the GM/IM.
-
@cincirin:
Every graphics library converts an image into an internal representation of pixels. You plain cannot operate on a jpeg directly, as - by the nature of compression - there are no single pixels in it. And every image format utilizes its own packaging of the pixel data. In order to be of general use, the lib must convert the pixels into an internal representation which is independent of the original format.So you have this drawback with every lib you use. And for the sake of speed I'd bet a penny that every of those libs tries hard to align pixels on word boundaries in order to utilize machine optimization.
Image manipulation is almost never a cheap operation.
-
@Volker, you are right when it comes to image format.
But you don't process compressed pixels of jpeg's or whatever internal pixel representation of every image format. You must process always uncompressed pixels of every image format, which are in most cases non 32/64 bits per pixel. -
If you do not align on 32 or 64 bits, you cannot utilize low level machine optimization. This will lead to a much bigger speed penalty than everything else. It's for a reason that every now and then developers put otherwise unnecessary padding data into objects to force a proper alignment.
-
-
I believe the IM/GM guys and the other graphics library folks do know what they are doing. And in doubt, the surely are of more wisdom in that topic than we all together.
This discussion is becoming too academic for my taste and I'm out now. Happy bit squeezing to everyone who wants to save some three bytes on his 8 GB workstation...