Alright, next alpha release. next set of features.

Changes/additions since stable:

• Better matching by improved border-crop algorithms
• Support for Movies (DirectShow codecs required)
• Bugfixing crashes (mostly dual-core systems)
• Optimized core functions (newer systems)

Downloads

• Download (2.08MB)
• ChangeLog
• Release Notes
• Alpha Archive

Details

Better matching

Almost all images include some kind of borders.

Such border might be artifically added (”frameing”, descriptive text labels), or they might be naturally there (background with white walls or dark night).

By removing those borders – we’re curious about the image subject only – the result quality usually greatly improves.

Support for movies

SimilarImages now supports processing movie clips.

I built a custom small DirectShow filter that I use to “copy” single images from a movie.
By this technic almost all movies that your system plays in your media player will also be usable with SimilarImages.
If you’re missing codecs this won’t work.
(DirectShow is part of DirectX and the default way MediaPlayers display movies since some time)
Supported file-formats (when proper codecs are installed:

• AVI like DivX, xvid;), 3ivx
• MPEG (MPEG1, MPEG2 eg. DVD/SVCD)
• RealMedia (Tested with RealAlternative codec)
• Apple Quicktime (Tested with QuickTime Alternative codec)
• OGG Movie

Movies will only compared to other movies (and not to images)
I’m actually grabbing four images from the movie and assembling them to one image that I later use for the comparisions.
This is not the perfect way, but works at least pretty well for re-encoded/resized movies.
However, I’m looking into alternative ways. (If you know about some let me know )

There are a few downsides however:

• Processing takes a lot of time.
  I need to start up DirectShow, let it assemble the so called Filtergraph, seek around in the movie and grab the images.
• There is a timeout of currently 60 seconds within which the image/movie must be loaded. Otherwise loading the file is aborted. This might be an issue on older systems.
• Pretty high memory consumption during grabbing.
• Some codecs might choke/crash. As an example I have seen the ffdshow codec (libavcodec.dll) crash when it tried to process corrupt/erronous MPEG files.
  As a workaround try to disable the MPEG1 support in ffdshow DirectShow filters). Then the default Microsoft codec for MPEG1 processing will be used instead.

Don’t get scared because of these. They are mostly harmless; the worst thing that might happen is that a file fails to load.

Important!: If you like to try movie support then turn explicitly on. Therefore go to FilesFolders/File Types and enable those movie types.

Bugfixed for crashes

There were a few reports where people rightly complained that SimilarImages would cease to continue while searching the matches. (Stuck at 99%).

I was finally able to reproduce the crashes and to fix them.
Which means that in general it should only surface rarily and usually only on dual-core systems when processing large batches.
Problem was that I accessed some object that doesn’t seem to be save for multi-threading (only-reading I thought).
So the alternatives were to rewrite the code to either use Synchronization objects or reimplement stuff in a thread-safe manner (which as possible as this is readonly). I went for the latter.

Furthermore there was a problem introduced with the last announced alpha that made analyzation pass crashing. Should be fixed now as well.

Another point I’ve taken care of is to find and fix memory leaks and consolidate memory usage in general. Although I’m not fully finished the improvements are actually there.

I tried this build with a large batch (240k images and 5k movie clips).
I tried it twice, first with an empty cache then eventually with a populated cache.
Everything went well.

Memory peaked at about 110M (at least TaskManager told me it was like this). This is acceptable to me considering the large batch and furthermore the high memory need of movie support.
The actual working-set of memory (i.e. the memory size when results were ready) was about 80M, and that’s fine too.

Optimized core functions

I finally managed to put together another DLL containing some critically core functionality.
That DLL is optimized for speed using VC2005 optimizing compiler and a lot of tweaks.

There are actually two version of that DLL:

• A “profile-guided” optimized version with SSE instructions.
• A “regular” optimized version without any SSE or such which is designed for legacy systems.

During installation it is automatically determined which DLL to use.

(If you’re curious about the NSIS plugin I did to query CPU features check the Plugin page.)

So long.
Have PHUN!

test