http://imagej.273.s1.nabble.com/macro-convert-calibrated-value-to-raw-pixel-value-tp5022651p5022664.html
lot of memory depending on the size of the image. But it is a faster
> 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>