FigureJ

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

FigureJ

dscho
Hi Jérôme (and other FigureJ fans),

I finally had time to play with FigureJ. Nice job! It provides important
functionality and is most likely going to be a very important tool for my
work.

Since you seemed to prefer feedback over code contributions when we talked
about open software development in Luxembourg, here a couple of comments
instead:

- the user interface is mostly intuitive, however, I had to watch a video
  tutorial (without sound because of a quiet office) to know how to resize
  the selection. Handles (these little white boxes on ImageJ selections'
  corners) would help that tremendously.

- likewise, I did not think of the "OK" button to get the image into the
  panel. I closed the image instead; that did not do what I expected...
  maybe it should?

- speaking of resizing the selection: it is always relative to the center.
  Sometimes it is easier to resize relative to a corner or a side, though,
  e.g. for screenshots.

- at one stage I had a FigureJ selection (i.e. this red-blue rectangle) in
  the FigureJ window itself.  That was a bit distracting, and I was only
  able to remove it via the Image>Overlay menu. I *think* it was triggered
  by my clicking on some FigureJ tool icons in the toolbar while the FigureJ
  window was in the foreground.

- I Mavenized the source code, just to see whether it was really hard
  (spoiler: it wasn't, see https://github.com/dscho/FigureJ). It
  demonstrated a problem: since IJ 1.47g, the ColorPicker is no longer a
  Frame, but a Dialog. Thus, the code did not compile, and it cannot reuse
  the color picker in any case (WindowManager.getFrame("CP") will never be
  able to obtain the color picker anymore).

- there appear to be 3 different panels involved, the New/Open/Save one,
  the one containing the "open image" button and the one to add labels and
  scale bars. Would it not be nicer to have a single window with
  appropriately grayed-out fields?

- double-clicking on a panel could open the image... that would make it a
  bit more intuitive than having to get the Figure Control panel into the
  foreground and to click the "open image" button.

- when I clicked "open image", it would automatically open the Macro
  Recorder, too. A bit distracting...

- speaking of the Options panel: it looks quite different from the video
  tutorial... maybe worth updating?

- just like the three different panels, I imagine it'd be better to have a
  single tool, not three (I did not figure out what the second tool was
  meant to do anyway)? Double-clicking that tool could bring the FigureJ
  panel into focus.

- at some stage I had to reorder the images. It would be nice if a drag 'n
  drop would exchange panels' images (and I'd suggest to keep the zoom
  factor and the center intact in case of different panel dimensions, so
  that exchanging two panels again would undo the exchange). Even looking
  at the source code of the serialized .figurej file does not seem to help
  because the LeafPanel class conflates the information about the position
  in the figure with the information about what is displayed there.

- speaking of serialization: it often looks like a neat way to solve the
  storage problem. That overlooks the fact, though, that it essentially
  prevents any future changes in the data structures (otherwise the
  serialized data cannot be read).

- speaking of drag 'n drop: it is nice that the panels can be resized by
  dragging the separator lines. However, I had to watch a video tutorial
  to know that I can do that. It might be a good idea to change the cursor
  when it hovers on top of a separator, to double-arrows (as it is the
  case for so many existing programs where a separator can be moved).

- should the "remove" button in the label panel not decrease the label
  counter so that drawing an "A", removing it, and then clicking the
  "draw" button again would draw an "A" again instead of a "B"?

- the Alt+Click to reset the label counter is too magic (read:
  unintuitive), and it does not even work on Linux: you have to hit
  Ctrl+Alt+Click. It should be a "reset" button; that would make things
  intuitive.

- the labels can be hard to read. Maybe an option to display them in
  Outline mode (i.e. add a background-colored border by using dilation)
  would help.

- speaking of labels: quite often, I find myself wanting to add labels to
  all panel at the identical location, "numbered" in the order we read and
  write English: left-to-right, top-to-bottom (in that order). Maybe there
  could be an option for that, too?

- I saw that "Image>Get Info" on the FigureJ window shows a bit of
  information about the current figure, but I did not see a way to
  reinitialize FigureJ from that info (that is stored e.g. when writing as
  TIFF). Maybe a good idea?

I will stop here because I realize that it is already a metric ton of
feedback that you might want to digest before I go on... ;-)

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: FigureJ

dscho
Hi Jérôme (and other FigureJ fans),

On Thu, 4 Apr 2013, Jerome Mutterer wrote:

> Thank you very much for your email, and for trying FigureJ.  You are
> raising many points, most of which I agree with. Here are some further
> comments:
>
> On 3 April 2013 17:56, Johannes Schindelin <[hidden email]>wrote:
>
> > I finally had time to play with FigureJ. Nice job! It provides
> > important functionality and is most likely going to be a very
> > important tool for my work.
> >
> > Since you seemed to prefer feedback over code contributions when we
> > talked about open software development in Luxembourg, here a couple of
> > comments instead:
>
> I appreciate feedback a lot and will do my best to fixe issues and add
> new features, but patches and code contributions are also most welcome,
> as they will accelerate things. I like the code being now more
> accessible in Github, so that more potential contributors can look at
> it.
>
> > - the user interface is mostly intuitive, however, I had to watch a
> > video tutorial (without sound because of a quiet office) to know how
> > to resize the selection. Handles (these little white boxes on ImageJ
> > selections' corners) would help that tremendously.
>
> Handles on selection tool and custom cursors changes over separators are
> very good ideas.
>
> > - likewise, I did not think of the "OK" button to get the image into
> > the panel. I closed the image instead; that did not do what I
> > expected...  maybe it should?
>
> How about changing the OK button label to 'Transfer' ?
I still think that closing the window should update the panel. The best
idea may be to do away with the button altogether, but ask the user upon
closing the window whether the changes should actually be reflected in the
panel.

> > - speaking of resizing the selection: it is always relative to the
> > center.  Sometimes it is easier to resize relative to a corner or a
> > side, though, e.g. for screenshots.
>
> This could be done with a modifier key.

Yes, but it would not be intuitive. While I really plan to use FigureJ
extensively, it would not be frequent enough to remember magic key
combinations.

> > - at one stage I had a FigureJ selection (i.e. this red-blue
> > rectangle) in the FigureJ window itself.  That was a bit distracting,
> > and I was only able to remove it via the Image>Overlay menu. I *think*
> > it was triggered by my clicking on some FigureJ tool icons in the
> > toolbar while the FigureJ window was in the foreground.
>
> I was hoping this bug to be gone now. It never happens on macs. Was this
> on Windows or Linux ?

Linux.

> - I Mavenized the source code, just to see whether it was really hard
> >   (spoiler: it wasn't, see https://github.com/dscho/FigureJ). It
> >   demonstrated a problem: since IJ 1.47g, the ColorPicker is no longer
> >   a Frame, but a Dialog. Thus, the code did not compile, and it cannot
> >   reuse the color picker in any case (WindowManager.getFrame("CP")
> >   will never be able to obtain the color picker anymore).
>
> I will address this and change the whole coloring picking for separator
> colors to just using the current foreground color.

Good idea!

> > - there appear to be 3 different panels involved, the New/Open/Save
> > one, the one containing the "open image" button and the one to add
> > labels and scale bars. Would it not be nicer to have a single window
> > with appropriately grayed-out fields?
>
> The New/Open/Save buttons should be in the main panel, I agree. To save
> screen estate, the options panel could maybe be moved to a tabbed pane
> of the main panel as well.

I would not mind the Figure Control panel to be double as wide as it is
right now...

> > - double-clicking on a panel could open the image... that would make
> > it a bit more intuitive than having to get the Figure Control panel
> > into the foreground and to click the "open image" button.
>
> I like this idea:  if the image close button would be used instead of
> the 'OK' button, and double click instead of 'open image', we could even
> get rid of those two buttons.
>
> - when I clicked "open image", it would automatically open the Macro
> >   Recorder, too. A bit distracting...
>
> The recorder is supposed to be started and hidden. It is required to log
> actions done during panel selection. I can not see it on my mac.
How about adding a CommandListener instead? That way, you won't rely on
the Macro Recorder. I closed it everytime it popped up, so FigureJ could
not have used it anyway.

> > - speaking of the Options panel: it looks quite different from the
> > video tutorial... maybe worth updating?
>
> I will record a new video with the latest version.

Thanks.

> > - just like the three different panels, I imagine it'd be better to
> > have a single tool, not three (I did not figure out what the second
> > tool was meant to do anyway)? Double-clicking that tool could bring
> > the FigureJ panel into focus.
>
> This second tool snaps an existing rectangle selection to panels
> borders.  (useful for placing insets)

Sorry, I am a bit slow... I do not understand ;-)

> > - at some stage I had to reorder the images. It would be nice if a
> > drag 'n drop would exchange panels' images (and I'd suggest to keep
> > the zoom factor and the center intact in case of different panel
> > dimensions, so that exchanging two panels again would undo the
> > exchange). Even looking at the source code of the serialized .figurej
> > file does not seem to help because the LeafPanel class conflates the
> > information about the position in the figure with the information
> > about what is displayed there.
>
> You are right, there is currently no way of re-building the entire
> figure from the panels information and datasource. That is also why
> panels with content get resized, but image content is not updated, you
> have to use the 'open image', 'ok' sequence to choose a new source
> region. What I could do is exchange datasources upon drag and drop, and
> trigger selection windows for each affected panel. The point is: the
> same zoom factor and center cannot always be achieved with panels of
> different form factors.
Yes, what I meant is: do not preserve the same view upon exchanging, but
keep the actual zoom factor and the center. That means if you move an
image from a large to a small panel, it would now show less of the
original image.

> > - speaking of serialization: it often looks like a neat way to solve
> > the storage problem. That overlooks the fact, though, that it
> > essentially prevents any future changes in the data structures
> > (otherwise the serialized data cannot be read).
>
> I get this but have no better solution for now.

Basically, what we need to do is invent our own data format. I imagine
that an XML-based format would be the easiest to use (from a Java point of
view). Something like:

        <figurej width=8 height=6 unit=cm dpi=600>
                <panel x=0 y=0 width=300 height=250>
                        <image name=hello-world.png
                                centerX=300 centerY=200 zoom=1.54 angle=0.48/>
                        <label letter=A position=bottom-left ...
                </panel>
                ...
        </figurej>

I would also put this complete description into the image info; that way,
starting FigureJ could inspect the current image (if any) and detect
whether it is a Figure. That might require full image paths to be stored
in the XML, though.

> > - speaking of drag 'n drop: it is nice that the panels can be resized
> > by dragging the separator lines. However, I had to watch a video
> > tutorial to know that I can do that. It might be a good idea to change
> > the cursor when it hovers on top of a separator, to double-arrows (as
> > it is the case for so many existing programs where a separator can be
> > moved).
>
> I will add this.

Thanks!

> > - should the "remove" button in the label panel not decrease the label
> > counter so that drawing an "A", removing it, and then clicking the
> > "draw" button again would draw an "A" again instead of a "B"?
>
> We had this in an early version. It would work only when you remove the
> last added label. If you remove another one, things get worse. That is
> why I added the alt-click reset of the label counter, which, I agree is
> hard to guess.

Maybe the easiest would be to have a running counter as a text field. That
way, the user can not only see what is next, but also reset herself.

> > - the Alt+Click to reset the label counter is too magic (read:
> > unintuitive), and it does not even work on Linux: you have to hit
> > Ctrl+Alt+Click. It should be a "reset" button; that would make things
> > intuitive.
> >
> > - the labels can be hard to read. Maybe an option to display them in
> > Outline mode (i.e. add a background-colored border by using dilation)
> > would help.
>
> Would be nice to have. Labels are now overlaid text rois, so I do not
> see an easy way of achieving that.
Would be possible as ImageRois using zero as transparent.

> > - speaking of labels: quite often, I find myself wanting to add labels
> > to all panel at the identical location, "numbered" in the order we
> > read and write English: left-to-right, top-to-bottom (in that order).
> > Maybe there could be an option for that, too?
> >
> > - I saw that "Image>Get Info" on the FigureJ window shows a bit of
> > information about the current figure, but I did not see a way to
> > reinitialize FigureJ from that info (that is stored e.g. when writing
> > as TIFF). Maybe a good idea?
>
> Those two remarks can be answered together: the basic info in the tif
> metadata is there to provide a basic way of targeting panels from
> macros.  I'm reading it like this:
>
> infos = getMetadata('info');
> lines = split (infos,'\n');
> for (i=0;i<lines.length;i++) {
>  line = split(lines[i],',');
> if (line.length>3) {
>  x= line[0];y= line[1];
> w= line[2];h= line[3];
> makeRectangle(x,y,w,h);
>  // or do whatever you like here
> }
> }
>
> You can use this approach to label panels automatically, or fill them with
> random colors, or fill them with a list of images, or with every Nth frame
> of a video, etc.
I agree that it would be nice to have FigureJ macro-scriptable better. But
the way you described does not even allow tilted rectangular selections,
so I imagine that a call() based approach might be better.

OTOH the rectangle selection tool could be enhanced to allow tilted
selections to begin with ;-)

> > I will stop here because I realize that it is already a metric ton of
> > feedback that you might want to digest before I go on... ;-)
>
> Thanks a lot for all these ideas. I hope I can achieve some of them. At
> least they are now on my to-do list :-)

Thanks for that! It would probably have been easier for me to contribute
code patches for some fundamental things such as the serialization at an
eariler stage, but I will see what I can do. This month is crazy,
though...

Ciao,
Johannes

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