Showing posts with label image processing. Show all posts
Showing posts with label image processing. Show all posts

Friday, December 27, 2013

Sunday, March 3, 2013

PaperPort .MAX files

I've still got about 85 PaperPort .MAX files from 2004-2006 when we had a scanner bundled with the format.  It's proprietary, which is a real pain now that I no longer have the software to read it.  None of the files are drop-dead crucial, but it turns out there's no converter available at all.  And I'm hardly the only person in this pickle.  Proprietary formats are a Bad Thing.

Well, but honestly - how hard could it possibly be to come up with something that could convert these to a bitmap or something?

That would be an interesting exercise in file format management.  I should do it.  I already know the first four bytes.

Thursday, August 9, 2012

Pixar open-sources a component

This is cool!  OpenSubdiv calculates surfaces for animation.

Detecting billboards in photos

Neat little post-mortem on some scripting by a billboard company involving image processing.

Saturday, March 10, 2012

Task: write a new Perl interface to ImageMagick

PerlMagick sucks - for two reasons. First and foremost is that in all the years I've messed occasionally with ImageMagick, not once have I ever been able to get PerlMagick to install correctly, and that's just ridiculous. But worse than that, PerlMagick is bad Perl. It handles errors like C (i.e. you have to check them yourself; no croaking or anything) and its object model is weird.

Answer: wrap the new MagickWand and/or MagickCore APIs in Perl, as a bog-standard CPAN module. It can't be that hard.

Update: I've actually started this one. Github link. I'm basing it on Inline::C, because I've always had a love affair with Inline, back from its early days.

Sunday, February 12, 2012

Evolution of pictures again

Remember that evolution of images last year or whenever? Here's a guy who got really beautifully obsessed with investigating how that might be used as an image compression algorithm. Verdict: not such a hot image compression algorithm, but quite interesting nonetheless.

Saturday, June 4, 2011

Sunday, May 15, 2011

Image processing

After many, many years, my sister and I have convinced my mother that all those decades of old photographs need to be scanned and curated. My sister being a CPA, she has a nice document-feeding scanner. So I ran a few test runs, and it turns out that at 600 pixel full-color resolution, any dust at all inside the scanner leaves vertical stripes on the scanned image that are ... not really monochromatic, but sort of a transparency of a monochromatic stripe.

Naturally, I figure there must be software out there to help me remove those stripes. My best strategy so far is to scan each picture twice, once upside down, so that the stripes will be in different places - then do something to recognize the stripes and eliminate them using the corresponding places on the other image.

So far this is a Hard Problem. Here is a link dump of some of the things I've run across while researching it:
  • The CImg library - and here I thought ImageMagick was all there was!
  • The hdrprep script - a Perl script to manipulate imagesets prior to stitching them together to average out their light levels (HDR = High Dynamic Range, a very neat technique)
  • ALE, which is a tool that works magic on images of such refined scope that I can't even truly understand the explanatory blurb - except that I know what registration is, and it's Good Stuff. This only runs on Linux, as a command-line utility, so it's going to take some actual effort to use it because I'm lazy and my Linux box is downstairs and thus requires ssh to hit.