Looking for image processing library
-
I am looking for an image processing library to work with photographs. I just need the basics: contrast, brightness, exposure, white balance, sharpining, green screen and other photography type of functions. Can anyone recommend either a library or maybe some good books?
Oh, the images will need to be printed, too.
Sam
-
I use boost.GIL, it's part of the Boost collection. it will do what you've mentioned and a whole lot more, however the learning curve might be a bit steep depending on how familiar you are with the concepts. Here's the documentation:
"Clicky":http://www.boost.org/doc/libs/1_44_0/libs/gil/doc/index.html
-
We developed "DMA image library":http://dmmd.net/main_wp/dmmd-algorithms-dma/dmmds-imaging-library-dma/ for ability to provide customized image processing solutions to our customers.
Also we develop a Photoshop host SDK with which you can run almost any Photoshop filter directly in your application: "vsrPp_sdk, 32 & 64 bits for windows":http://pictomic.com/data/vsrPp_sdk.1.0.11530-win.tar.gz
-
I am no opposed to learning, but time is a concern.
Will the DMA library allow me to simple give it an image and make a white balance adjustment?
I am interested in Boost, but need some good references books to bring me up to speed. Amazon has a lot of books, they are all pricey as far of books so I am seeking recommendations;)
Sam
-
[quote author="scarleton" date="1317292153"]Will the DMA library allow me to simple give it an image and make a white balance adjustment?Sam[/quote]
Surely, yes you can. But ...
DMA's primary development goals were medical images. Applying the same process to a color image is not always the most ideal solution and therefore, at present we don't recommend it for color images. However, we can customize it for you for color. Color processing is more efficient in an Lab color space and we can add that conversion to our library, if there's demand for it.
One of the main advantages of DMA is that it's multi-threaded, handles different color packing on the fly (i.e. R0G0Bo, R1G1B1 or R0R1, G0G1, B0B1) and it handles region of interest and border processing in a transparent fashion. If you want, contact us and we will gladly work with you to further customize the library for your needs.Also if you have any Photoshop filters with "PIDescriptorParameters" or "Action Descriptor Suite" capabilities (i.e. save filter parameters for later use, and don't show filter dialog), again, the answer is yes using our Photoshop host SDK.
In the past we have worked with GraphicsMagick library (c++ wrapper for ImageMagick), but this library has (had ?) a great inconvenience, it always uses 32 bits alignment for every input/output image and consume more resources because of this.
Other solution for you could be IIPL (Intel Image Processing Library).
-
Cincirin,
Actually I would love to use IIPL, but when I look at the API's it is all completely over my head in terms of how I use them to do something as simply as adjust contrast, brightness, exposure, white balance, saturation and maybe one or two more basic tweaks people do with images. I simply don't know how to map these photography terms into the general image process lexicon.
I would LOVE it if there was a good book out there that helped me connect these terms, that I would be 100% for the IIPL, since I want to run on both Windows and Mac.
Since this is to make money, I don't have a problem spending some money to get this done. I found this one library that does everything I need and then some:
"Accusoft":http://www.accusoft.com/ig-netfeatures.htm
The problem is that is some serious money! 2999 USD for the development kit and between 55 USD and 99 USD for each runtime, that is way too rich for my blood when I only need about 10% of what it does!
Sam
-
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...