the last word

Photography meets digital computer technology. Photography wins -- most of the time.

  • site home
  • blog home
  • galleries
  • contact
  • underwater
  • the bleeding edge
You are here: Home / The Last Word / Writing your own image processing tools

Writing your own image processing tools

October 11, 2012 JimK 2 Comments

Last May, as I reported in this post , I started looking into ways to implement nonstandard image processing algorithms in Photoshop. I found a workaround for the May problem, but that didn’t stop me from looking for ways to make my own algorithms.

Pixel Bender sounded like a good platform, but that Adobe’s withdrawal of support made that a nonstarter; there’s nothing worse than spending hours and hours, or weeks and weeks, developing code and then finding that your platform is obsolete.

In the 1990s, I did a lot of image processing algorithm development using Smalltalk, but that language, even with today’s much faster computers, is too slow for exhibition-sized images. The reason is that it is almost completely interpreted, to the point of being essentially written in itself. This really helps the learning process – if you want to see how a built-in method operates, you can just look at the code – but slows down execution.

I considered C++ and Java. I hate the C++ object-oriented syntax, especially compared to the elegant construction of Smalltalk, and Java borrowed it, but I could get over that. I find working in an interpreted environment to be more productive than using a compiler, so that tilted the scales toward Java. However, I didn’t find a good image processing toolbox for Java, and I certainly didn’t want to write my own from scratch. There are probably appropriate Java toolboxes out there, but I stumbled into a program called Matlab while looking around, and decided to use it.

Originally created for mathematical, scientific, and engineering programming, Matlab splits the difference on interpretation versus compilation. The object-oriented syntax is in the C++/Java mold. (It’s like the QWERTY keyboard; once a bad design becomes standard, it’s really hard to get rid of it) All user code is interpreted, but the many built-in functions are compiled. Execution speed ends up somewhere in the middle between interpreted and compiled languages. Just about everything in Matlab is a matrix – the name is a contraction of “matrix laboratory”, after all – and images fit right into that paradigm. A standard RGB image is a three-dimensional matrix, of dimensions number of pixels in a row, number of pixels in a column, and the three color planes. Matlab has an extensive image processing toolbox, with generalized functions for many algorithms. It has limited support for ICC profiles: you can read or write images with various standard profiles, and convert between the color spaces of those profiles, but there’s no support for creating your own profiles.

The implementation is rock solid, and it had better be, since the program is expensive. There are free programs that are similar,  like MIT’s Octave, and one called R.

It took me a couple of weeks to learn the language well enough to be productive and to write a little image processing toolkit for myself on top of the Matlab one. Now I’m experimenting. Stay tuned for the results.

The Last Word

← Image processing without computation Why roll your own image processing? →

Comments

  1. Dave Kosiur says

    October 24, 2012 at 12:15 pm

    Have you looked at ImageJ (http://rsb.info.nih.gov/ij/) as a possible alternative? I’ve only glanced at it briefly and am considering it to try a few algorithms for image processing. Between the initial app and the number of plugins that are available, it’s pretty powerful.

    Reply
    • Jim says

      October 24, 2012 at 1:14 pm

      Dave,

      Thanks for the tip. I hadn’t seen the ImageJ material. It looks interesting, and probably capable of faster processing than Matlab. If you use ImageJ, the natural place to end up is with a customized image editor, with you in control of the customizations.

      With Matlab, unless you want to go to the trouble of writing a GUI, the natural place to end up is with a class library that you build on top of the Matlab image toolbox, and running the image processing from scripts that you write.

      ImageJ has the undeniable advantage of being free. If I were starting over I’d look hard at it. But I’ve already bought Matlab, and invested weeks in learning it. I’ll just soldier on for a while, and see what happens.

      Jim

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

June 2023
S M T W T F S
 123
45678910
11121314151617
18192021222324
252627282930  
« May    

Articles

  • About
    • Patents and papers about color
    • Who am I?
  • Good 35-70 MF lens
  • How to…
    • Backing up photographic images
    • How to change email providers
  • Lens screening testing
    • Equipment and Software
    • Examples
      • Bad and OK 200-600 at 600
      • Excellent 180-400 zoom
      • Fair 14-30mm zoom
      • Good 100-200 mm MF zoom
      • Good 100-400 zoom
      • Good 100mm lens on P1 P45+
      • Good 120mm MF lens
      • Good 18mm FF lens
      • Good 24-105 mm FF lens
      • Good 24-70 FF zoom
      • Good 35 mm FF lens
      • Good 60 mm lens on IQ3-100
      • Good 63 mm MF lens
      • Good 65 mm FF lens
      • Good 85 mm FF lens
      • Good and bad 25mm FF lenses
      • Good zoom at 24 mm
      • Marginal 18mm lens
      • Marginal 35mm FF lens
      • Mildly problematic 55 mm FF lens
      • OK 16-35mm zoom
      • OK 60mm lens on P1 P45+
      • OK Sony 600mm f/4
      • Pretty good 16-35 FF zoom
      • Pretty good 90mm FF lens
      • Problematic 400 mm FF lens
      • Tilted 20 mm f/1.8 FF lens
      • Tilted 30 mm MF lens
      • Tilted 50 mm FF lens
      • Two 15mm FF lenses
    • Found a problem – now what?
    • Goals for this test
    • Minimum target distances
      • MFT
      • APS-C
      • Full frame
      • Small medium format
    • Printable Siemens Star targets
    • Target size on sensor
      • MFT
      • APS-C
      • Full frame
      • Small medium format
    • Test instructions — postproduction
    • Test instructions — reading the images
    • Test instructions – capture
    • Theory of the test
    • What’s wrong with conventional lens screening?
  • Previsualization heresy
  • Privacy Policy
  • Recommended photographic web sites
  • Using in-camera histograms for ETTR
    • Acknowledgments
    • Why ETTR?
    • Normal in-camera histograms
    • Image processing for in-camera histograms
    • Making the in-camera histogram closely represent the raw histogram
    • Shortcuts to UniWB
    • Preparing for monitor-based UniWB
    • A one-step UniWB procedure
    • The math behind the one-step method
    • Iteration using Newton’s Method

Category List

Recent Comments

  • Olaf on Nikon Z50 dark-field histograms
  • JimK on Nikon Z50 dark-field histograms
  • Paul on A book report: decisions, decisions
  • Olaf on Nikon Z50 dark-field histograms
  • JimK on Sigma ART 50/1.4 on Fujifilm GFX 50S
  • Simon on Sigma ART 50/1.4 on Fujifilm GFX 50S
  • Bob Foster on Hasselblad X2D firmware 2.0
  • JimK on UniWB on the X2D
  • Ad Dieleman on UniWB on the X2D
  • Christer Almqvist on Specularity, part 2

Archives

Copyright © 2023 · Daily Dish Pro On Genesis Framework · WordPress · Log in

Unless otherwise noted, all images copyright Jim Kasson.