http://imagej.273.s1.nabble.com/macro-convert-calibrated-value-to-raw-pixel-value-tp5022651p5022667.html
That’s fair. I will consider converting to 32-bit, or BatchMode. I hadn’t
version - which looked just like yours. That’s because I still had other
parameter, but perhaps BatchMode might be the answer. Also - duplicating
8-bit looks promising. I think I can write a generic macro to handle any
it. That was my original goal.
scripting and “small languages”. They appear to be “easy entry”, but user
the point where it is useful to do so. Currently, I usually see this in
time test it’s limits. I think I have decided that - for me - it’s more
parsimonious to simply use full Java, even for very simple tasks. I
achieve this with a macro”, it is best to switch to full Java. I have a
write complicated macros. I understand that this argument works the other
> Hi Kenneth,
>
> concerning (1), why is there no macro function for calibrated -> raw
> pixel value conversion, I guess that this is because it is needed only
> in rare cases. One can always convert the image to 32 bits (which takes
> the calibrated values) ant then work on this. Also note that raw ->
> calibrated conversion is just a lookup operation in the calibration
> table, whereas there can be no table for the calibrated -> raw
> conversion, so it requires searching for the best fitting value (which
> is slower; nothing that you want to do for each pixel, so a
> setPixelValue function would be of questionable value).
>
> I can't speak for Wayne, but I guess that he would be open to add an
> inverse function for calibrate(value) in case you can provide examples
> where this is needed.
>
>
> Concerning (2) taking pixels of one image and setting pixels of the
> other from that, pixel by pixel: I guess that you have done the obvious,
> using BatchMode?
>
> In any case, the macro language is run by an interpreter, not compiled,
> so it won't be very fast for any pixel-by-pixel operations.
> (I have the impression that it is comparable with python, which is also
> an interpreter language).
>
> The following macro needs about 11 seconds on my computer for a
> 2048x2032 pixel image. About 85% of the time are needed for switching
> between the images in BatchMode (1.5 seconds without switching between
> the images). This is not so bad, about 1 microsecond to switch between
> the foreground images, but it is switching 8 million times...
>
> run("Blobs (25K)");
> run("Size...", "width=2048 height=2032 depth=1 constrain average
> interpolation=Bilinear");
> srcID=getImageID();
> run("Duplicate...", "title=target");
> tarID=getImageID();
> setBatchMode(true);
> w=getWidth();
> h=getHeight();
> for (y=0; y<h; y++) {
> for (x=0; x<w; x++) {
> selectImage(srcID);
> v=getPixel(x, y);
> selectImage(tarID);
> setPixel(w-1-x, y, v);
> }
> }
>
> The bottom line: for pixel-by-pixel operations, use Java or Javascript,
> unless you have small images and you don't care about processing time.
>
>
> Michael
> ________________________________________________________________
> On 11.11.19 19:57, Kenneth Sloan wrote:
> > Thank you for all the prompt replies.
> >
> > Most seem aimed at solving the SPECIFIC application problem. Again -
> this exercise was intended to
> > explore *mechanisms* that might be used in a more general setting.
> >
> > I suppose we have established that the ImageJ macro language does not
> provide a way to set a specific x,y pixel
> > to a calibrated value (as opposed to a raw pixel value. Is that
> correct?
> >
> > In this specific, toy, application, the new value depends only on the
> old value, and "changeValues" can be made to work.
> > But, I can envision many applications where the new pixel value depends
> on location as well as (or instead of) the current value).
> >
> > For example - can I (in the macro language) draw a line in the image
> using a calibrated value? I haven't checked that, so his might be trivial.
> >
> > It seems odd to provide a conversion from calibrated to raw, but not the
> other way. Similarly, it seems odd to include getPixel(), getValue(), and
> putPixel() but NOT putValue(). Is there some reason this is difficult to
> implement?
> > Is there enough information in the calibration (accessed how?) that
> would allow me to do the conversion myself?
> >
> > From a design point of view, I would advocate adding
> putValue(x,y,cValue). It is sufficient (but not as nice) to instead
> > add rawFromCalibrated(cValue). Unless there is some problem I don't
> understand, I would add both.
> >
> > ======================
> >
> > My second question hasn't drawn much comment: is there an efficient way
> to calculate a target image where every pixel is a function of x,y,value of
> the source image - instead of doing it "in-place" as I did. I tried to do
> this by calling selectImage() before every getPixel() and putPixel(), but
> that seemed horribly slow. But - I had other issues at the time, so this
> might not be so bad. This doesn't matter until I have a putValue()
> function.
> >
> > Back to full Java, for me, I suppose.
> >
> > --
> > 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>