Of course I couldn’t resist myself from implementing the algorithm I have written about in the previous post.
Images below have been scaled to fit on the page. The second one was scaled down using the application.
Sep
21
2007
Of course I couldn’t resist myself from implementing the algorithm I have written about in the previous post.
Images below have been scaled to fit on the page. The second one was scaled down using the application.
I’m having trouble gunzipping in windows (winRAR)… could you check to see if it’s packaged correctly?
Sorry about that! Internet Explorer is so rediculous… I tried to “save target as…”, and helpful microsoft converted the .tgz file to .gz without me knowing, and of course did something wrong. I got it to work with Mozilla.
Looks great, and I like how it’s all condensed into one main.cpp! I have a couple questions:
* Did you implement these algorithms yourself, or copy and paste from somewhere?
* When the image is being condensed, why do I only see vertical streaks, and not horizontal?
* Is this an efficient implementation, or do you think it could be sped up?
The algorithm itself is presented in the article, but I was basing on the code provided in one of the articles mentioned in my previous post. The implementation was C based and I think it contained some few errors and suboptimal solutions which I tried to correct/improve, but the impact on the overall result is hard to notice.
About horizontal streaks – I have no idea, I noticed that myself too.
As for optimizations… some time is wasted for converting between QPixmap and QImage, so removing those should improve the speed a bit. Furthermore you can operate on the same image and crop it after the operation instead of creating a new image in each iteration. Finally you could have a bitmap stating which pixels should be removed from the image instead of performing actual removals (which means copying the data) and only create the final image after last removal. But that last thing makes the algorithm for finding the lowest energy path a bit more complex and it might prove that the overall speedup is not that big after all. But of course it’s worth checking out. Unfortunately things don’t look that pretty when you want to scale up the image (you have to create the new image in each step as adding pixels changes the energy pattern). Long story short – yes, I think it could be a bit faster in many cases as now it’s awfully slow.
Regarding speed… I had originally thought, watching the video, that the retargetting algorithm was implemented in real time as the user manually resized the image. However, I now realize that the algorithm is applied once ahead of time, and the scaling information is stored as part of the image, enabling real-time retargetting — which of course is the main goal of the technique. This makes the efficiency of the algorithm less important, but it still would be nice to speed it up using the items you suggest.
I realize that there exist user interfaces for creating these “content aware” images which can then later be rescaled to any size. However, it would be great if such a user interface were created using Qt… and even better, if a standard data-format for the content-aware images could be created (does one already exist?). Then a QImage-type class (QRetargetableImage?) could be invented for them, so the images could be incorporated into Qt applications.
When I get around to it, I’d like to work on these things, using your code as starter. That is unless you get around to it first
Just one more thing, as after writing the previous comment I was still thinking about the speed issue and I came to a conclusion, that it should be possible to implement such a scaling algorithm on a GPU using a fragment program. That could certainly speed things up as well.
Anyway you are free to do whatever you like with the idea. I have lots of other work pending