Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
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' ? ... [show rest of quote] ... [show rest of quote] 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. 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. ... [show rest of quote] ... [show rest of quote] 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. > > - 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. ... [show rest of quote] ... [show rest of quote] 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 |
Free forum by Nabble | Disable Popup Ads | Edit this page |