http://imagej.273.s1.nabble.com/macro-convert-calibrated-value-to-raw-pixel-value-tp5022651p5022668.html
> properly. If it matters, I'm interested in using Python 3 (not 2).
> 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>