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 

• New features:
  • Support for image types (color models): GREY, GREYA, RGB, RGBA, CMY, CMYK, CMYKA and custom
  • Additional builtin energy functions based on luma instead of brightness
  • Support for custom energy functions
  • Functions to read out the energy map
  • Cancel function to interrupt computations
  • Additional methods for bias and rigidity masks
  • Use a single progress instead of several ones when the update is performed in steps
  • Can handle input buffers non-destructively

• Performace related:
  • Faster rescaling thanks to optimisations in the code
  • Spare memory when not using features (e.g. the bias)

• Configuration
  • The default installation directory is now /usr instead of /usr/local
  • Compiling under MinGW now correctly produces a DLL with the default settings
  • Now it also compiles correctly under MS Visual C++ on Windows
  • All public macro names start with LQR_* (old versions are still available but can be disabled at configure time)

You find it in the Download Page.

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

Julien

After looking at the literature, it seems that one can easily implement skin tone detection using this function:

int is_skin_tone(R,G,B) {

S = R +G+B;
r=R/S;
g=G/S;
b=B/S;
s=r+g+b;

return( b/g < 1.249 &&
s/3r > 0.696 &&
1/3.0-b/s > 0.014 &&
g/(3s) <0.108);

}

We will implement it to try if it works in the Digikam content aware plugin, if it does we will let you know for a possible integration at Lqr level.

Regards,

Julien Narboux

Julien

I will think about a general framework for convolutions, it seems a good idea; however, it should just be a special case of a user-defined functions framework - I think I will implement that first (as soon as I can, it requires some work).

Julien

As far as the new energy function are concerned, maybe a convolution function would be usefull, then you could have Sobel and Prewit filters.

Julien

LqrRetVal lqr_carver_cancel (LqrCarver * carver)

Obviously, it has to be called from a different thread than the one from which you call lqr_carver_resize (or from a signal handler). It should be thread-safe.
Currently, however, there is no way to recover the LqrCarver object after you call this function (if it actually cancels an ongoing operation).
You can pull form the git repo master branch and read the updated manual or the man pages. Feel free to ask if you have any troubles, or suggestions for further improvement (or if you find any bugs, of course).

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.

Julien

Thanks,

Julien

Thanks,

Julien

We could not find a function to stop computation during the carving process ? it there a way to cancel a computation in the Lqr library ?
If not, it would be nice to have one.

Julien

Gilles Caullier found a bug in Lqr when dealing with 16 bits pictures, look at this comparison:
http://farm4.static.flickr.com/3416/3411750178_76585a8bd3_o.png

Digikam use Lqr version > 0.0.3 from git repository.

Any idea ?

Thanks.

Julien

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

• Enlargement is not limited to 200% any more (it is automatically performed in steps¹)
• Added readout functions for the internal visibility map

You find it in the Download Page.

Changes

• Fixed a bug which could lead to crashes when using a high value for the max transversal step
• Moved private structs to private headers, removed some unnecessarily includes
• Fixes in the manual

• In the new version of the library, the public symbols are the only ones to be exported in the binaries, as it should, while in the older version the private symbols were just excluded from the headers. This shouldn't be of any concern most of the times, as it doesn't really break ABI compatibility.
• The versioning scheme has changed: no “revision number” will be used any more for tar files, micro version will be incremented instead.

New fetures:

• Support for 16-bit, 32-bit and 64-bit per channel images
• Rigidity masks
• Left-right/top-bottom balance

Performace related:

• Improved attached visibility maps management (lower memory requirements)
• All internal buffers turned from double to float, improving both speed and memory requirements

Documentation:

• Reviewed manual and completed refence
• Added man pages

You find it in the Download Page.