ImageJ development involvement/contributions

[dscho]

Hi,

On Sat, 12 Dec 2009, Raymond Martin wrote:

> > This is all nice theory.  I am still waiting to see the code.
>
> Aren't you involved in coding also?

Yes.

> I never indicated that I would solely be doing this separation of GUI
> from core, did I.

When you claimed that ImageJ could be converted to using Swing without
breaking backwards compatibility with existing plugins, I was naturally
very interested.  If you did not say it explicitely, then you led me to
believe that you implied that you would prove this.

I am interested to see my doubts being disproved.

But I will not be convinced by talk, only by code,
Johannes

[Gabriel Landini]

On Sunday 13 Dec 2009  09:30:35 you wrote:
> Would having an RPM, .deb, or other package for installation be of
>  interest?

Opensuse has both ImageJ and ImageJA rpms available.
I prefer to install as a local user.

> Also, I would like to know how many actually use the upgrade feature in
> ImageJ to do anything besides upgrading between a current version and a new
> one?

I do not understand the question. Do you mean to update the ij.jar file?
I do not think you can do other things than testing different versions of IJ
with that.
I also use a script that updates the ij.jar and checks differences with the
published documents in Wayne's site, so if something changes I see the old and
new docs with kdiff3.
 
> Even for that, this kind of feature will not work on Linux/UNIX when ImageJ
>  is installed system-wide, as opposed to somewhere in a users home
>  directory. What is often seen in this case is just an ability to be
>  notified of an upgrade, take you to a web page, and let you choose the
>  method of upgrade that is suitable to your system instead.

Fiji has a much more complex updater, have a look at it.

Cheers
G.

[Gabriel Landini]

On Sunday 13 Dec 2009  09:39:13 you wrote:
> I am using IJ under OpenSuse 11.1 on several stand-alone systems
>  (notebooks). I do not require a system-wide installation, but having an
>  rpm and this feature would be good, I think: If I were using different
>  accounts for different projects or at work/at home it would become easier
>  to manage system wide updates.

Actually the ImageJ and ImageJA rpms and javadocs (v1.43m) for opensuse 11.2
are available from the repository at packman.links2linux.de

Cheers

G.

[Raymond Martin-2]

Hi Gabriel,

> > Would having an RPM, .deb, or other package for installation be of
> >  interest?
>
> Opensuse has both ImageJ and ImageJA rpms available.
> I prefer to install as a local user.

I found the Opensuse ImageJ one recently. Installed it on Mandriva, it
works in general, but there are no plugins or macros available with it
(even though some default macros are in the jar itself?).

To me, at least, it is sort of broken if it cannot put a working folder into
the users home folder as a default setup (e.g., with plugins and macros
folders, etc.) like most other applications do. MIPAV, also a Java application
from NIH, does do this when installed on Linux.

> > Also, I would like to know how many actually use the upgrade feature in
> > ImageJ to do anything besides upgrading between a current version and a
> > new one?
>
> I do not understand the question. Do you mean to update the ij.jar file?
> I do not think you can do other things than testing different versions of
>  IJ with that.

I think it is supposed to upgrade. And my question was to basically determine
if anybody ever would revert to an older version or move up and down between
them, aside from only being interested in upgrading.

It is supposed to at least get another ij.jar and write it somewhere. Of
course, you cannot get it to write into places where a regular user should
never have access. So it does not work on Linux, UNIX. (unless you violate
OS security by changing permissions or run as root).

> I also use a script that updates the ij.jar and checks differences with the
> published documents in Wayne's site, so if something changes I see the old
>  and new docs with kdiff3.
>
> > Even for that, this kind of feature will not work on Linux/UNIX when
> > ImageJ is installed system-wide, as opposed to somewhere in a users home
> > directory. What is often seen in this case is just an ability to be
> > notified of an upgrade, take you to a web page, and let you choose the
> > method of upgrade that is suitable to your system instead.
>
> Fiji has a much more complex updater, have a look at it.

Will do.

Thanks.

Raymond

[Paolo Ariano-2]

Il giorno lun, 14/12/2009 alle 06.38 -0500, Raymond Martin ha scritto:
> I found the Opensuse ImageJ one recently. Installed it on Mandriva, it
> works in general, but there are no plugins or macros available with it
> (even though some default macros are in the jar itself?).

omho imagej is a packet (.deb or .rpm) and imagej-plugins should be
another thing

> To me, at least, it is sort of broken if it cannot put a working folder into
> the users home folder as a default setup (e.g., with plugins and macros
> folders, etc.) like most other applications do. MIPAV, also a Java application
> from NIH, does do this when installed on Linux.

just make .imagej and use another wrapper to launch your imagej ;) you
can specify where to find plugins ...

hth
paolo

--
Paolo Ariano
www.mieleria.it

[Gabriel Landini]

Hi Raymond,

On Monday 14 Dec 2009  12:38:03 you wrote:
> I found the Opensuse ImageJ one recently. Installed it on Mandriva, it
> works in general, but there are no plugins or macros available with it
> (even though some default macros are in the jar itself?).

I think that is a problem. I do not see the advantage to install it system-
wide in computers where I am the only user. Of course if one is an admin of a
multi user setup it might be handy, but I have no experience on this.

> To me, at least, it is sort of broken if it cannot put a working folder
>  into the users home folder as a default setup (e.g., with plugins and
>  macros folders, etc.) like most other applications do. MIPAV, also a Java
>  application from NIH, does do this when installed on Linux.

Yes, that would be a problem when installed in the system as opposed to the
user space. I wonder whether the rpm is being packaged by somebody who
actually uses IJ because if s/he did, the issues you mention should have been
resolved by now (IJ rpms have been available in those repos for some time).
 
> I think it is supposed to upgrade. And my question was to basically
>  determine if anybody ever would revert to an older version or move up and
>  down between them, aside from only being interested in upgrading.

It allows to test the behaviour of older versions when one finds a bug. Not
sure everybody uses this often, but I have used a few times and it is quite
handy.

Cheers,
G.

[Paolo Ariano-2]

Il giorno dom, 13/12/2009 alle 00.58 -0500, Raymond Martin ha scritto:
> Would having an RPM, .deb, or other package for installation be of interest?

just google "imagej debian" and you will find a lot of answers ;) or if
you have a debian distro:
                       
                        aptitude search imagej
                        aptitude show imagej
                        apt-get source imagej
                        and you'll have the source to play with ;)
               
> That is, is system-wide installation of ImageJ in the expected manner as for
> other Linux/UNIX application packages desirable for you and others that use it
> on your systems?

system-wide but with personal configuration file and plugins as most of
packages

> Do you want to be able to control the installation and upgrade of ImageJ by
> only allowing a user with root privileges (superuser/system administrator) to
> do it?

could be nice but you have to check debian guidelines or something
                like ...
               
                hth
                paolo
               

hth
paolo
--
Paolo Ariano
www.mieleria.it

[Prodanov Dimiter]

Dear Raymond,

Some of the discourse so far is based in fact on social phenomena.

1) Forking is a matter of culture. We try to avoid forking because we all support the role of Wayne as the "guru/patriarch" of ImageJ. Some people here may start arguing about Fiji. I personally admire the efforts of the Fijians to maintain a centralized plugin repository and will promote this idea for another plugin repository. But we should avoid asking Fiji to contain "everything but the kitchen sink" so I leave for it the field for 3D reconstructions, image stitching, axonal tracking etc. Fiji is clearly not meant for bio-medical imaging, which I already do for some time at IMEC and is also supported by the Santec group. It is also not meant for DB integration and results management and so on.
But what we need to preserve is the common core functionality of ImageJ so that different projects could interoperate in such way as the different Linux distros are built on top of the same kernel.

2) Pursuing 100% backward compatibility is not tenable in the long run. What we can do is to start up an new PluginPlus or whatever interface, and not touch the old ones. With time we can depreciate the old Plugin  interface so that the development will turn gradually to the new pattern. So at this point I agree with Raymond.

3) In view of all said, I suggest that we have to assemble a list of plugins that need to be maintained and stop caring much about the rest. Good starting points for this are the ImageJ site plugins, the Fiji plugins and the plugins on the IJ Wiki site. Of course such a list should not be set in marble ;) and if other plugin programmers agree to upgrade/maintain their plugins a mechanism for this should be foreseen.

Best regards,

Dimiter

-----Original Message-----
From: Raymond Martin [mailto:[hidden email]]
Sent: Sunday 13 December 2009 06:33
Subject: Re: ImageJ development involvement/contributions

Grant,

> I appreciate your concerns and share them.  If ImageJ does not evolve in a
> way which  the community of developers and users follows, it will fail.  As
> you likely know, these concerns have been debated at length both in this
> mailing list and on the Google ImageJX discussion group
> (http://groups.google.com/group/imagejx).

I do not think it will fail because of those reasons. It would have failed
already if known limitations were so important for users to continue using it.

> I've been working on how to refactor ImageJ for extensibility while
> maintaining backward compatibility for several years now.  The best I have
> been able to do thus far still requires minor changes to plug-ins; minor
> meaning that they could be accomplished with several find-and-replace
> operations in most cases.

If that is the best that can be done my conclusion at this point is not to
bother trying to make extensibility a feature for plugins in their present
form. Add extensibility only for new plugins or upgraded ones, along with
continuing support for old plugins.

> I expect that the authors of most of the plug-ins would make these changes
> as necessary. And if not, I expect that a user of some obscure plug-in could
> find someone to make the change for  them.

This is what should happen, as the assumption to maintain near 100%
backward compatibility along with extending functionality for old plugins
is not going to work in all cases. And it may become a case of diminishing
returns, where too much effort is expended to attempt to provide support
past a certain point.

There seems to be the assumption that once a plugin has been made that it
should work indefinitely through all new versions of the program and have all
the new features also, without maintenance to keep it up-to-date. That is not
reasonable (a cake and eat it scenario) since so many of the underlying
factors will change that are necessary to facilitate that in the long run.

Reality shows that hardly anybody is running software from say 20 years ago
with extra functionality that was added on to it, it either does not exist
anymore, it changed drastically, the operating system it worked on upgraded
numbers of times adding/removing functionality in the process, and so on.
Real-world computing requires periodic maintenance/upgrade of all combined
parts.

> From my experience and reading, software that succeeds in being used
>  by a significant number of people eventually reaches a point where many of
>  the initial design assumptions no longer hold and it becomes necessary to
>  make some incompatible changes in order to evolve the software further.
>  My sense is that ImageJ is at that point.

So some of the motivations that are supposed to drive the funded development
of ImageJ on imagejdev.org cannot really hold.

Maintaining near 100% backwards compatibility is one of those things.

Another is the idea of "no forks". An impossible ideas for a project that is
free software, and public domain on top of that. I really wonder why this same
though this not occurred to anyone working on that side of things. The only
way to have no forks is to have no free software, no ImageJ. Am I seeing
proprietary thinking trying to mix itself in with free software?

>  If anyone can find a way to, for instance, decouple the GUI in a way that
>  doesn't require any changes to plugins, I'm all ears.

I think I just mentioned it above. Provide support for old plugins, but
extensibility only for new ones.

Raymond

[Raymond Martin-2]

Hi Paolo

> > I found the Opensuse ImageJ one recently. Installed it on Mandriva, it
> > works in general, but there are no plugins or macros available with it
> > (even though some default macros are in the jar itself?).
>
> omho imagej is a packet (.deb or .rpm) and imagej-plugins should be
> another thing

Sure, plugins could be it a separate package. It really depends on the utility
of a default set of them, size, categories, and so forth. Still will not have
write access to where they get installed anyway.

>
> > To me, at least, it is sort of broken if it cannot put a working folder
> > into the users home folder as a default setup (e.g., with plugins and
> > macros folders, etc.) like most other applications do. MIPAV, also a Java
> > application from NIH, does do this when installed on Linux.
>
> just make .imagej and use another wrapper to launch your imagej ;) you
> can specify where to find plugins ...

Okay, I am aware you can do this, but it is considered bad programming
practice to do it when good default application behavior will solve the
problem. Command line options are fine, but you should not have to
use any to get the program running in a normal default manner on a particular
operating system. The application should adhere to at least minimal default
behaviors expected of for it to run on the operating system, without any
kind of user intervention.

I already know how to fix this and have functional code to put in that will
make it happen. The question is whether it will get accepted into the
application or can I only put it in my derivative version. If enough people
weigh in on the matter, that know how Linux/UNIX are usually installed and
operate in system-wide terms, it might be more convincing.

I appreciate the comments of those that are only running it from a location
that they have complete write access to (e.g., home directory or other), but
the usual way to run a Linux application is from it having been installed by
the distribution's package manager. So it would be helpful to hear from
those that have it installed system-wide, are using it in multi-user
situations, using it with an application server (e.g., JBoss), other related
ways?

Thanks.

Raymond

[Frederic V. Hessman]

> 2) Pursuing 100% backward compatibility is not tenable in the long  
> run. What we can do is to start up an new PluginPlus or whatever  
> interface, and not touch the old ones. With time we can depreciate  
> the old Plugin  interface so that the development will turn  
> gradually to the new pattern. So at this point I agree with Raymond.

If the new data model is flexible enough (and it better be), then it  
may be feasible to make things  like ImagePlus a particular sub-class  
of SuperDuperImage, in which case most plugins may work with  
practically no changes.  The ImagePlus/ImageStack/HyperStack/....  
model is very primitive, after all.  I

'm not complaining, just thinking about what would be possible if  
ImageJ supported all the data models and world coordinate systems of  
just the FITS standard (generalized hyperstacks, highly non-linear  
coordinates, all known map-projections).

Rick

[Paolo Ariano-2]

Il giorno lun, 14/12/2009 alle 09.22 -0500, Raymond Martin ha scritto:
> Sure, plugins could be it a separate package. It really depends on the utility
> of a default set of them, size, categories, and so forth. Still will not have
> write access to where they get installed anyway.

sorry, i'm confused ... but in debian, right now we have:

usr/share/imagej/plugins
usr/share/imagej/macros
usr/share/imagej/luts

default path points to:
ij_path=/usr/share/java

and this is for the system wide imagej, then for the single user we add:
$ij_user_path/plugins
$ij_user_path/macros
$ij_user_path/luts

finally the loooong imagej.sh wrapper merge both ...

> Okay, I am aware you can do this, but it is considered bad programming
> practice to do it when good default application behavior will solve the
> problem. Command line options are fine, but you should not have to
> use any to get the program running in a normal default manner on a particular
> operating system. The application should adhere to at least minimal default
> behaviors expected of for it to run on the operating system, without any
> kind of user intervention.

ok, i'm not a programmer.

> I appreciate the comments of those that are only running it from a location
> that they have complete write access to (e.g., home directory or other), but
> the usual way to run a Linux application is from it having been installed by
> the distribution's package manager. So it would be helpful to hear from
> those that have it installed system-wide, are using it in multi-user
> situations, using it with an application server (e.g., JBoss), other related
> ways?


we run it as "usual way" and every user add his own plugins ... without
touching imagej source but only playing with image.sh, is a workaround
probably, a bad practice but is good enough to use it ;)

hth
paolo
--
Paolo Ariano
www.mieleria.it

[Raymond Martin-2]

Dear Dimiter,

> Some of the discourse so far is based in fact on social phenomena.
>
> 1) Forking is a matter of culture. We try to avoid forking because we all
>  support the role of Wayne as the "guru/patriarch" of ImageJ. Some people
>  here may start arguing about Fiji. I personally admire the efforts of the
>  Fijians to maintain a centralized plugin repository and will promote this
>  idea for another plugin repository. But we should avoid asking Fiji to
>  contain "everything but the kitchen sink" so I leave for it the field for
>  3D reconstructions, image stitching, axonal tracking etc. Fiji is clearly
>  not meant for bio-medical imaging, which I already do for some time at
>  IMEC and is also supported by the Santec group. It is also not meant for
>  DB integration and results management and so on. But what we need to
>  preserve is the common core functionality of ImageJ so that different
>  projects could interoperate in such way as the different Linux distros are
>  built on top of the same kernel.

There is a book I read a few years ago entitled "Innovation Happens
Elsewhere". It is written by a Sun software engineer who works on Java and it
is all about free open source software and the practices of the projects
that follow it.

One point that is very clear to me from that is that when you attempt to
prevent forks you actually cause them to some degree. I have seen this in
practice and the writer points out that the proper thing to do when faced with
a fork is to welcome it, give it space on your servers, a branch in SCM and so
forth. There is already some of this type of acceptance happening with ImageJ.
I consider this a good thing.

In other words, do not alienate potential contributors by attempting to be
exclusionary, it does not work. To move towards curtailing forks or pulling
development towards a core has the potential to repel as well as attract.

And you are right, forking is a matter of culture. It is a central part of
the free open source software culture. ImageJ is a part of that.

I think if people want to contribute directly to the core it will happen,
naturally. Many successful FOSS projects that exist prove this without
using force.

Also consider that forks may arise due to inability to get functionality into
the core of a project. A developer may be given no alternative if they
have desirable functionality that the core does not accept. What can
they possibly do once they have exhausted the route of communication
to try to convince others that the functionality is required, desired, useful,
better... It becomes a decision point. Should they throw their ideas/code
away? They would be stuck if it were a proprietary application. But for
FOSS they have been given the freedom to fork as an option. So this
forking is very much a safety mechanism to prevent the loss of good ideas and
allow them to flow.

To try to prevent forks is to cut off potential enhancements that you
would never know exist if it were closed source software.

> 3) In view of all said, I suggest that we have to assemble a list of
>  plugins that need to be maintained and stop caring much about the rest.
>  Good starting points for this are the ImageJ site plugins, the Fiji
>  plugins and the plugins on the IJ Wiki site. Of course such a list should
>  not be set in marble ;) and if other plugin programmers agree to
>  upgrade/maintain their plugins a mechanism for this should be foreseen.

Good idea. Some kind of table with parameters indicating status, last update,
and so on that the maintainers of the plugins can edit also.

Cheers,

Raymond

[dscho]

Hi,

On Mon, 14 Dec 2009, Frederic V. Hessman wrote:

> >2) Pursuing 100% backward compatibility is not tenable in the long run.
> >   What we can do is to start up an new PluginPlus or whatever
> >   interface, and not touch the old ones. With time we can depreciate
> >   the old Plugin interface so that the development will turn gradually
> >   to the new pattern. So at this point I agree with Raymond.
>
> If the new data model is flexible enough (and it better be), then it may
> be feasible to make things like ImagePlus a particular sub-class of
> SuperDuperImage, in which case most plugins may work with practically no
> changes.  The ImagePlus/ImageStack/HyperStack/.... model is very
> primitive, after all.  I
>
> 'm not complaining, just thinking about what would be possible if ImageJ
> supported all the data models and world coordinate systems of just the
> FITS standard (generalized hyperstacks, highly non-linear coordinates,
> all known map-projections).

Now, now.  Recently there has been a flurry of mails that contain a lot of
buzzwords, and not so much substance to back it up.  IMHO you should not
say that a certain model is very primitive unless you have come up with a
superior model _before_ shouting about.

Likewise, even if I agree that a powerful library can be wrapped into a
backwards-compatible library, if you cannot substantiate your claim by
evidence, I would suggest producing that evidence first.

Oh, and please tell who you are quoting.  It is only because I followed
the thread that I know that you are quoting Dimiter.  In science, we have
this long tradition of citing our sources properly, let's not forget that
on this mailing list, either.

Ciao,
Dscho

[Raymond Martin-2]

Hi Paolo,

> sorry, i'm confused ... but in debian, right now we have:
>
> usr/share/imagej/plugins
> usr/share/imagej/macros
> usr/share/imagej/luts
>
> default path points to:
> ij_path=/usr/share/java
>
> and this is for the system wide imagej, then for the single user we add:
> $ij_user_path/plugins
> $ij_user_path/macros
> $ij_user_path/luts
>
> finally the loooong imagej.sh wrapper merge both ...

Of course it works, yes. But it is unnecessary if just a relatively small
amount of configuration code is added to ImageJ to take care of all the
default situations that occur across the major operating systems.

Not having this default configuration code prevents ImageJ from being packaged
up in a straight-forward manner, without much, if any, changes. And then just
working properly, something I have been able to do with other Java
applications for years when getting them to run on Linux, Mac OS X, and
Windows at least.

Regards,

Raymond

[Frederic V. Hessman]

(my reply didn't make it to the list the first time)

>>> I'm not complaining, just thinking about what would be possible if  
>>> ImageJ
>>> supported all the data models and world coordinate systems of just  
>>> the
>>> FITS standard (generalized hyperstacks, highly non-linear  
>>> coordinates,
>>> all known map-projections).
>>
>> ... IMHO you should not
>> say that a certain model is very primitive unless you have come up  
>> with a
>> superior model...

I'd be happy to ablidge.   These things were taken care of (literally)  
ages ago in astronomy - being a small, global community, we needed  
good standards early on:

- generalized hyperstacks (1981)
        http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1981A%26AS...44..371G&db_key=AST&high=3db47576cf05893

- generalized tables (1995)
        http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1995A%26AS..113..159C&db_key=AST&high=3db47576cf06210

- generalized coordinates (2002)
        http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2002A%26A...395.1061G&db_key=AST&high=3db47576cf06933

- every known map-projection (2002)
        http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2002A%26A...395.1077C&db_key=AST&high=3db47576cf06933

Of course, this is just a data-representation made for storage (that's  
what the FITS standard is all about), but the appropriate properties  
of a generalized data model are well illustrated by the constraints  
placed on being able to store such data.  The FITS header mechanism is  
primitive but easy to use and makes the bookkeeping associated with  
generalized hyperstacks/tables/coordinates/world-coordinate-systems  
fairly manageable (and is much more powerful than that used in TIFF or  
JPEG).

Since most of you are interested in plain imaging (even if it is n-
dimensional), it was natural that ImageJ only supported the simplest  
data forms, but once you get to know and love (!) ImageJ, you want to  
be able to do other things as well.

Rick

[David Webster]

All,

So, why can't we have 100% backward compatibility?

Are changes that would preclude this really all that necessary?

David Webster

On Mon, Dec 14, 2009 at 10:15 AM, Frederic V. Hessman <
[hidden email]> wrote:

> (my reply didn't make it to the list the first time)
>
>   I'm not complaining, just thinking about what would be possible if
>>>> ImageJ
>>>> supported all the data models and world coordinate systems of just the
>>>> FITS standard (generalized hyperstacks, highly non-linear coordinates,
>>>> all known map-projections).
>>>>
>>>
>>> ... IMHO you should not
>>>
>>> say that a certain model is very primitive unless you have come up with a
>>> superior model...
>>>
>>
> I'd be happy to ablidge.   These things were taken care of (literally) ages
> ago in astronomy - being a small, global community, we needed good standards
> early on:
>
> - generalized hyperstacks (1981)
>
> http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1981A%26AS...44..371G&db_key=AST&high=3db47576cf05893
>
> - generalized tables (1995)
>
> http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1995A%26AS..113..159C&db_key=AST&high=3db47576cf06210
>
> - generalized coordinates (2002)
>
> http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2002A%26A...395.1061G&db_key=AST&high=3db47576cf06933
>
> - every known map-projection (2002)
>
> http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2002A%26A...395.1077C&db_key=AST&high=3db47576cf06933
>
> Of course, this is just a data-representation made for storage (that's what
> the FITS standard is all about), but the appropriate properties of a
> generalized data model are well illustrated by the constraints  placed on
> being able to store such data.  The FITS header mechanism is primitive but
> easy to use and makes the bookkeeping associated with generalized
> hyperstacks/tables/coordinates/world-coordinate-systems fairly manageable
> (and is much more powerful than that used in TIFF or JPEG).
>
> Since most of you are interested in plain imaging (even if it is
> n-dimensional), it was natural that ImageJ only supported the simplest data
> forms, but once you get to know and love (!) ImageJ, you want to be able to
> do other things as well.
>
> Rick
>

[Raymond Martin-2]

Hi David,

> So, why can't we have 100% backward compatibility?
>
> Are changes that would preclude this really all that necessary?

The reason is that it is impossible to know how to make something 100%
backwards compatible without doing experiments first. Nobody knows exactly
what the functionality is yet, therefore there is no way to determine if full
backwards compatibility is possible.

Moving forward in software is a process of discovery, plus in another few
years, 5 or 10 maybe, reinvention of at least some parts of the program will
have to be done again because that is the nature of computer science/software
engineering, domains that are still very much in their infancy. It is just
going to keep moving and changing. And users are going to want newer,
better functionality due to the needs of the domains they are applying the
application to.

So it is really about how the need for change is handled and not about whether
it is needed.

Raymond

[Paul Johnston]

I agree with Raymond, people should not resist or fear change.  To
demand 100% backwards compatibility forever ultimately would doom any
software project, because it assumes that all potential problems were
conceived and accounted for at the initial design.  Furthermore it
assumes that the world outside the system never changes either, which
is of course false.  Just as fire is a natural part of a forest
ecosystem, refactoring and redesign is a normal part of software
development.  Plus, if people are using specific plugins that are no
longer being developed, there is no need to upgrade the core imagej
for that use case.

But all this talk doesn't really matter anyway, because its the code
that speaks for itself, and the number of downloads/interest that
decides.  So people should spend more time just doing what they are
good at and not worry so much about the outcome, like it or not, it
will decide itself.

For me, each experiment that I do which has a dependency on imagej
gets the core and required plugin set placed in source control
alongside my imaging data.  That way I always know that I can go back
and be able to repeat the analysis without worrying about other things
changing.

Paul

On Mon, Dec 14, 2009 at 12:50 PM, Raymond Martin <[hidden email]> wrote:

> Hi David,
>
>> So, why can't we have 100% backward compatibility?
>>
>> Are changes that would preclude this really all that necessary?
>
> The reason is that it is impossible to know how to make something 100%
> backwards compatible without doing experiments first. Nobody knows exactly
> what the functionality is yet, therefore there is no way to determine if full
> backwards compatibility is possible.
>
> Moving forward in software is a process of discovery, plus in another few
> years, 5 or 10 maybe, reinvention of at least some parts of the program will
> have to be done again because that is the nature of computer science/software
> engineering, domains that are still very much in their infancy. It is just
> going to keep moving and changing. And users are going to want newer,
> better functionality due to the needs of the domains they are applying the
> application to.
>
> So it is really about how the need for change is handled and not about whether
> it is needed.
>
> Raymond
>

[Thomas Boudier]

Hello,

For FITS and WCS I would like to report the existence of SalsaJ, a
ImageJ based software for astronomy, we introduced the FITS reading and
the WCS display by using the skyview library.

The program is available at : http://www.euhou.net/

For information this is a simplified version of ImageJ for use in
high-schools which has been translated to many languages. A updated
version will be available soon.

Thomas



Frederic V. Hessman a écrit :

> (my reply didn't make it to the list the first time)
>
>>>> I'm not complaining, just thinking about what would be possible if
>>>> ImageJ
>>>> supported all the data models and world coordinate systems of just the
>>>> FITS standard (generalized hyperstacks, highly non-linear coordinates,
>>>> all known map-projections).
>>>
>>> ... IMHO you should not
>>> say that a certain model is very primitive unless you have come up
>>> with a
>>> superior model...
>
> I'd be happy to ablidge.   These things were taken care of (literally)
> ages ago in astronomy - being a small, global community, we needed good
> standards early on:
>
> - generalized hyperstacks (1981)
>     http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1981A%26AS...44..371G&db_key=AST&high=3db47576cf05893 
>
>
> - generalized tables (1995)
>     http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1995A%26AS..113..159C&db_key=AST&high=3db47576cf06210 
>
>
> - generalized coordinates (2002)
>     http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2002A%26A...395.1061G&db_key=AST&high=3db47576cf06933 
>
>
> - every known map-projection (2002)
>     http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2002A%26A...395.1077C&db_key=AST&high=3db47576cf06933 
>
>
> Of course, this is just a data-representation made for storage (that's
> what the FITS standard is all about), but the appropriate properties of
> a generalized data model are well illustrated by the constraints  placed
> on being able to store such data.  The FITS header mechanism is
> primitive but easy to use and makes the bookkeeping associated with
> generalized hyperstacks/tables/coordinates/world-coordinate-systems
> fairly manageable (and is much more powerful than that used in TIFF or
> JPEG).
>
> Since most of you are interested in plain imaging (even if it is
> n-dimensional), it was natural that ImageJ only supported the simplest
> data forms, but once you get to know and love (!) ImageJ, you want to be
> able to do other things as well.
>
> Rick
>
>

--
   /**********************************************************/
      Thomas Boudier, MCU Université Pierre et Marie Curie,
      IFR 83. Bat B 7ème étage, porte 706D, Jussieu.
      Tel : [phone]  Fax : [phone]
/*******************************************************/

[dscho]

Hi Thomas,

On Tue, 15 Dec 2009, Thomas Boudier wrote:

> For FITS and WCS I would like to report the existence of SalsaJ, a ImageJ
> based software for astronomy, we introduced the FITS reading and the WCS
> display by using the skyview library.
>
> The program is available at : http://www.euhou.net/

Funny!  I came upon this software a few days ago, but I failed to find the
source code.  Do you have a pointer?  I would like to look into the
changes and see whether we can pick a few nice cherries from there.

Ciao,
Dscho