Posted by
Kenneth Sloan-2 on
URL: http://imagej.273.s1.nabble.com/macro-convert-calibrated-value-to-raw-pixel-value-tp5022651p5022666.html
George-
Using a 1D array is exactly the kind of programming gymnastics that I try to avoid wherever possible. I prize clarity above all else. I *might* consider using a 2D array, if it were supported in ImageJ - but it's not. Note that I'm not asking for 2D arrays! My preference is for a mechanism that allows for manipulation of multiple images without the overhead of switching the "current image". BatchMode is a reasonable compromise, and I'm happy with it.
Duplicating the image and converting it to 32-bit...then writing new values...then converting to 8-bit is another memory-intensive method, which I would consider if I really needed speed and could afford the memory. But, once I was reminded about BatchMode (remember, I'm a macro newbie) I found that the resulting macro was fast enough for my purposes.
What I have learned is that the macro language works well for workflows that involve a single image at a time. Anything which needs to access multiple images on a fine-grained level (such as pixel-by-pixel) is a signal to me to switch to full Java. This is trivial to write in full Java - especially if you create and save a template Plugin to use as boilerplate.
And, that was my goal for the current exercise. It was triggered by yet-another query of the form "how do I transform and measure an image in a way not currently automated" - with enough detail so that (in my eyes) it differed from an actual Plugin only in he syntax.
When I taught image processing to CS students, I took the approach of having them build toy programs which did about this amount of work - simply to get them to write the boilerplate. THEN we moved on to more complicated processing. Our focus was usually more on the nuts and bolts of "how to do it" rather than an application-centric approach which tends to look at what has already been implemented. It's a question of what level of detail you want to emphasize, and whether you are behaving as a user, or a pusher.
But, I didn't have a prototype piece of boilerplate handy. Writing the boilerplate in Java was trivial - but producing the macro version was challenging (for me). So - it was worth doing.
If it's a macro - I don't care TOO MUCH about speed. Anything that runs in less than 30 seconds is fine. When I need speed, my preferred method is to switch to full Java.
I have many small, special purpose Java Plugins that consist mostly of calls to IJ.run(). Clearly, these could be written as macros - EXCEPT that they usually morph over time to include bells and whistles that are awkward (for me) to implement in a macro.
As I said earlier, this has been my experience with "little languages". They are perfect at what they do, but lead developers down a slippery slope as requirements become more complex. After a while, you can become so invested in learning the workarounds that it seems easier to continue to struggle rather than biting the bullet and switching to a more expressive language.
And now...switching subjects...what is the current state of Python compatibility with ImageJ? Every time I am tempted to write Python code to work in ImageJ I seem to spot another complaint that the interface does not quite work properly. If it matters, I'm interested in using Python 3 (not 2). Is there now a robust interface? Does it support Python 3, or just 2? Anyone care to render either my Java or macro versions to Python 3 to serve as a tutorial? For that matter - is there a canonical reference tutorial I can use to get started?
But, after all...this is ImageJ, and not ImageP.
--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html