Superimpose

[N IW]

hello,
   
  I am now trying to do superimpose on MRI images. On one MRI image,I would like to cut a desired area and superimpose and paste the area on the second MRI image, by using Image J. Does anyone know the way to do it? I am wondering whether I could do the superimpose by using this software.
   
  Thanks..
   
  Sincerely,
  Ng
 

 
---------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar

[ali ayata]

hi,
   
  a.
  open both image in imagej
   
  process > image calculator
   
  use add function/
   
  b.
you can also use photoshop to superimpose 2 image in a equal manner or different mixture via changing transparency percent of the each image.
   
  have a nice year...
   
  Ali Ayata
  GATA Haydarpasa Training Hospital
  Department of Ophthalmology
  I s t a n b u l  
 
N IW <[hidden email]> wrote:
  hello,

I am now trying to do superimpose on MRI images. On one MRI image,I would like to cut a desired area and superimpose and paste the area on the second MRI image, by using Image J. Does anyone know the way to do it? I am wondering whether I could do the superimpose by using this software.

Thanks..

Sincerely,
Ng




       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

[Joachim Wesner]

Hi all, best wishes for the new year!

I know this subject has been discussed quite for some time, but I think I
probably stumbled over some other  "feature" that I did not yet find
discussed!?

Scenario:

1) I´m working on some small to medium size plugins using the IJ built-in
Editor and Compile-and-Run commands.
2) While development the source files for the plugin are stored in a
subdirectory of /plugins
3) I have a couple of utility classes that are packaged together in
*another* subdirectory of /plugins, say /plugins/libs as a simple example.
This is because several plugins will later need to access those classes. I
also do not really like to have a hidden copy of the utility classes with
evey plugin in the jar as discussed in some posts.
4) While working on a plugin I also might want to have easy access to the
source code of the utility classes for fixes, adding extra methods etc.,
i.e. I want to keep the classes resp. java sources
in its subdirectory, not in a .jar file
5) However, when later deploying the plugin, I do not want to make any
changes on the source code, i.e. no changes on "import libs.*" or "package"
statements. At best both subdirecties would simply need to be converted to
.jar files that both go into /plugins and it should work.

As I understand from studying the different posts in this forum and infos
on the internet, there is no problem for this setup at *RUN* time, but it
is a problem at *COMPILE* time. This is because ImageJ
has its own class loader which is smarter than the regular Jdk loader, i.e.
it will treat .jars exactly like subdirectories, so the above mentioned
final conversion from subdirectory to .jar requires
no changes. However, at compile time the regular Java loader is active,
which does not  act this way,

The problem:

One suggestion to fix this is to simply add the /plugins directory to the
IJ class path. I did this in the ImageJ.cfg file. After this, everything
works fine as long as the plugin sources really are in a
subdirectory of /plugins as mentioned above, but I just discovered a
strange behaviour when you try to create a simple plugin in /plugins
itself, for example using the "Plugins/New/Plugin/OK/^R" command. Everyting
seems to run OK, the message box of My_Plugin.java appears, but after this,
you cannot really do any changes to the source file (I.e. change the text
in the message box), any changes will be ignored, it seems some hidden,
cached version of that class is running, also even deleting the
MyPlugin.class does not help, you need to restart ImageJ to see any
changes.

This strange behavious disappears when you either put the simple plugin in
its own subdirectory of remove /plugins again from the classpath in
ImageJ.cfg

I tried IJ 1.39k or 1.39n with package Java 1.6.0._02 (Win XP)

Any suggestions?

Sincerely

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. Martin Haase | Colin Davis | Dr. Wolf-Otto Reuter


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

[Jinglei Yang]

Dear All,

I have a question about how to analyze the color change of a small sphere.

The sphere is compressed with increasing load. The projective image
sequences are recorded using a color imaging system. Its color will change
and expand from gray to purple/blue starting from the center of the bead
with increasing load.

I use Plugins->Macros->RGB histogram to analyze the RGB change. Both the
entire area of the sphere and a constant centralized area are considered.
But the byte values of RGB all decreased with increasing load! The values of
Red and Green decreased more obviously than that of Blue.
However, I thought the value of blue should increase because I can watch the
color changing to purple/blue by naked eyes.

I have no background of chromatics. Does anyone here give any suggestions
about this issue?

Thank you very much!
Happy New Year!

Jinglei Yang
@UIUC

[Harry Parker]

Dear Jinglei,

What you observe sounds normal to me. Your eyes/brain are much more sensitive to color hue shifts than light intensity variation. So you would probably not notice that the light intensity is slightly less, but you would notice small differences in the ratio of the colors.
 
--  
Harry Parker  
Senior Systems Engineer  
Digital Imaging Systems, Inc.

----- Original Message ----
From: Jinglei Yang <[hidden email]>
To: [hidden email]
Sent: Wednesday, January 2, 2008 5:46:14 PM
Subject: RGB analysis


Dear All,

I have a question about how to analyze the color change of a small
 sphere.

The sphere is compressed with increasing load. The projective image
sequences are recorded using a color imaging system. Its color will
 change
and expand from gray to purple/blue starting from the center of the
 bead
with increasing load.

I use Plugins->Macros->RGB histogram to analyze the RGB change. Both
 the
entire area of the sphere and a constant centralized area are
 considered.
But the byte values of RGB all decreased with increasing load! The
 values of
Red and Green decreased more obviously than that of Blue.
However, I thought the value of blue should increase because I can
 watch the
color changing to purple/blue by naked eyes.

I have no background of chromatics. Does anyone here give any
 suggestions
about this issue?

Thank you very much!
Happy New Year!

Jinglei Yang
@UIUC





      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

[ctrueden]

Hi Joachim,

All of the behavior you describe makes perfect sense, I think. As you
point out, the problem really lies with the fact that ImageJ uses a
fancy class loader, but only for runtime, not for compile time.

I would recommend using the "Compile and Run" approach only if your
plugin is a single .java file -- as soon as your distribution is more
complex than that, it is safer to just bite the bullet and use the JAR
approach completely.

The way I personally solve the problem for LOCI's "large" plugin
distribution is to simply not use the "Compile and Run" feature
directly, as it becomes cumbersome for complex plugins. Instead, I
have an ant build script that builds a JAR file with the proper
plugins.config and such inside, and a symlink in my ImageJ plugins
folder pointing to my latest JAR file. It does require restarting
ImageJ for testing, but is not too burdensome. To speed the
development cycle, you could always write a small program that
automatically launches ImageJ and then executes your plugin on some
test data.

You can have your source in a completely separate folder, then build
to a JAR using a single ant command, without needing to store the
source code underneath the plugins folder. This approach also has the
advantage that you are testing your code within ImageJ in exactly the
way it will be arranged for the end user, so you won't accidently
release a bundle that works from source but not from JAR.

Regarding your point #3, I would suggest a separate common/shared JAR
file for the utility classes.

Good luck, and happy new year,
Curtis

On Jan 1, 2008 6:40 AM, Joachim Wesner
<[hidden email]> wrote:

> Hi all, best wishes for the new year!
>
> I know this subject has been discussed quite for some time, but I think I
> probably stumbled over some other  "feature" that I did not yet find
> discussed!?
>
> Scenario:
>
> 1) I´m working on some small to medium size plugins using the IJ built-in
> Editor and Compile-and-Run commands.
> 2) While development the source files for the plugin are stored in a
> subdirectory of /plugins
> 3) I have a couple of utility classes that are packaged together in
> *another* subdirectory of /plugins, say /plugins/libs as a simple example.
> This is because several plugins will later need to access those classes. I
> also do not really like to have a hidden copy of the utility classes with
> evey plugin in the jar as discussed in some posts.
> 4) While working on a plugin I also might want to have easy access to the
> source code of the utility classes for fixes, adding extra methods etc.,
> i.e. I want to keep the classes resp. java sources
> in its subdirectory, not in a .jar file
> 5) However, when later deploying the plugin, I do not want to make any
> changes on the source code, i.e. no changes on "import libs.*" or "package"
> statements. At best both subdirecties would simply need to be converted to
> .jar files that both go into /plugins and it should work.
>
> As I understand from studying the different posts in this forum and infos
> on the internet, there is no problem for this setup at *RUN* time, but it
> is a problem at *COMPILE* time. This is because ImageJ
> has its own class loader which is smarter than the regular Jdk loader, i.e.
> it will treat .jars exactly like subdirectories, so the above mentioned
> final conversion from subdirectory to .jar requires
> no changes. However, at compile time the regular Java loader is active,
> which does not  act this way,
>
> The problem:
>
> One suggestion to fix this is to simply add the /plugins directory to the
> IJ class path. I did this in the ImageJ.cfg file. After this, everything
> works fine as long as the plugin sources really are in a
> subdirectory of /plugins as mentioned above, but I just discovered a
> strange behaviour when you try to create a simple plugin in /plugins
> itself, for example using the "Plugins/New/Plugin/OK/^R" command. Everyting
> seems to run OK, the message box of My_Plugin.java appears, but after this,
> you cannot really do any changes to the source file (I.e. change the text
> in the message box), any changes will be ignored, it seems some hidden,
> cached version of that class is running, also even deleting the
> MyPlugin.class does not help, you need to restart ImageJ to see any
> changes.
>
> This strange behavious disappears when you either put the simple plugin in
> its own subdirectory of remove /plugins again from the classpath in
> ImageJ.cfg
>
> I tried IJ 1.39k or 1.39n with package Java 1.6.0._02 (Win XP)
>
> Any suggestions?
>
> Sincerely
>
> 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. Martin Haase | Colin Davis | Dr. Wolf-Otto Reuter
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>

[Superior Semen Works]

Hi Imagej Interest Group,
  I am trying to use ImageJ to analyize motility of sperm.
  I need step by step help in laymans terms to get the program downloaded and "plugged" in.
  I have extremely limited knowledge of the computer so your help would be greatly appreciated.
  Thank you and take care.
  Geoff and Nancy Masterman
  Superior Semen Works
  603 512 5546

Curtis Rueden <[hidden email]> wrote:
  Hi Joachim,

All of the behavior you describe makes perfect sense, I think. As you
point out, the problem really lies with the fact that ImageJ uses a
fancy class loader, but only for runtime, not for compile time.

I would recommend using the "Compile and Run" approach only if your
plugin is a single .java file -- as soon as your distribution is more
complex than that, it is safer to just bite the bullet and use the JAR
approach completely.

The way I personally solve the problem for LOCI's "large" plugin
distribution is to simply not use the "Compile and Run" feature
directly, as it becomes cumbersome for complex plugins. Instead, I
have an ant build script that builds a JAR file with the proper
plugins.config and such inside, and a symlink in my ImageJ plugins
folder pointing to my latest JAR file. It does require restarting
ImageJ for testing, but is not too burdensome. To speed the
development cycle, you could always write a small program that
automatically launches ImageJ and then executes your plugin on some
test data.

You can have your source in a completely separate folder, then build
to a JAR using a single ant command, without needing to store the
source code underneath the plugins folder. This approach also has the
advantage that you are testing your code within ImageJ in exactly the
way it will be arranged for the end user, so you won't accidently
release a bundle that works from source but not from JAR.

Regarding your point #3, I would suggest a separate common/shared JAR
file for the utility classes.

Good luck, and happy new year,
Curtis

On Jan 1, 2008 6:40 AM, Joachim Wesner
wrote:

> Hi all, best wishes for the new year!
>
> I know this subject has been discussed quite for some time, but I think I
> probably stumbled over some other "feature" that I did not yet find
> discussed!?
>
> Scenario:
>
> 1) I´m working on some small to medium size plugins using the IJ built-in
> Editor and Compile-and-Run commands.
> 2) While development the source files for the plugin are stored in a
> subdirectory of /plugins
> 3) I have a couple of utility classes that are packaged together in
> *another* subdirectory of /plugins, say /plugins/libs as a simple example.
> This is because several plugins will later need to access those classes. I
> also do not really like to have a hidden copy of the utility classes with
> evey plugin in the jar as discussed in some posts.
> 4) While working on a plugin I also might want to have easy access to the
> source code of the utility classes for fixes, adding extra methods etc.,
> i.e. I want to keep the classes resp. java sources
> in its subdirectory, not in a .jar file
> 5) However, when later deploying the plugin, I do not want to make any
> changes on the source code, i.e. no changes on "import libs.*" or "package"
> statements. At best both subdirecties would simply need to be converted to
> .jar files that both go into /plugins and it should work.
>
> As I understand from studying the different posts in this forum and infos
> on the internet, there is no problem for this setup at *RUN* time, but it
> is a problem at *COMPILE* time. This is because ImageJ
> has its own class loader which is smarter than the regular Jdk loader, i.e.
> it will treat .jars exactly like subdirectories, so the above mentioned
> final conversion from subdirectory to .jar requires
> no changes. However, at compile time the regular Java loader is active,
> which does not act this way,
>
> The problem:
>
> One suggestion to fix this is to simply add the /plugins directory to the
> IJ class path. I did this in the ImageJ.cfg file. After this, everything
> works fine as long as the plugin sources really are in a
> subdirectory of /plugins as mentioned above, but I just discovered a
> strange behaviour when you try to create a simple plugin in /plugins
> itself, for example using the "Plugins/New/Plugin/OK/^R" command. Everyting
> seems to run OK, the message box of My_Plugin.java appears, but after this,
> you cannot really do any changes to the source file (I.e. change the text
> in the message box), any changes will be ignored, it seems some hidden,
> cached version of that class is running, also even deleting the
> MyPlugin.class does not help, you need to restart ImageJ to see any
> changes.
>
> This strange behavious disappears when you either put the simple plugin in
> its own subdirectory of remove /plugins again from the classpath in
> ImageJ.cfg
>
> I tried IJ 1.39k or 1.39n with package Java 1.6.0._02 (Win XP)
>
> Any suggestions?
>
> Sincerely
>
> 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. Martin Haase | Colin Davis | Dr. Wolf-Otto Reuter
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>

Geoff and Nancy Masterman
Superior Semen Works
Bucyrus OH
603 512 5546 Cell


       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.