Missing Classes for CallJavaDemo

[David Webster]

I tried to run CallJavaDemo, but the classes
CallDemo.method0,CallDemo.method1, and CallDemo.method2 are in thg plugins
folder.

David Webster

[David Webster]

Whoops, sorry!! Found them!!

David Webster

On Thu, Mar 19, 2009 at 8:37 PM, David William Webster <
[hidden email]> wrote:

> I tried to run CallJavaDemo, but the classes
> CallDemo.method0,CallDemo.method1, and CallDemo.method2 are in thg plugins
> folder.
>
> David Webster
>

[Joachim Wesner]

Hi list,

while updating some plugin of mine, I noted something:

Usually, if you have an (non-float) ImageProcessor, that has a calibration
attached, that calibration will be automatically applied, when you do
ImageProcessor.convertToFloat().

(BTW, can a FloatProcessor have an extra calibration??)

Now, If you want your PlugInFilter not need to fiddle with the details of
non-float input formats, you can set CONVERT_TO_FLOAT in the return to the
setup()
method. However, that´s what I noted, it seem that this flag will NOT apply
any calibration of the input processor!

So, question, what to do. Probably the current behaviour should not be
changed, but an extra bit-field could be defined, that, when set, also
causes the
calibrated conversion!?

Or, leave everthing as is, do NOT use CONVERT_TO_FLOAT if calibration is
important and add only a little bit of code like:

            float calib[] = ip.getCalibrationTable();
            ip = ip.duplicate();
            ip.setCalibrationTable(calib);
            if (!(ip instanceof FloatProcessor))
                  ip = ip.convertToFloat();

(The duplication in the code below can even be optimized away in most cases
and would only be needed
if the input is ALREADY float, as the filter promises not to change the
input data...)


Any suggestions?


Mit freundlichen Grüßen / Best regards

Joachim Wesner

Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
Wetzlar  HRB 2432
Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy
Martyr | Colin Davis


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[Michael Schmid]

Hi Joachim,

you are right, PlugInFilter.CONVERT_TO_FLOAT does not care about the  
calibration. The flag is meant for filtering operations such as  
convolution, smoothing etc.
When doing such an operation directly on 8-bit or 16-bit data one  
would not convert them to calibrated values before doing the  
conversion and convert them back to 8 or 16 bits after the operation,  
so it is the same behavior.

If you need calibrated values, I'd suggest not using CONVERT_TO_FLOAT  
but rather ip.getPixelValue(x,y), which returns the calibrated value.  
There will be a significant difference on RGB images, however: With  
CONVERT_TO_FLOAT, the run(ip) method is called 3 times with the color  
channels (for filtering of all the colors); with ip.getPixelValue you  
get a (weighted) average of the color channels (weighted depends on  
Edit>Options> Conversion).

---

A FloatProcessor cannot have a calibration.

Hope this helps,

Michael
________________________________________________________________

> From: Joachim Wesner
>
> Hi list,
>
> while updating some plugin of mine, I noted something:
>
> Usually, if you have an (non-float) ImageProcessor, that has a  
> calibration
> attached, that calibration will be automatically applied, when you do
> ImageProcessor.convertToFloat().
>
> (BTW, can a FloatProcessor have an extra calibration??)
>
> Now, If you want your PlugInFilter not need to fiddle with the  
> details of
> non-float input formats, you can set CONVERT_TO_FLOAT in the return  
> to the
> setup()
> method. However, that´s what I noted, it seem that this flag will  
> NOT apply
> any calibration of the input processor!
>
> So, question, what to do. Probably the current behaviour should not be
> changed, but an extra bit-field could be defined, that, when set, also
> causes the
> calibrated conversion!?
>
> Or, leave everthing as is, do NOT use CONVERT_TO_FLOAT if  
> calibration is
> important and add only a little bit of code like:
>
>             float calib[] = ip.getCalibrationTable();
>             ip = ip.duplicate();
>             ip.setCalibrationTable(calib);
>             if (!(ip instanceof FloatProcessor))
>                   ip = ip.convertToFloat();
>
> (The duplication in the code below can even be optimized away in  
> most cases
> and would only be needed
> if the input is ALREADY float, as the filter promises not to change  
> the
> input data...)
>
>
> Any suggestions?
>
>
> Mit freundlichen Grüßen / Best regards
>
> Joachim Wesner
>
> Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
> Wetzlar  HRB 2432
> Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr.  
> David Roy
> Martyr | Colin Davis
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

[Joachim Wesner]

> Hi Joachim,
>
> you are right, PlugInFilter.CONVERT_TO_FLOAT does not care about the
> calibration. The flag is meant for filtering operations such as
> convolution, smoothing etc.
> When doing such an operation directly on 8-bit or 16-bit data one
> would not convert them to calibrated values before doing the
> conversion and convert them back to 8 or 16 bits after the operation,
> so it is the same behavior.
>
> If you need calibrated values, I'd suggest not using CONVERT_TO_FLOAT
> but rather ip.getPixelValue(x,y), which returns the calibrated value.
> There will be a significant difference on RGB images, however: With
> CONVERT_TO_FLOAT, the run(ip) method is called 3 times with the color
> channels (for filtering of all the colors); with ip.getPixelValue you
> get a (weighted) average of the color channels (weighted depends on
> Edit>Options> Conversion).
>
> ---
>
> A FloatProcessor cannot have a calibration.
>
> Hope this helps,
>
> Michael

Hi Michael,

I see your point, but maybe one would like to retain not the **extra**
calibration but really the "effektive" values in the "smoothing" output
or whatever, because otherwise also when not trying to convert back to 8 or
16 bits,
the final scaled values maybe "wrong". So my question.

In my special case, if a Floatprocessor cannot have another extra crazy
calibration attached to it, I already removed CONVERT_TO_FLOAT and the
code I had shown can be even much simpler and handles all cases (float,
nonfloat w/o calibration, nonfloat w calibration) correctly, simply:

            if (!(ip instanceof FloatProcessor))
                  ip = ip.convertToFloat();
            else
                  ip = ip.duplicate();

Cheers

Joachim



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________