Posted by
Stein Rørvik on
URL: http://imagej.273.s1.nabble.com/macro-convert-calibrated-value-to-raw-pixel-value-tp5022651p5022684.html
I think the tasks described by Philippe in his post is a perfect example of when it makes far more sense to write a macro than create a plugin.
I work in a quite similar way; the major thing I use ImageJ for is to export and analyze µCT data. 99% of the functions I need are already available in ImageJ. So my daily task is to run a workflow that applies for the object I scanned that day, relevant for the customer. This may be for example to import the dataset; calculate the center of gravity of the imaged object; create orthogonal views through the centre of this, add a scalebar and arrows indicating the object's coordinate system for each of the X/Y/Z axis images; import some measured physical data from a connected database, paste the relevant parameters from the object's measurement data in the corner of the image, and finally flatten the annotated image and send it as a PNG file to the customer as well as some worksheets with measured data. I think doing this in Java would require tens or maybe hundreds of hours exploring code and understand the relevant Java API's, instead of just using a the functions already available in the macro language and getting it all done in less than an hour. Most ad hoc tasks can be done in 10-20 minutes.
Since the objects I scan differ from day to day, the workflow is different from day to day. I create a set of macros for each of the tasks I typically use, and then modify them as needed. I do all improvements in a cumulative way, so that the latest version of the macro will include the new functionality included, as well as all earlier code so that it can be reused in a backwards compatible way. The flow of functionality is determined by reading attached metadata, so that the macro will know the nature of the object and decide how to process it from that. So I can use the same macros no matter the size or density of the object. The size may vary from millimeters to decimeters, the atomic density may vary from boron to neodymium.
I write plugins in java in only two cases:
1) If I need pixel-by-pixel processing in 3D, which is much faster in a plugin.
For 2D, getPixel(x,y) works okay, it only takes a few seconds per image.
2) If I need to change some function already in ImageJ that does not work for me as I need. I then extract the code, change it as I like, and recompile as a new plugin. So far I have needed to do that with only a handful of functions. I work almost exclusively with ImageJ 1.x so I can then simply use compile-and-run.
I think plugins work best for general tasks that are image independent. For workflows that are problem-dependent or object-dependent, using the macro language is far more efficient, IMHO.
Stein
-----Original Message-----
Sent: 14. november 2019 00:44
To:
[hidden email]
Subject: Re: macro: convert calibrated value to raw pixel value?
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
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html