<div dir="ltr">Thank you for this detailled answer Curtis !</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><br>--<br>Hadrien Mary<div><br></div><div>Ph.D student in Biology</div><div>Tournier-Gachet Team</div>
<div>CNRS - LBCMCP - UMR 5088<div><div><br></div><div><div>Université de Toulouse - Bât. 4R3B1</div><div>118, route de Narbonne - 31062 Toulouse</div></div></div></div></div></div>
<br><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 9:28 PM, Curtis Rueden <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Hadrien,<div><br></div><div>[Cross-posting with imagej-devel since this discussion is relevant there too.]</div><div class="im"><div><br></div><div><div>> My problem is when for example I duplicate or make a z projection on</div>
<div>> an OME Tiff file under data browser, the new viewer will be hyperstack</div><div>> (IJ/Fiji default viewer). However if I export the file with LOCI</div><div>> exporter and then I re open it with LOCI importer I can still have</div>
<div>> data browser and OME metadata are here as well.</div></div><div><br></div></div><div>Ah. So at minimum, what you need is a way to wrap an ImageJ hyperstack back into a Data Browser window again. You can do that with this Beanshell one-liner:</div>
<div><br></div><div> new loci.plugins.util.DataBrowser(IJ.getImage());<br></div><div><br></div><div>Paste that line into the script editor and save as (e.g.) data-browser.bsh. When you run it, the currently active image window will be converted to a Data Browser window.</div>
<div><br></div><div>You can even install the script into the menus and map a shortcut key to it, although of course that's still not completely automatic. For a totally seamless override of the default image viewer you'll have to wait for IJ2.</div>
<div class="im">
<div><br></div><div><div>> It really awesome if you can backport some IJ2 features to Fiji 1</div><div>> since IJ2 won't be released before at least one year from what I</div><div>> saw...</div></div><div><br>
</div></div><div>Yes, we are working toward more of a gradual release schedule. Rather than releasing "ImageJ2" as one monolithic thing (which it really isn't), we want to start integrating the already polished parts of it into Fiji as soon as possible. We are currently working on the "legacy" interoperability layer to facilitate this.</div>
<div class="im">
<div><br></div><div><div>> are you considering in a mid/long term to merge Fiji/IJ2 ? Does it</div><div>> make really sense to separate both ? I think it would be best for</div><div>> everyone (devs and users) to have only one place for download and</div>
<div>> development so you would have a better visiblity and it will be much</div><div>> more clear for potential contributors or bug reporters to know where</div><div>> they need to go</div></div><div><br></div>
</div><div>
That is essentially what we are doing, yes. ImageJ2 is the core software; several parts of Fiji core infrastructure have migrated into ImageJ2. So at heart, Fiji is now a big collection of life sciences plugins -- i.e., an ImageJ update site. As such, you can currently obtain a working Fiji installation by downloading ImageJ2, running the updater, and toggling the Fiji update site.</div>
<div><br></div><div>Fiji and ImageJ2 are fundamentally the same software, using the same launcher. It's just that if you download "Fiji" and run it, it currently starts up in ImageJ1 mode at the moment. But Fiji ships with ImageJ2 and you can launch it in that mode instead if you prefer -- or switch to ImageJ2 mode after launching using the "Switch to Modern Mode" command under the Help menu.</div>
<div><br></div><div>Ultimately, we probably do not want to get rid of the two distinct web sites and project names though, since people are familiar with both. That said, we are integrating resources when feasible: e.g., <a href="http://wiki.imagej.net" target="_blank">wiki.imagej.net</a> and <a href="http://fiji.sc" target="_blank">fiji.sc</a> are really both the same wiki with a different skin, to make cross-linking more seamless. But we want to ensure it is clear that ImageJ2 is not a life-sciences-specific project, whereas Fiji is. Historically, because Fiji has a life sciences focus, there have been some users who refused to switch from vanilla ImageJ1 to Fiji even though Fiji makes users' lives easier in lots of ways.</div>
<div><br></div><div>Regards,</div><div>Curtis</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 11, 2013 at 3:41 PM, Hadrien Mary <span dir="ltr"><<a href="mailto:hadrien.mary@gmail.com" target="_blank">hadrien.mary@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thansk for the answer Curtis !o<div><br></div><div>It's my fault because I didn't explain entirely the issue but I already knew all these behaviours. My problem is when for example I duplicate or make a z projection on an OME Tiff file under data browser, the new viewer will be hyperstack (IJ/Fiji default viewer). However if I export the file with LOCI exporter and then I re open it with LOCI importer I can still have data browser and OME metadata are here as well.</div>
<div><br></div><div>Anyway I now understand all IJ1 core limitations and I guess this problem is also due to IJ1 and so I will wait for IJ2. It really awesome if you can backport some IJ2 features to Fiji 1 since IJ2 won't be released before at least one year from what I saw...</div>
<div><br></div><div>PS: quick question to end: are you considering in a mid/long term to merge Fiji/IJ2 ? Does it make really sense to separate both ? I think it would be best for everyone (devs and users) to have only one place for download and development so you would have a better visiblity and it will be much more clear for potential contributors or bug reporters to know where they need to go... I am sure you already think about all of that, so I am sorry if my question is naive but I didn't find any informations on the web.</div>
<div><br></div><div>Best,</div></div><div class="gmail_extra"><div><br clear="all"><div><div dir="ltr"><br>--<br>Hadrien Mary<div><br></div><div>Ph.D student in Biology</div><div>Tournier-Gachet Team</div><div>
CNRS - LBCMCP - UMR 5088<div>
<div><br></div><div><div>Université de Toulouse - Bât. 4R3B1</div><div>118, route de Narbonne - 31062 Toulouse</div></div></div></div></div></div>
<br><br></div><div><div><div class="gmail_quote">On Wed, Dec 11, 2013 at 10:26 PM, Curtis Rueden <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Hadrien,<div><div><br></div><div><div>> Is there is a way to make LOCI data browser the default viewer on IJ /</div><div>> Fiji ?</div></div><div><br></div></div><div>Sort of. The Bio-Formats Importer dialog will remember that you selected the Data Browser as your stack viewer, and hence it will be initially selected upon subsequent calls to the Importer.</div>
<div><br></div><div>However, when using the File > Open command, ImageJ only calls Bio-Formats in certain cases. The rule of thumb is: if the format is one that only Bio-Formats knows how to handle, Bio-Formats will be called. If not, ImageJ will handle it internally, or with a different plugin. This behavior is not configurable.</div>
<div><br></div><div>So, if ImageJ does not call Bio-Formats (which it won't when opening e.g. a TIFF file), you will not end up with the Data Browser viewer.</div><div><div><br></div><div><div>> Or at least use LOCI data browser when an OME Tiff file is detected ?</div>
</div><div><br></div></div><div>Unfortunately, because OME-TIFF files end with the .ome.tif (or .ome.tiff) extension, ImageJ will prefer its own internal TIFF reader to Bio-Formats, even though its own internal reader does not actually support OME-TIFF's metadata.</div>
<div><br></div><div>Your options are either: A) open the file using File > Import > Bio-Formats rather than File > Open; or B) run Plugins > LOCI > LOCI Plugins Shortcut Window and then drag-and-drop your OME-TIFF files onto that window.</div>
<div><br></div><div>Regards,</div><div>Curtis<br></div><div><br></div><div>P.S. We have solved this problem in ImageJ2, thanks to its improved plugin framework and use of the extensible SCIFIO image I/O library. We are also planning to retrofit SCIFIO into Fiji in ImageJ 1.x mode, to address this problem there, too.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Dec 11, 2013 at 1:29 PM, Hadrien Mary <span dir="ltr"><<a href="mailto:hadrien.mary@gmail.com" target="_blank">hadrien.mary@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi,<div><br></div><div>Is there is a way to make LOCI data browser the default viewer on IJ / Fiji ? Or at least use LOCI data browser when an OME Tiff file is detected ?</div>
<div><br></div><div>Best,<br clear="all">
<div><div dir="ltr"><br>--<br>Hadrien Mary<div><br></div><div>Ph.D student in Biology</div><div>Tournier-Gachet Team</div><div>CNRS - LBCMCP - UMR 5088<div><div><br></div><div><div>Université de Toulouse - Bât. 4R3B1</div>
<div>118, route de Narbonne - 31062 Toulouse</div></div></div></div></div></div>
</div></div>
<br></div></div>_______________________________________________<br>
ome-devel mailing list<br>
<a href="mailto:ome-devel@lists.openmicroscopy.org.uk" target="_blank">ome-devel@lists.openmicroscopy.org.uk</a><br>
<a href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel" target="_blank">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>