I am compiling from the source on OS X and the following was installed,

 /usr/include/lqr-1/lqr.h /usr/include/lqr-1/lqr/ lqr_base.h lqr_carver_bias_pub.h lqr_carver_list_pub.h lqr_carver_pub.h lqr_carver_rigmask_pub.h lqr_cursor_pub.h lqr_energy_pub.h lqr_gradient_pub.h lqr_progress_pub.h lqr_rwindow_pub.h lqr_vmap_list_pub.h lqr_vmap_pub.h 

Gilles Caullier is asking if you could you include this small patch for the next release ?

http://websvn.kde.org/trunk/extragear/graphics/digikam/imageplugins/contentawareresizing/lqr/lqr_base.h?r1=958077&r2=959015

You could also join us at to follow implementation of Lqr in Digikam and discuss with us the possible features:
https://bugs.kde.org/show_bug.cgi?id=149485

Thanks,

Julien

We have a question about your implementation, what do you implement ? I think you implement V ersion B, did you ever tried to implement Version A ? does it create too many artefacts ?
Is your implementation O(h*w*s) where h= height w=widht and s= number of pixel to delete in one direction (assuming we just reduce in one direction) ? or is it O(h*w) ?

Version A

1- Compute energy
2- Find all paths of least energy
3- Delete the required number of paths

Version B

1- Compute energy
2- Find one path of least energy
3- Delete this path and update energy
4- Find another path of least energy, go to step 3

Thanks for your help.

Julien

void lqr_carver_set_preserve_input_image(LqrCarver * carver)

it must be called right after the carver object creation, and it should ensure that your image data is left untouched by the lqr library (hopefully).
You can pull the new version from the git repo, master branch.
The manual is also updated there.

Best,

Andi

in fact, the library contructor expects to receive a copy of the image, since it manipulates the buffer internally (e.g. it may actually free and reallocate memory for it many times, not only when calling the destuctor). Also, calling the carver destructor method is necessary, since there are a number of other internal structures which need to be freed. So the way in which you're doing things now is the right one.

I know that passing a copy is not very efficient, particularly in terms of memory managment, however this has the benefit to ensure that, if there's an error at some point, the orignal image is left untouched.

Of course, this benefit would not hold if the DImg object you're manipulating is itself a copy instead of a reference (I'd be surprised, but I don't know that). From the library point of view, the only workaround in such case would actually be to hold a copy internally, since as I wrote above it needs to be able to reallocate the internal buffer (consider for example that at each carving operation the image is actually enlarged, and therefore it requires more memory), so this solution would of course be as much inefficient as copying it beforehand. Therefore, I don't think there's a way out of this (but suggestions are welcome if you have any).

BTW I am glad to know that you're using the library in digiKam.

we use the LQR in an image plugin of the digiKam image editor (well we are writing a plugin at the moment).

The problem is that we have a crash when the plugin is finishing. This is due to the way we assign the image data to the carver. The data comes from a DImg object (digikam image object) that holds the data.
We pass the pointer to the carver, but after the carver is destroyed by the appropriate function call, the DImg object crashes in the destructor because it tries to free the data (which has already been done by the carver).

My actual question is: do we need to call this destroy method or will it be enough to just do "delete carver;" in the destructor of the plugin?
If not, we need to do a deep copy of the image data first (like we do now) and provide this copy to the carver object. But this is not very efficient of course.

Andi

The manual supplied with the sources in the docs/ directory actually is comprehensive of all the functions in the library: the reference (Chapter 3) is incomplete, but the user's manual (Chapter 2) should explain it all (please, point to me any part which may be obscure and I'll try to clarify it).

For example, you can get the information about the seams which are to be carved from the "visibility maps", which are described in Chapter 2, in the section named "Dealing with the visibility maps (the seams)". Example 2.5 shows how to read out the seam rank ("visibility level") of a pixel.

For the purpose of smoothing, you could do it as follows (assuming a horizontal resizing): do the carving, read out the image and the visibility map, and parse each row of both in parallel. In the visibility map there will be regions with 0's only (which correnspond to the pixels which are kept) and others with strictly positive values (which are the pixels which were carved); this way you can identify which pixels in the output image belong to non-contiguous regions of the input image and smooth them.

In case of vertical resizing you would parse by column, of course. However, there's a problem when resizing in both directions at once. If you wish to introduce such a feature, you should be careful to implement it in two separate steps yourself. I may also implement it as an option for the library, but I am already working on other features, so it may take quite some time to see this in the release code.

However I am finding very little information on doing just about anything else! Is there a more comprehensive manual some where?

Things I want to include is some of the lower level functions that should be available in the library such as getting a mask of the the seams that would be removed from an image, when it is seam carved.

This information is useful for generating smoother images by compressing the pixels in the areas removed, rather than just deleteing the pixels out-right!