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.
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
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.
Subscribe to:
Posts (Atom)