Posted by
CARL Philippe (LBP) on
URL: http://imagej.273.s1.nabble.com/macro-convert-calibrated-value-to-raw-pixel-value-tp5022651p5022681.html
Dear Keneth,
Let me just answer to your following answer:
>> Nevertheless after completion of this course, I moved over to macro for 80-90% of my
>> programming needs given that the development times between Java and macro are more or
>> less 80% lower.
> I question this. Once you have boilerplate in hand, I find that it takes no longer to
> deliver a tested, working Java Plugin than it does to deliver a tested, working macro.
In Java you need to import all the used libraries as well as define the used parameters.
All these definitions are not needed within Macro programming which make it's use easier and faster.
And as prototypical example, let me just describe the last macro I made for a student and for which the use of the Java language won't make a big difference on the running time but defenetly on the programming time.
So the student aquired 3 channels with 5 heights z-stack 144 pictures time lapse.
The used microscope software saved these pictures into 2 files (because too big) for each of the acquired channels.
So what needed to be done is to open the 2 files corresponding to a channel, concatenete them, reorganize the obtained stack into an ad hoc hypertstack and finally place this obtained hyperstack window at a given position within a 2 screen desktop.
And finally reproduce this same procedure with the 2 other stacks and place the obtained hyperstacks next to the previous one.
So nothing really complicated for an experienced ImageJ user, there's no doubt about it.
But believe me, way too complicated and time consuming for a beginner student to do it "by hand".
On the other side, given that there were only about 20 cells positions to open the described way, it was quite over killing to write a "squared plugin" for this (at least this is my opinion, but you may still disagree to it).
Of course from the user interface I wrote a GUI using the Dialog Macro methods which user interface result is fully indential whether it has been generated by a macro or a plugin.
So hoping I shared you now a little bit of my light, I wish you a good night!
My best regards,
Philippe
----- Mail original -----
De: "Kenneth Sloan" <
[hidden email]>
À: "imagej" <
[hidden email]>
Envoyé: Mercredi 13 Novembre 2019 20:09:18
Objet: Re: macro: convert calibrated value to raw pixel value?
> On your argument:
>> From a practical point of view - once you have standard boilerplate for a
>> full Java Plugin, I’m having a hard time seeing any advantage to the macro
>> version.
> This is more then obvious!
I have been known to be slow. Many things which are obvious to others puzzle me.
> Macro programming is only for quick and dirty things and once you have already spend the time and work for writing a Java code it is nonsense to try to translate it back into the Macro language.
My problem is that as soon as I start reading tutorials on the macro language I run into 5 page long programs which seem to be anything other than "quick and dirty".
> ...
> Nevertheless after completion of this course, I moved over to macro for 80-90% of my programming needs given that the development times between Java and macro are more or less 80% lower.
I question this. Once you have boilerplate in hand, I find that it takes no longer to deliver a tested, working Java Plugin than it does to deliver a tested, working macro.
Now...if you are in "exploration mode" and want to try different approaches interactively, then a macro does appear to be
slightly faster to first execution. BUT (and this is my point) - when it comes time to put a program into production use, or hand it over to someone else to use, it should not take long to produce a full Java version. So...I tend to reject the "it's faster to write" argument.
> At last but not at least, it is way easier (with only a couple neurons required) to move from Java to Macro programming, rather than to make the inverse (taking as example a colleague in this situation).
That is more than obvious! Only...as I have learned...it's good to be aware that the macro language is *by necessity* limited.
Which is why it is worth encouraging folks who start with macros to NOT push macros as far as they can (becoming ever more complicated and clever) and switch to full Java earlier rather than later. This is my "beware of little languages" argument. Little languages are VERY GOOD for small, (quick and dirty), throwaway solutions. They tend to fail when the process becomes complicated, or involves multiple developers/users, etc. The real trap is when a programmer becomes so invested in their macro skills that it is now expensive and painful to switch.
A competent developer should have BOTH tools in their toolbox. Which is why I am taking your advice to learn more about the macro language.
I didn't pick the current application. It was a request from the OP. My first thought was "that's 10 line Java Plugin - surely it's even simpler as a macro". When no one posted such a solution, I saw an opportunity for me to learn enough about macros to do it myself. It took longer than it should have, and required at least 2 helpful hints (mostly from Michael) - but in the end I got there.
In the end, I think this problem *is* appropriate for a macro solution. With my existing skill set, I can (now) implement it either way, in about the same amount of time.
Along the way, I think I identified a few ways that the macro language might be improved. But, I'm willing to tolerate the minor disadvantages of the macro solution. I also now have the right sort of "boilerplate" for use in similar problems.
So...I'm happy. And, since (for me) using Java is just as easy as using macros, I'm not particularly lobbying for the macro language to be "improved". [I might even argue that making the macro language "better" might make the overall situation worse.]
Finally, I recognize that many ImageJ users may not happen to have a usable Java compiler handy. They are *always* faced with a rather large investment in time to write their *first* Java plugin. My message is that this is time well spent (but NOT when you are on deadline to get the current project working, yesterday).
--
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--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html