Changing fonts in macros for the Series Labeler

[dscho]

Hi all,

it was recently brought to my attention that the following macro does not
do what you think it does:

        setFont("SansSerif", 48, "antialiased");
        run("Series Labeler", ...);

The reason is that setFont() only changes the current slice's font, while
the Series Labeler accesses the font properties as specified via
Edit>Options>Fonts, i.e. the TextRoi settings.

The workaround is to use Javascript (which you should consider anyway,
given that it is such a powerful scripting language):

        eval("script", "importClass(Packages.ij.gui.TextRoi);"
                + "importClass(Packages.java.awt.Font);"
                + "TextRoi.setFont('Serif', 28, Font.ITALIC, true);");
        run("Series Labeler", ...);

Hopefully this information helps more people do what they need to do!

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Graeme,

On Fri, 9 Nov 2012, Graeme Ball wrote:

> a question about ImageJ(2) scripting - going forward, it seems the
> original ImageJ macro language will continue to be supported - but do
> you consider it deprecated? and if so, do you see one of the existing
> scripting options becoming a new standard? Javascript perhaps?

The macro language will be limited to the legacy layer. We will provide a
very similar interface using Beanshell (http://fiji.sc/Beanshell_Scripting)
that will be able to call ImageJ2-specific functionality, but not all
macros will run unchanged.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Graeme & everyone,

Johannes Schindelin wrote:
> We will provide a very similar interface using Beanshell
> (http://fiji.sc/Beanshell_Scripting) that will be able to call
> ImageJ2-specific functionality, but not all macros will run unchanged.

To elaborate, we have managed to create an almost-totally-compatible
Beanshell version of the ImageJ1 macro language. It still needs a bit more
work, but we believe that most ImageJ1 macros will run unchanged in
ImageJ2, while also allowing to mix and match any Java API calls—something
that was previously not possible with the macro language.

The ImageJ1 macro language has been extremely useful to many users.
However, it has a substantial limitation: its functions are separate from
those available from Java and the other scripting languages. In ImageJ2 the
goal is to provide one unified set of functions, which is fully accessible
from Java and all scripting languages. The Beanshell-based macro language
helps to meet that goal, and also makes the reverse possible: calling macro
functions from other scripting languages and from Java.

Graeme Ball wrote:
> do you consider it deprecated?

ImageJ2 plugins and scripts are more flexible than ImageJ1 plugins and
macros. They can run headless on a server, and are accessible from various
applications such as CellProfiler, KNIME, OMERO, and headless from the
command line. I would encourage newly developed scripts and plugins to use
the ImageJ2 API since it offers these advantages, but the ImageJ1 API will
remain accessible, too.

> do you see one of the existing scripting options becoming a new
> standard?

ImageJ2 will support a variety of scripting languages, like Fiji does now.
There is no one language intended to become a "standard" above the others.

Regards,
Curtis


On Fri, Nov 9, 2012 at 4:10 PM, Johannes Schindelin <
[hidden email]> wrote:

> Hi Graeme,
>
> On Fri, 9 Nov 2012, Graeme Ball wrote:
>
> > a question about ImageJ(2) scripting - going forward, it seems the
> > original ImageJ macro language will continue to be supported - but do
> > you consider it deprecated? and if so, do you see one of the existing
> > scripting options becoming a new standard? Javascript perhaps?
>
> The macro language will be limited to the legacy layer. We will provide a
> very similar interface using Beanshell (http://fiji.sc/Beanshell_Scripting
> )
> that will be able to call ImageJ2-specific functionality, but not all
> macros will run unchanged.
>
> Ciao,
> Johannes
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Thomas Boudier]

Hi,

I would like to emphasize the point "The ImageJ1 macro language has been
extremely useful to many users". That's completely true and I'm sure
that one of the big success of ImageJ is the possibility for biologists
to make easy programs. In my every day experience with biologists
researchers and students, they can create very long and quite complex
macros but they will never use the complex API and then use BeanShell.
So if IJ2 wants the same success towards biologists, please keep macros
and improve them.

best regards,

Thomas

Le 11/11/2012 03:25, Curtis Rueden a écrit :

> Hi Graeme&  everyone,
>
> Johannes Schindelin wrote:
>> We will provide a very similar interface using Beanshell
>> (http://fiji.sc/Beanshell_Scripting) that will be able to call
>> ImageJ2-specific functionality, but not all macros will run unchanged.
>
> To elaborate, we have managed to create an almost-totally-compatible
> Beanshell version of the ImageJ1 macro language. It still needs a bit more
> work, but we believe that most ImageJ1 macros will run unchanged in
> ImageJ2, while also allowing to mix and match any Java API calls—something
> that was previously not possible with the macro language.
>
> The ImageJ1 macro language has been extremely useful to many users.
> However, it has a substantial limitation: its functions are separate from
> those available from Java and the other scripting languages. In ImageJ2 the
> goal is to provide one unified set of functions, which is fully accessible
> from Java and all scripting languages. The Beanshell-based macro language
> helps to meet that goal, and also makes the reverse possible: calling macro
> functions from other scripting languages and from Java.
>
> Graeme Ball wrote:
>> do you consider it deprecated?
>
> ImageJ2 plugins and scripts are more flexible than ImageJ1 plugins and
> macros. They can run headless on a server, and are accessible from various
> applications such as CellProfiler, KNIME, OMERO, and headless from the
> command line. I would encourage newly developed scripts and plugins to use
> the ImageJ2 API since it offers these advantages, but the ImageJ1 API will
> remain accessible, too.
>
>> do you see one of the existing scripting options becoming a new
>> standard?
>
> ImageJ2 will support a variety of scripting languages, like Fiji does now.
> There is no one language intended to become a "standard" above the others.
>
> Regards,
> Curtis
>
>
> On Fri, Nov 9, 2012 at 4:10 PM, Johannes Schindelin<
> [hidden email]>  wrote:
>
>> Hi Graeme,
>>
>> On Fri, 9 Nov 2012, Graeme Ball wrote:
>>
>>> a question about ImageJ(2) scripting - going forward, it seems the
>>> original ImageJ macro language will continue to be supported - but do
>>> you consider it deprecated? and if so, do you see one of the existing
>>> scripting options becoming a new standard? Javascript perhaps?
>>
>> The macro language will be limited to the legacy layer. We will provide a
>> very similar interface using Beanshell (http://fiji.sc/Beanshell_Scripting
>> )
>> that will be able to call ImageJ2-specific functionality, but not all
>> macros will run unchanged.
>>
>> Ciao,
>> Johannes
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

... [show rest of quote]

--
   /**********************************************************/
      Thomas Boudier, MCU Université Pierre et Marie Curie,
      Modélisation Cellulaire et Imagerie Biologique (EE1),
      IFR 83, Bat B 7ème étage, porte 723, Campus Jussieu.
      Tel : [phone]   Fax : [phone]
/*******************************************************/

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Thomas,

On Mon, 12 Nov 2012, Thomas Boudier wrote:

> I would like to emphasize the point "The ImageJ1 macro language has been
> extremely useful to many users". That's completely true and I'm sure
> that one of the big success of ImageJ is the possibility for biologists
> to make easy programs. In my every day experience with biologists
> researchers and students, they can create very long and quite complex
> macros but they will never use the complex API and then use BeanShell.
> So if IJ2 wants the same success towards biologists, please keep macros
> and improve them.

Sorry for the misunderstanding. We never suggested to replace a simple API
by a complex one.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ericbarnhill]

Hi all,

I'm wondering if anyone can give me insight into an effect I am  
getting in attempting to implement an algorithm.

The algorithm denotes a forward Laplacian operator as, dropping some  
constants,

FFT^-1[(p^2+q^2)FFT(f(x,y))]

and a corresponding inverse Laplacian operator as

FFT^-1[FFT(f(x,y)) / (p^2 + q^2)]

in short, forward and inverse Laplacians are obtained by multiplying  
and dividing the FFT by a parabolic mask.

x and y are row and column coordinates, p and q are fourier space  
coordinates with origin in the middle of the image.

I was quite interested in this algo because it's not too hard to get  
the Laplacian, but the inverse Laplacian? Hard.

However, the inverse is not quite working for me. I get a  
"checkerboarding" effect where pixels alternate positive-negative. For  
example, -55 might be right next to +55. If I take the Math.(abs) of  
the inverse it looks like it might be about right, though if so the  
algorithm doesn't work so great -- too much high pass on the way in  
and too much low pass on the way back. I can attach an image if that  
helps clarify anything.

I am wondering, is the checkerboarding a result of the nature of the  
DHT? Might I have more luck using some other kind of DFT, or a  
discrete cosine transform?

Thanks for any insights,
Eric

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[James Ewing]

Eric - examine the modulus of result of the first (forward) FFT.  You may have to take out some central points to get a reasonable dynamic range.  You should see a non-central 'spike,' possibly a leading-edge (or trailing-edge) spike, in the modulus of the forward FFT.  That's the glitch that is causing you trouble.  Identify the source of that spike and your checkerboarding will go away.
 - Jim

On Nov 13, 2012, at 6:33 AM, Eric Barnhill wrote:

> Hi all,
>
> I'm wondering if anyone can give me insight into an effect I am getting in attempting to implement an algorithm.
>
> The algorithm denotes a forward Laplacian operator as, dropping some constants,
>
> FFT^-1[(p^2+q^2)FFT(f(x,y))]
>
> and a corresponding inverse Laplacian operator as
>
> FFT^-1[FFT(f(x,y)) / (p^2 + q^2)]
>
> in short, forward and inverse Laplacians are obtained by multiplying and dividing the FFT by a parabolic mask.
>
> x and y are row and column coordinates, p and q are fourier space coordinates with origin in the middle of the image.
>
> I was quite interested in this algo because it's not too hard to get the Laplacian, but the inverse Laplacian? Hard.
>
> However, the inverse is not quite working for me. I get a "checkerboarding" effect where pixels alternate positive-negative. For example, -55 might be right next to +55. If I take the Math.(abs) of the inverse it looks like it might be about right, though if so the algorithm doesn't work so great -- too much high pass on the way in and too much low pass on the way back. I can attach an image if that helps clarify anything.
>
> I am wondering, is the checkerboarding a result of the nature of the DHT? Might I have more luck using some other kind of DFT, or a discrete cosine transform?
>
> Thanks for any insights,
> Eric
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html