Legacy ImageMagick Discussions Archive

Details about the planned adaption of my Image Registration code for subimage-searches.
http://embedded-software-architecture.com/?p=183

Unfortunately the API has to be changed heavily.
https://raw.githubusercontent.com/RoelofBerg/limereg/master/lib/export/limereg.h

I will provide an example code ...

Hi fmw42,

Regarding the grid-search: The 'magick' of the algorithm is that it is iterative and automagically proceeds comparing into the right direction. This is done by analytically (!) solving an optimization problem, where shift/rotation are the parameters to be optimized. To say it a bit rough ...

First version based on autotools for a sneek peak:
http://embedded-software-architecture.c ... 9.3.tar.gz
Better, however, wait for 1.0.0 before starting the integration.

Note: I'm dumping my makefile and move to GNU autotools (configure). Makes life easier for people using the lib, I guess.

(x,y: Gridsize smaller than the Imagesize. E.g. every 50 pixels for a 100 pixel subimage. Has to be found out ...)

Ok. I just noticed that you have > 15000 posts. Dear, who am I e-mailing to ? And magick also has so many, many posts. Such an honor :)

I'm currently busy with bringing limereg and liblimereg into Debian. Which also means to do get rid of some limitations (square image size). Feature work can be ...

Extending rigid registration to affine would be pretty easy. (In fact one has to ADD more math to the affine registration to get a rigid one - which we did.) This aproach would allow more flexibility (like magnification or shearing) when needed. Even more easily I could allow a smaller template ...

Note for the tryout:
Usually images for image registration have content in the middle that is surrounded by a black background, like in the .pdf mentioned in the original post. The current algorithm works best with this types of images. I'm working on a way to be more tolerant to image edges with ...

Hi fmw42,

thanks for noting about the demand for a solution :) The algorithm operates on equisized images. The result of the (rigid, 2D) image registration is an angle and an x-shift, y-shift. So the rigid transformation parameters needed to align the images. The example images on the .pdf in the ...

Great ! I extracted the sole library to: https://github.com/RoelofBerg/liblimereg . If
make
sudo make install-dev
doesn't work, please let me know. Note: 'make lib' can be used instead of 'make all' to avoid the dependency to doxygen.

Calling example see folder named 'test' (make test). Another ...

Ok, now I have a library 'liblimereg' that can be called from C and processes byte-stream-images. I'm also busy with packaging the library for Debian (the official repo, if they allow me to).

API so far (simplified):
int Limereg_RegisterImage(
unsigned char* imgRef, //input buffer
unsigned char ...

I see, thanks, so I will extract the tool's features into a library. I'm not sure yet which method I will use for extracting code of an executable-project into a library.

a) Use a makefile that has a special make target for a library-only-version (instead of an executable), like 'make lib' and ...

Hello,

recently I developed a simple and fast algorihm for rigid image registration. I wonder if it could be interesting for Imagemagick.

Example:
mogrify -register reference.jpg template.jpg

Would shift/rotate template.jpg in a way that it is aligned to reference.jpg (best possible overlay ...