On Sun, 7 Jun 2009, Johan Henriksson wrote:
> I think there is plenty of interest but taking the step to start
> developing is huge. there is light in the end of the tunnel though. my
> perspective is that fixing imagej entirely will break backward
> compatibility with all plugins, but the plugins are the reason imagej is
> still popular (except the lack of alternatives). hence only smaller
> fixes are worthwhile. there are two routes:
>
> * The Fiji project (http://pacific.mpi-cbg.de/wiki/index.php/ Main_Page)
> if you want to keep using imagej and are fine with fine-tuning, then
> maybe you should join this very active community
>
> * The next generation imaging software, such as my own Endrov
> (www.endrov.net) if you want to address core issues such as bad 4d
> support, metadata etc then you have to look at entire rewrites. there
> are several attempts on the way. I aim to have the first non-beta
> release of Endrov out in a 3 months, and it solves all the problems
> that I have seen float up in the discussions here.
There is a thirds option. You _can_ stay backwards-compatible, adding a
new interface to ImageJ _without_ breaking backwards compatibility.
We are just about releasing something like imagescience.jar in Fiji, just
way better:
- it does not break backwards-compatibility (no need to reimplement what
already works),
- it is an interface to image data that makes it easy not to care about
the dimensionality and data type of the images,
- it is efficient, using Java 1.5's generics to the full extent, and
- it does not implement a new GUI with its own set of shortcomings, but
continues to use the GUI people are used from ImageJ (possibly enhancing
it incrementally),
- oh, and it is Open Source (which is way superior than a closed-source
component you have to beg to be enhanced).
Ciao,
Dscho
On Mon, 8 Jun 2009, wil...@ieee.org wrote:
> this sounds interesting - can you share any more information and/or give
> API examples?
As I said: soon.
Ciao,
Johannes
On Wed, 22 Jul 2009, Curtis Rueden wrote:
> On Jul 22, 9:03 am, Johan Henriksson <he.jo...@gmail.com> wrote:
>
> > On Tue, Jul 21, 2009 at 7:50 PM, wil...@ieee.org <wil...@ieee.org> wrote:
> >
> > > Yes, but I still hope that the general discussion will not be halted
> > > by a single announcement (which should eventually materialize though).
> >
> > > On Jul 8, 8:16 pm, Grant <ghar...@mbl.edu> wrote:
> > > > Johannes --
> > > > We're waiting! We're waiting!
> > > > Anything new on your project?
Oh, I missed that mail.
The problem on this side is time.
Ciao,
Dscho
Hi Johan et al,
In some ways, that's what the ImageJ list accomplishes. People write
> * most importantly, use cases: "I want to do X with Y to obtain Z". a very
> detailed list, it should be possible to verify that it is possible with a
> particular software. this would speed up development a lot
all the time asking how to do X with Y to obtain Z, and they usually
get responses. If we were to compile a more formal list, we would need
a list of people (us?) who contribute items, and another list of
people (also us?) who review which items on the list are possible/
implemented/done, and how to proceed with items that need work.
I don't think it need be more formal than a wiki; some people need just take
care of cleaning up once in a while though. since we have several projects,
some overlapping, it's not as easy as just keeping bug track and tick of the
items. we could just add comments and/or tutorial links once anyone has written a tool.
Also, it is worth mentioning that often with ImageJ the answer to "Can
I do X with Y to obtain Z" is "Yes, but... you have to write a plugin/
macro/etc." For many use cases, that is a fine answer. But for very
common cases, we obviously want to make it simpler than that.
indeed, at the same time we have to spend our resources to maximize rate of
interest. a voting system would be optimal. is there a bugtracker allowing editing
of posts and with voting?
The ITK (Insight Toolkit) community has attempted to tackle this
problem using their Insight Journal: http://www.insight-journal.org/
thanks for the link!
Good idea. ImageJ has a nice start with its "Open samples" list,
> * a compiled set of images that can be used to benchmark algorithms and
> software
though it would be nice if it were tweakable with a configuration file
somewhere.
* it's rather low on 3d and 3d+t recordings
* no weird formats (zips)
* license information should be clarified
* a simple formalized .xml metadata file for each image, so any software can autodetect what should be under "open samples"
I think this could be started up not too heavy duty; we just need some web
space and someone to hand out accounts. I could contribute this.
so who's on? does anyone have a diverse set of images to contribute? I have
lots of images, but all of the same thing :(
/Johan
On Fri, 24 Jul 2009, Dimiter Prodanov wrote:
> I see that the discussion is again restarted. So I propose to collect
> the ideas/options in a design-like document in Google Doc rather that
> shooting back and forth e-mails.
TBH I could not care less about the mode of writing said document, and
absent any content, I cannot see why emails should not be good enough.
I am much more interested in _content_. So far, only Curtis provided
some concrete ideas.
(Well, if you ignore my _negative_ wish: I sincerely believe that breaking
backwards-compatibility will cost you _dearly_ in terms of users -- not
only numbers, but also support by them -- but then, I am convinced that
breaking backwards-compatibility is not necessary at all)
Ciao,
Dscho
On Thu, 30 Jul 2009, Curtis Rueden wrote:
> We will hear back about our GO grant proposal very soon (early August, I
> think). Once we know how it fared, I will reply back to the list.
That's wonderful!
> Regarding "concrete ideas," I spelled out some technical aims in the
> proposal, which I would be glad to reiterate here. Ultimately though,
> the only way to get completely precise will be to start actually trying
> the proposed changes on the codebase, and seeing what the consequences
> are.
FWIW we have something _preliminary_ -- without documentation or code
samples, and not even complete yet, in our 'imagecontainer1' branch in
fiji.git.
The idea is to have Type instances that wrap the data type (by "wrap" I
do not mean that they extend java.lang.Integer and friends -- that would
be horrible in terms of memory complexity! -- but rather that those Type
instances can hold a value and contain methods to do basic arithmetic
with the values), Container instances that wrap whatever memory/disk
layout your image (hyper-)stack wants to have, and Cursor instances that
traverse the containers.
A (very small) example: this will create a 2x2x2 float image and fill it
with increasing values:
FloatTypeImage img =
factoryFloat.createImage(new int[]{2, 2, 2},
"2D Float Test image" );
Cursor<FloatType> c = img.createCursor();
int i = 1;
while ( c.hasNext() )
{
c.fwd();
c.getType().set( i );
i++;
}
ImageJFunctions.displayAsVirtualStack( img,
ImageJFunctions.GRAY32 ).show();
We will have to fiddle with the interfaces, of course, and do some
profiling (as it appears that at least in a few cases, there are a few
percent between the runtime of our container-based algorithm and an
implementation using basic types).
The idea, of course, is to allow implementations of algorithms that are
independent of the data type, but which are still readable (even more so,
I would contend, as all the cruft of nested loops with different indices
that can be confused, and calculations from pixel coordinates into array
indices that can be wrong) and fast.
Ciao,
Johannes
On Thu, 13 Aug 2009, wil...@ieee.org wrote:
> is there any way to browse the corresponding source code without
> downloading Fiji?
Yes. As mentioned on the Wiki (third paragraph, the link to the
"repository"), following "fiji.git" into the "imagecontainer1" branch:
http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=fiji.git;a=shortlog;h=refs/heads/imagecontainer1
But as with all source code, you have an easier time figuring out what is
going on if you download it and play with it.
Note that I picked up work on it yesterday, but due to technical reasons
am no able to push the changes to pacific.
Ciao,
Dscho
On Fri, 14 Aug 2009, Dimiter Prodanov wrote:
> Hi Stephan,
He probably missed your mail, as you did not Cc: or To: it to him.
> Which project do you comment now?
> the imagecontainer or something else?
Obviously about the imagecontainer.
Please note that this is in _heavy_ flux; it does not even compile at the
moment, as Stephan and me worked on it, and he decided to take a
completely different course from what I originally envisaged for the
ImagePlus adaption.
So maybe the best would be to wait a few days until I cleaned up the stuff
for proper inclusion into Fiji and started writing an introduction on the
Fiji Wiki.
Of course, the project is almost independent of the current ImageJ
version; that was the whole idea, right? It's just a thin wrapper on top
of ImagePlus just so we do not need to lose existing customers. Because a
project without customers is like a fish without bike.
Ciao,
Dscho
We will hear back about our GO grant proposal very soon (early August, I think). Once we know how it fared, I will reply back to the list. Regarding "concrete ideas," I spelled out some technical aims in the proposal, which I would be glad to reiterate here. Ultimately though, the only way to get completely precise will be to start actually trying the proposed changes on the codebase, and seeing what the consequences are.