Friday, February 12, 2016

Friday: At least I got pretty much all my work stuff finished today.

I thought it was funny.

I really hate object oriented programming.  "It'll be so much better, and cleaner!"  Bullshit.  It's needlessly complicated setting up hoops and then jumping through them and then shutting the hoops down.  The current problem is that I'm attempting to write a program to automatically construct gifs from my cell phone pictures, so I don't have to do it manually.  It's not a really complicated math problem.  My current solution design:
  1. Open out the first image, and take its FFT.  That's the template.
  2. Open all subsequent images, take a 100x100 pixel crop from the center + maybe like 10% of the image size.  This assumes the very center is the thing being giffed, and chooses something slightly off centered from that.  FFT that crop.
  3. Cross-correlate the crop with the template, and find the pixel offset needed.
  4. Offset full image by that amount.
  5. Scale the image down, and take a 400x300 crop around the center.  I had thoughts of putting in some sort of "activity check" that would basically look for the pixels with the largest sigma when taken in terms of the image stack, but decided a simple crop would probably be fine.
  6. Write out image, using the input filenames to determine the animation timing (since my camera writes things like IMG_20160117_175142084_resize, so year/month/day_hour/minute/second/milliseconds).
However, opencv doesn't write animated gifs.  That means using imagemagick.  The C api is needlessly complicated, forcing everything to be packed into arrays of images for no really good reason.  Sure, I'm operating on an array of images, but there's no clear "read all of these images into the array."  It's all "load each image into it's own single-element array".  Which is stupid.  So I looked at the C++ api, to see if some of this bullshit is hidden.  Nope.  It's even worse.  There isn't even a single image FFT.  You have to pack the images into a container, and then operate on the container.  Why?  Even more fuckery: The image class contains an inverse FFT operation, but not a forward FFT operation.  Why would you think, "oh, we definitely need the inverse FFT here, but it'd be silly to put in the forward one"?



No comments:

Post a Comment