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

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

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

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.

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!

To install, just issue:

 yum install liblqr-1 

The interface should probably look like pamscale with a -width, -height or a -xysize option. Essentially this is the same code as the example, but with a pnm front end.

What do you think?

All information is contained inside the packages.