From bergs at janelia.hhmi.org Wed Dec 12 19:48:24 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 12 Dec 2012 18:48:24 +0000 Subject: [ilastik-devel] Updates to the ilastik-0.6 Applet API Message-ID: An HTML attachment was scrubbed... URL: From bergs at janelia.hhmi.org Tue Jul 3 19:46:29 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Tue, 3 Jul 2012 17:46:29 +0000 Subject: [ilastik-devel] h5py multithread support Message-ID: FYI, ilastik developers may be interested in the following post from the h5py mailing list regarding synchronization issues: https://groups.google.com/forum/?fromgroups#!topic/h5py/q2kYHigifu8 Since h5py 2.1 isn't released yet, I've been using a recent clone of the h5py hg repo. The stability is vastly improved over the 2.0 release, but I still see the odd crash from time to time, which I attribute to h5py (though I can't prove it). From bernhard.kausler at iwr.uni-heidelberg.de Wed Jul 4 09:02:30 2012 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Wed, 04 Jul 2012 09:02:30 +0200 Subject: [ilastik-devel] h5py multithread support In-Reply-To: References: Message-ID: <4FF3EA86.9080302@iwr.uni-heidelberg.de> Stuart, could you please quickly detail what exactly you mean by "multithreading related h5py crashes"? Had it something to do with vigra accessing h5 files using its own wrapper for libhdf5 or are you talking about something different? Best, Bernhard From bergs at janelia.hhmi.org Wed Jul 4 18:52:57 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 4 Jul 2012 16:52:57 +0000 Subject: [ilastik-devel] h5py multithread support In-Reply-To: <4FF3EA86.9080302@iwr.uni-heidelberg.de> References: <4FF3EA86.9080302@iwr.uni-heidelberg.de> Message-ID: Hi Bernhard, > Stuart, could you please quickly detail what exactly you mean by "multithreading related h5py crashes"? I'm not sure which email that quote is lifted from... In my testing, I have seen that the pixel classification workflow can segfault under at least two scenarios: 1) Using Qt improperly (e.g. using a QPainter in a non-GUI thread). 2) Using h5py 2.0. Using h5py 2.1.0-beta, I see very few segfaults (they were extremely common using 2.0). Still, I have seen one or two segfaults even after upgrading. Having no other obvious source to blame for these, I blame h5py. Assuming that's correct, then there are two possibilities: 1) The segfault occurs when one or more threads are writing and other threads are reading. 2) The segfault occurs when all threads are reading. If I read Darren's response correctly, neither of these scenarios are officially supported by h5py-2.1 without synchronization at the application level, though he says that synchronization "may not be necessary" for the read-only case. At the moment, we aren't doing anything to protect against either scenario. Even so, the segfaults are extremely rare. The next time I see one, I'll document exactly what I was doing at the time. > Had it something to do with vigra accessing h5 files using its own wrapper for libhdf5 or are you talking about something different? No, vigra's hdf5 support is only used by v0.6 when reading/writing the classifier (via a temporary file since we can't share hdf5 file handles with vigra), which only occurs during project saving/loading. The segfaults I've seen did not occur during project saving/loading. -Stuart From ullrich.koethe at iwr.uni-heidelberg.de Thu Jul 5 20:37:45 2012 From: ullrich.koethe at iwr.uni-heidelberg.de (Ullrich Koethe) Date: Thu, 05 Jul 2012 20:37:45 +0200 Subject: [ilastik-devel] h5py multithread support In-Reply-To: References: <4FF3EA86.9080302@iwr.uni-heidelberg.de> Message-ID: <4FF5DEF9.8050506@iwr.uni-heidelberg.de> Hi Stuart and Bernhard, I'm somewhat confused about this issue (or rather the recommendations of the h5py developers). Why would one use explicit synchronization by locks on file access, when Python's Global Interpreter Lock already serializes all calls to HDF5 for free? I can imagine that synchronization problems arise if h5py releases the GIL for the sake of parallelization. But then, if it doesn't work, one would just keep the GIL locked and be done with it, instead of setting up yet another system of locks. Or am I missing something? Best regards Ulli >> Stuart, could you please quickly detail what exactly you mean by >> "multithreading related h5py crashes"? > > I'm not sure which email that quote is lifted from... > > In my testing, I have seen that the pixel classification workflow can > segfault under at least two scenarios: 1) Using Qt improperly (e.g. > using a QPainter in a non-GUI thread). 2) Using h5py 2.0. > > Using h5py 2.1.0-beta, I see very few segfaults (they were extremely > common using 2.0). Still, I have seen one or two segfaults even > after upgrading. Having no other obvious source to blame for these, > I blame h5py. Assuming that's correct, then there are two > possibilities: > > 1) The segfault occurs when one or more threads are writing and other > threads are reading. 2) The segfault occurs when all threads are > reading. > > If I read Darren's response correctly, neither of these scenarios are > officially supported by h5py-2.1 without synchronization at the > application level, though he says that synchronization "may not be > necessary" for the read-only case. > > At the moment, we aren't doing anything to protect against either > scenario. Even so, the segfaults are extremely rare. The next time > I see one, I'll document exactly what I was doing at the time. > >> Had it something to do with vigra accessing h5 files using its own >> wrapper for libhdf5 or are you talking about something different? > > No, vigra's hdf5 support is only used by v0.6 when reading/writing > the classifier (via a temporary file since we can't share hdf5 file > handles with vigra), which only occurs during project saving/loading. > The segfaults I've seen did not occur during project saving/loading. > > -Stuart > > > _______________________________________________ ilastik-devel mailing > list ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From markus.nullmeier at uni-heidelberg.de Thu Jul 19 14:26:18 2012 From: markus.nullmeier at uni-heidelberg.de (Markus Nullmeier) Date: Thu, 19 Jul 2012 14:26:18 +0200 (METDST) Subject: [ilastik-devel] Slides of the build system talk Message-ID: <201207191226.OAA17706@aixterm7.urz.uni-heidelberg.de> Dear all, please find the slides of today's talk about the build system at https://github.com/Ilastik/build-system/raw/master/doc/intro-talk.pdf Kind regards, Markus From markus.nullmeier at uni-heidelberg.de Fri Jul 20 15:45:50 2012 From: markus.nullmeier at uni-heidelberg.de (Markus Nullmeier) Date: Fri, 20 Jul 2012 15:45:50 +0200 (METDST) Subject: [ilastik-devel] New 0.6 test binary using prerelease h5py Message-ID: <201207201345.PAA22028@aixterm7.urz.uni-heidelberg.de> Dear all, please download the latest 0.6 binaries for 64-bit Linux as http://www.ilastik.org/download.php?cat=15_Download&file=ilastik.binaries-0.6-test-2.tar.bz2 Unpack via "tar jxf ilastik.binaries-0.6-test-2.tar.bz2" and start as ilastik.binaries-0.6-test-2/ilastik . For h5py, it uses the latest Mercurial commit 156e8c8afa66 from 2012/06/04 according to the stability requirements stated by Stuart. The respective build system commit, tagged "binaries-0.6-test-2", is now part of the master branch of https://github.com/Ilastik/build-system . The binaries' file was build on mipserver01 using the single command /export/home/users/mip/ilastik/build/local/bin/ilastik-build-binaries binaries-0.6-test-2 The file may be also found within the HCI as /export/home/users/mip/ilastik/build/snapshots/ilastik.binaries-0.6-test-2.tar.bz2 However -- the commits pertaining to Ilastik 0.6 proper are seriously outdated, as I do not know a recent combination of commits from the repositories "widgets", "volumina", "lazyflow", and "applet-workflows" that ought to be used. This information would go only into the tiny file release.json, and these commmits (tags do work as well as sha1 numbers, just push to Github via "git push --tags origin [your-branch]") are not required to be from the master branch of the respective repositories. Kind regards, Markus From markus.nullmeier at uni-heidelberg.de Fri Jul 20 18:58:42 2012 From: markus.nullmeier at uni-heidelberg.de (Markus Nullmeier) Date: Fri, 20 Jul 2012 18:58:42 +0200 (METDST) Subject: [ilastik-devel] Yet newer binaries... Message-ID: <201207201658.SAA16492@aixterm7.urz.uni-heidelberg.de> Dear all, there is another set of binaries at http://www.ilastik.org/download.php?cat=15_Download&file=ilastik.no-szip.tar.bz2 , the only difference from the previous being that the proprietary Szip library is configured out. I would assume that nobody needs szip, and distributing Ilastik with szip would be a violation of the GPL licenses of the FFTW, Sip, and PyQt packages. An alternative would be to obtain commmercial licenses for all of the latter three packages, which are apparently readily available. Kind regards, Markus From bernhard.kausler at iwr.uni-heidelberg.de Thu Jun 7 16:35:47 2012 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Thu, 07 Jun 2012 16:35:47 +0200 Subject: [ilastik-devel] Volumina logo Message-ID: <4FD0BC43.4040309@iwr.uni-heidelberg.de> Dear devs, please find attached my proposal for a Volumina logo. I would like to put it on github, if nobody disagrees. Best, Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: volumina-logo-noalpha.png Type: image/png Size: 278476 bytes Desc: not available URL: From bernhard.kausler at iwr.uni-heidelberg.de Sat Jun 9 13:07:32 2012 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Sat, 09 Jun 2012 13:07:32 +0200 Subject: [ilastik-devel] abstract DataSource.getShape method Message-ID: <4FD32E74.8040008@iwr.uni-heidelberg.de> Hi Stuart, you extended the abstract datasource interface with a getShape method. The pixelpipeline is written under the assumption of data with an infinite extent. Datasources have a 5D coordinate system with an origin (0,0,0,0,0) but not necessarily any borders (think of google maps or some artificially on-the-fly generated data). A datasource can-of course-have a shape (numpy arrays etc.). In that case requests outside the shape shouldn't happen in the first place (as guaranteed by a supervisor class like the volumeeditor) or the datasource implementation should return zeros outside the shape (or something equivalent). Furthermore, concrete implementations of the DataSource interface like ArraySource may expose a getShape method, but it shouldn't be a mandatory requirement for any DataSource. Bottomline: please remove the getShape method from the abstract interface (given that you don't have better argument for keeping it :) ) Best, Bernhard From bergs at janelia.hhmi.org Tue Jun 12 04:27:20 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Tue, 12 Jun 2012 02:27:20 +0000 Subject: [ilastik-devel] abstract DataSource.getShape method In-Reply-To: <4FD32E74.8040008@iwr.uni-heidelberg.de> References: <4FD32E74.8040008@iwr.uni-heidelberg.de> Message-ID: <9D4A9DC8-5B90-4EAB-AF3D-25A24640138A@janelia.hhmi.org> Hi Bernhard, Well said -- thanks for the explanation. I've now removed the getShape method from the datasource interface. Cheers, Stuart On Jun 9, 2012, at 7:07 AM, Bernhard X. Kausler wrote: > Hi Stuart, > > you extended the abstract datasource interface with a getShape method. > > The pixelpipeline is written under the assumption of data with an > infinite extent. Datasources have a 5D coordinate system with an origin > (0,0,0,0,0) but not necessarily any borders (think of google maps or > some artificially on-the-fly generated data). > > A datasource can-of course-have a shape (numpy arrays etc.). In that > case requests outside the shape shouldn't happen in the first place (as > guaranteed by a supervisor class like the volumeeditor) or the > datasource implementation should return zeros outside the shape (or > something equivalent). Furthermore, concrete implementations of the > DataSource interface like ArraySource may expose a getShape method, but > it shouldn't be a mandatory requirement for any DataSource. > > Bottomline: please remove the getShape method from the abstract > interface (given that you don't have better argument for keeping it :) ) > > Best, > Bernhard From bernhard.kausler at iwr.uni-heidelberg.de Thu Jun 14 14:09:17 2012 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard Kausler) Date: Thu, 14 Jun 2012 14:09:17 +0200 Subject: [ilastik-devel] "techpreview" vs. "applet-workflows" repo and plans for the github repos Message-ID: <4FD9D46D.3020908@iwr.uni-heidelberg.de> Hi all, why are there two repos for the ilastik-shell and workflows ("techpreview" and "applet-workflows")? They should be reunited again. I think we have way to many repos at the moment and have to cut the number down: We will rename the "ilastik" repo to "ilastik-0.5" and make a "ilastik" repo for 0.6 based on "techpreview". The shell and our applets should all go there. Lazyflow and Volumina stay in their own repos, since they are also useful outside the Ilastik context. Best, Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: bernhard_kausler.vcf Type: text/x-vcard Size: 470 bytes Desc: not available URL: From bergs at janelia.hhmi.org Thu Jun 14 16:43:00 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Thu, 14 Jun 2012 14:43:00 +0000 Subject: [ilastik-devel] "techpreview" vs. "applet-workflows" repo and plans for the github repos In-Reply-To: <4FD9D46D.3020908@iwr.uni-heidelberg.de> References: <4FD9D46D.3020908@iwr.uni-heidelberg.de> Message-ID: <1BE2FFC1-19B6-4BD8-B4B5-BCC2427DE443@janelia.hhmi.org> Hello Bernhard, My preference is to keep the applet-workflows repo separate from the techpreview. My impression of the techpreview is that it contains experimental projects that may not be included in the v0.6 release (e.g. the CATMAID interface). Is this correct? The applet-workflows repo represents the files specific to the v0.6 release. It should therefore be cleaner to track issues on github and maintain tests for it separate from the other projects in techpreview. Anyway, that's my opinion, but if I'm outvoted -- or outranked :-) -- then I'll merge the applet-workflows repo back into the techpreview. Let me know if my assumptions are incorrect. Any other opinions? Christoph? Thorben? -Stuart On Jun 14, 2012, at 8:09 AM, Bernhard Kausler wrote: > Hi all, > > why are there two repos for the ilastik-shell and workflows ("techpreview" and "applet-workflows")? They should be reunited again. > > I think we have way to many repos at the moment and have to cut the number down: > We will rename the "ilastik" repo to "ilastik-0.5" and make a "ilastik" repo for 0.6 based on "techpreview". > The shell and our applets should all go there. Lazyflow and Volumina stay in their own repos, since they are also useful outside the Ilastik context. > > Best, > Bernhard > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From markus.nullmeier at uni-heidelberg.de Wed Jun 20 21:50:59 2012 From: markus.nullmeier at uni-heidelberg.de (Markus Nullmeier) Date: Wed, 20 Jun 2012 21:50:59 +0200 (METDST) Subject: [ilastik-devel] New build system Message-ID: <201206201951.VAA14108@aixterm7.urz.uni-heidelberg.de> Dear all, the new build system for Linux binaries of the future 0.6 release (containing about two dozen upstream packages) is from now on to be found at https://github.com/Ilastik/build-system . There is a tentative, even provisionally working, bootstrap script, lacking mainly a viable way to distribute/download the 800M of the file vm_fedora12_0.sparse.qcow2. Anyway, anybody may perform a single-command build on the machine mipserver01 (where everything is already installed), as /export/home/users/mip/ilastik/build/local/bin/ilastik-build-binaries -- it takes about 36 minutes if that computer is idle otherwise. A working result of the latest binary build may be found as /export/home/users/mip/ilastik/build/snapshots/ilastik.3b74edf525d6082f550472f7b31585db99cb9fa9_bootstrap.tar.bz2 It uses the HEAD state of applet-workflows, lazyflow, widgets, and volumina from about two weeks ago. Please create new work branches in the "build-system" repository for experimentation. Do not push to the master branch unless you are absolutely sure what you are doing :-) Use work branches for builds via /export/home/users/mip/ilastik/build/local/bin/ilastik-build-binaries -- only after you have pushed your changes to Ilastik/build-system on Github, where is the output of 'git rev-parse HEAD' when your work branch is checked out. Or else, use the appropriate internal scripts -- documenatation for these will eventually follow, if/when somebody else actually starts using the new build system. Kind regards, Markus From bernhard.kausler at iwr.uni-heidelberg.de Thu Jun 21 18:05:17 2012 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Thu, 21 Jun 2012 18:05:17 +0200 Subject: [ilastik-devel] "techpreview" vs. "applet-workflows" repo and plans for the github repos In-Reply-To: <1BE2FFC1-19B6-4BD8-B4B5-BCC2427DE443@janelia.hhmi.org> References: <4FD9D46D.3020908@iwr.uni-heidelberg.de> <1BE2FFC1-19B6-4BD8-B4B5-BCC2427DE443@janelia.hhmi.org> Message-ID: <4FE3463D.1010904@iwr.uni-heidelberg.de> Dear all, as discussed with Stuart and Thorben: I removed the ilastikshell code from the techpreview repo. Ilastikshell now lives in applet-workflows, which shall become the new Ilastik 0.6 at some point in the future. To reduce confusion I made the "techpreview" repo private, since most of the code doesn't work anymore with the new lazyflow. Best, Bernhard On 06/14/2012 04:43 PM, Berg, Stuart wrote: > Hello Bernhard, > > My preference is to keep the applet-workflows repo separate from the techpreview. My impression of the techpreview is that it contains experimental projects that may not be included in the v0.6 release (e.g. the CATMAID interface). Is this correct? The applet-workflows repo represents the files specific to the v0.6 release. It should therefore be cleaner to track issues on github and maintain tests for it separate from the other projects in techpreview. > > Anyway, that's my opinion, but if I'm outvoted -- or outranked :-) -- then I'll merge the applet-workflows repo back into the techpreview. Let me know if my assumptions are incorrect. > > Any other opinions? Christoph? Thorben? > > -Stuart > > > On Jun 14, 2012, at 8:09 AM, Bernhard Kausler wrote: > >> Hi all, >> >> why are there two repos for the ilastik-shell and workflows ("techpreview" and "applet-workflows")? They should be reunited again. >> >> I think we have way to many repos at the moment and have to cut the number down: >> We will rename the "ilastik" repo to "ilastik-0.5" and make a "ilastik" repo for 0.6 based on "techpreview". >> The shell and our applets should all go there. Lazyflow and Volumina stay in their own repos, since they are also useful outside the Ilastik context. >> >> Best, >> Bernhard >> _______________________________________________ >> ilastik-devel mailing list >> ilastik-devel at ilastik.org >> http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > From bergs at janelia.hhmi.org Thu Nov 1 15:37:54 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Thu, 1 Nov 2012 14:37:54 +0000 Subject: [ilastik-devel] Applet API Documentation In-Reply-To: <44F90911-52B4-401E-9F09-6460EA2592DA@janelia.hhmi.org> References: <44F90911-52B4-401E-9F09-6460EA2592DA@janelia.hhmi.org> Message-ID: Oops, I forgot to update that link now that the repo name has changed. The online copy of the docs are at http://ilastik.github.com/ilastik-0.6/ ________________________________________ From: ilastik-devel-bounces at ilastik.org [ilastik-devel-bounces at ilastik.org] on behalf of Berg, Stuart [bergs at janelia.hhmi.org] Sent: Wednesday, October 31, 2012 5:29 PM To: ilastik-devel at ilastik.org Subject: [ilastik-devel] Applet API Documentation Hi all, The ilastik-0.6 repo has some developer documentation now. It's not complete, but it should help beginners get a handle on basic workflow design. The pre-built files are located in ilastik-0.6/docs/_build/html, or you can read them online here: http://ilastik.github.com/applet-workflows/ That online version won't update automatically. If you make changes to the documentation, let me know and I'll update the online copy. By the way, you can get rudimentary visualizations of your operators via the "Export Operator Diagram" menu item in the "Settings" menu of the ilastik shell. The svg diagram it produces MUST be opened with InkScape and exported before you can view it with Firefox. Let me know if you have any questions or suggestions for improvements. Stuart _______________________________________________ ilastik-devel mailing list ilastik-devel at ilastik.org http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From anna.kreshuk at iwr.uni-heidelberg.de Thu Nov 1 20:11:42 2012 From: anna.kreshuk at iwr.uni-heidelberg.de (anna.kreshuk at iwr.uni-heidelberg.de) Date: Thu, 01 Nov 2012 20:11:42 +0100 Subject: [ilastik-devel] Applet API Documentation In-Reply-To: References: <44F90911-52B4-401E-9F09-6460EA2592DA@janelia.hhmi.org> Message-ID: <20121101201142.kqtb4865cgg4ks8s@webmail.iwr.uni-heidelberg.de> Stuart, this is awesome!!! And certainly above scientific software documentation standards. I was meaning to tell you, I also appreciate the new lazyflow error messages, it looks much friendlier now. Anna Quoting "Berg, Stuart" : > Oops, I forgot to update that link now that the repo name has changed. > > The online copy of the docs are at http://ilastik.github.com/ilastik-0.6/ > > ________________________________________ > From: ilastik-devel-bounces at ilastik.org > [ilastik-devel-bounces at ilastik.org] on behalf of Berg, Stuart > [bergs at janelia.hhmi.org] > Sent: Wednesday, October 31, 2012 5:29 PM > To: ilastik-devel at ilastik.org > Subject: [ilastik-devel] Applet API Documentation > > Hi all, > > The ilastik-0.6 repo has some developer documentation now. It's not > complete, but it should help beginners get a handle on basic > workflow design. The pre-built files are located in > ilastik-0.6/docs/_build/html, or you can read them online here: > > http://ilastik.github.com/applet-workflows/ > > That online version won't update automatically. If you make changes > to the documentation, let me know and I'll update the online copy. > > By the way, you can get rudimentary visualizations of your operators > via the "Export Operator Diagram" menu item in the "Settings" menu > of the ilastik shell. The svg diagram it produces MUST be opened > with InkScape and exported before you can view it with Firefox. > > Let me know if you have any questions or suggestions for improvements. > > Stuart > > > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > From ullrich.koethe at iwr.uni-heidelberg.de Fri Nov 2 10:22:36 2012 From: ullrich.koethe at iwr.uni-heidelberg.de (Ullrich Koethe) Date: Fri, 02 Nov 2012 10:22:36 +0100 Subject: [ilastik-devel] Applet API Documentation In-Reply-To: References: <44F90911-52B4-401E-9F09-6460EA2592DA@janelia.hhmi.org> Message-ID: <509390DC.9080403@iwr.uni-heidelberg.de> Hi Stuart, > Oops, I forgot to update that link now that the repo name has changed. > > The online copy of the docs are at http://ilastik.github.com/ilastik-0.6/ > Very nice! BTW, the name should also be changed in the documentation itself (e.g. on the Overview page). Best regards Ulli > ________________________________________ > From: ilastik-devel-bounces at ilastik.org [ilastik-devel-bounces at ilastik.org] on behalf of Berg, Stuart [bergs at janelia.hhmi.org] > Sent: Wednesday, October 31, 2012 5:29 PM > To: ilastik-devel at ilastik.org > Subject: [ilastik-devel] Applet API Documentation > > Hi all, > > The ilastik-0.6 repo has some developer documentation now. It's not complete, but it should help beginners get a handle on basic workflow design. The pre-built files are located in ilastik-0.6/docs/_build/html, or you can read them online here: > > http://ilastik.github.com/applet-workflows/ > > That online version won't update automatically. If you make changes to the documentation, let me know and I'll update the online copy. > > By the way, you can get rudimentary visualizations of your operators via the "Export Operator Diagram" menu item in the "Settings" menu of the ilastik shell. The svg diagram it produces MUST be opened with InkScape and exported before you can view it with Firefox. > > Let me know if you have any questions or suggestions for improvements. > > Stuart > > > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > From bergs at janelia.hhmi.org Fri Nov 2 18:12:10 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Fri, 2 Nov 2012 17:12:10 +0000 Subject: [ilastik-devel] Renamed ilastik organization and 2 repositories In-Reply-To: References: Message-ID: <2FB51B1B-7442-4E44-BD2D-724E8B1C39FF@janelia.hhmi.org> Hi again, The team has decided to remove the version number from the actively-developed repos. Sorry for the confusion. Here's a summary of this week's changes: Was: ilastik Now: ilastik-0.5 Was: applet-workflows Now: ilastik (not ilastik-0.6) Online Developer Documentation: http://ilastik.github.com/ilastik/ New repo: ilastik-meta (not ilastik-0.6-meta) Old URL: http://github.com/Ilastik/ New URL: http://github.com/ilastik/ (note capitalization) Stuart On Oct 31, 2012, at 5:18 PM, Berg, Stuart wrote: > Hi all, > > I've started to implement the slight changes mentioned in applet-workflows issue #26: > http://github.com/ilastik/ilastik-0.6/issues/26 > > Please make note of the following changes: > > 1) On github, our organization's name is now "ilastik" not "Ilastik" (note the capitalization). For urls, it shouldn't matter. For git commands (e.g. git clone), it seems to make a difference. > > 2) The repo for ilastik v0.5 has been renamed to ilastik-0.5 > > 3) The repo for applet-workflows has been renamed to ilastik-0.6 > > 4) A new repo called ilastik-meta has been made for tagging release repo revisions. > > Note that if you have a local copy of the applet-workflows repo, you'll have to associate it with a new remote. Assuming github is your "origin" remote, you would rename it as follows: > > $ git remote -v > origin ssh://git at github.com/ilastik/ilastik-0.6 (fetch) > origin ssh://git at github.com/ilastik/ilastik-0.6 (push) > > $ git remote rm origin > $ git remote add origin ssh://git at github.com/ilastik/ilastik-0.6 > > Similarly, you may need to rename your local copy of the ilastik 0.5 repo, if you have one. > > You may need to replace ssh with http, depending on how your git setup. > > -Stuart > > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From f.v.claus at googlemail.com Sun Nov 4 13:58:52 2012 From: f.v.claus at googlemail.com (Frederik Claus) Date: Sun, 4 Nov 2012 13:58:52 +0100 Subject: [ilastik-devel] Handle smaller dimension output with LayerViewerGui Message-ID: Hi list, I need to run one operation which requires the whole first,second and fifth dimension of the lf. For example (:,:,:256,:256,:). It outputs only one image of the size of the third and fourth dimension. Is there a way to access the data of the dataSelectionOperator manually, e.g. dataSelectionOperator.InputImages[:].wait()? I can only access this operator, when all inputs of my own operator are set (connected behind the dataSelectionOperator). I also tried disconnecting, but the InputImages don't seem to be available, when the operator is not ready. What is the right way to do it? Thanks, Frederik From f.v.claus at googlemail.com Sun Nov 4 14:03:00 2012 From: f.v.claus at googlemail.com (Frederik Claus) Date: Sun, 4 Nov 2012 14:03:00 +0100 Subject: [ilastik-devel] Applet API Documentation In-Reply-To: <44F90911-52B4-401E-9F09-6460EA2592DA@janelia.hhmi.org> References: <44F90911-52B4-401E-9F09-6460EA2592DA@janelia.hhmi.org> Message-ID: Hi Stuart, I read most of the documentation and found it to be very helpful. There were some minor things I did not understand: In the applet class documentation, what are the signals that are used to trigger certain shell requests? In the top-level operators section, how does the gui know the operator "changed" to fetch the data? I understand that this is handled usually by the layerviewer gui somehow, but what happens exactly? The chaining of operators in general, the signals that traverse this chain and the point in time when all the data is sucked through the chain is still a mystery to me. Frederik 2012/10/31 Berg, Stuart : > Hi all, > > The ilastik-0.6 repo has some developer documentation now. It's not complete, but it should help beginners get a handle on basic workflow design. The pre-built files are located in ilastik-0.6/docs/_build/html, or you can read them online here: > > http://ilastik.github.com/applet-workflows/ > > That online version won't update automatically. If you make changes to the documentation, let me know and I'll update the online copy. > > By the way, you can get rudimentary visualizations of your operators via the "Export Operator Diagram" menu item in the "Settings" menu of the ilastik shell. The svg diagram it produces MUST be opened with InkScape and exported before you can view it with Firefox. > > Let me know if you have any questions or suggestions for improvements. > > Stuart > > > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From bergs at janelia.hhmi.org Mon Nov 5 04:14:24 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Mon, 5 Nov 2012 03:14:24 +0000 Subject: [ilastik-devel] Applet API Documentation In-Reply-To: References: <44F90911-52B4-401E-9F09-6460EA2592DA@janelia.hhmi.org> Message-ID: <6EC90190-BCF4-4541-90B5-829D0B2735D3@janelia.hhmi.org> An HTML attachment was scrubbed... URL: From f.v.claus at googlemail.com Wed Nov 7 22:31:16 2012 From: f.v.claus at googlemail.com (Frederik Claus) Date: Wed, 7 Nov 2012 22:31:16 +0100 Subject: [ilastik-devel] Handle smaller dimension output with LayerViewerGui In-Reply-To: <3A882270-CE86-4F0F-A0A6-6E3874DA12F7@janelia.hhmi.org> References: <3A882270-CE86-4F0F-A0A6-6E3874DA12F7@janelia.hhmi.org> Message-ID: Hi, There is no easy to understand code available. I have tried several things, but that's just a mess now. My operator must support multiple operations on the images, therefore the mere function of the operator is just dispatching to the right "function" (that's why it is not so easy to go over ;). Essentially I want the following: def onDepth(self): self.logger.info("Building depth...") # get all the images raw = self.dataSelectionOperator.Image[:].wait() depth = operations.depth(raw,**options) # depth has the shape (1,1,width,height,nchannels) self.customWidget.show(depth) #this will display the depth image in a custom widget onDepth is connected to a button in the ui. I need to access the whole data at once or in slices of (:,:,x,y,z). My data is different from the one you usually use. It is an array of images, where the first and second dimension indexes the image and the 3-5th dimension is the image itself (including the colour channel). The depth function calculates the depth-structure tensor and therefore needs to access all the images. Let's assume the array stores 9x9 pictures with a resolution of 100x100 pixels in colour. The shape of the array would therefore be (9,9,100,100,3). Calculating the depth of pixel (3,4) would require the data from (0:9,0:9,3,4,3). The topleveloperator in ilastik only asks for something like this: (1,1,3,4,3). (3,4) is just for the sake of simplicity :) I would have to get all the images for every slice he asks for. This is so memory intensive, it crashes my computer everytime. It is obviously redundant too, because from all the images I can only calculate one depth image and not one per image. I understand that this will not work with the topleveloperator of an applet, therefore I tried to access the image data "by hand" and do the calculation in one run. I hope this clarifies the problem Thanks for your helpful answers all the time, Frederik 2012/11/5 Berg, Stuart : > Hi Frederik, > > I'm sorry, but I don't understand your question. Is your code on github somewhere? I'd be happy to take a look at your specific use-case if you can point me to a particular operator you're working on. > > Stuart > > > On Nov 4, 2012, at 7:58 AM, Frederik Claus wrote: > >> Hi list, >> >> I need to run one operation which requires the whole first,second and >> fifth dimension of the lf. For example (:,:,:256,:256,:). It outputs >> only one image of the size of the third and fourth dimension. Is there >> a way to access the data of the dataSelectionOperator manually, e.g. >> dataSelectionOperator.InputImages[:].wait()? I can only access this >> operator, when all inputs of my own operator are set (connected behind >> the dataSelectionOperator). I also tried disconnecting, but the >> InputImages don't seem to be available, when the operator is not >> ready. What is the right way to do it? >> >> Thanks, >> Frederik >> _______________________________________________ >> ilastik-devel mailing list >> ilastik-devel at ilastik.org >> http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > From bernhard.kausler at iwr.uni-heidelberg.de Thu Nov 22 10:50:35 2012 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Thu, 22 Nov 2012 10:50:35 +0100 Subject: [ilastik-devel] widgets repo now private Message-ID: <50ADF56B.9020300@iwr.uni-heidelberg.de> Dear all, the widgets repo was merged into ilastik some time ago. Therefore I made the--now obsolete--repo private. Best, Bernhard From christoph.straehle at iwr.uni-heidelberg.de Thu Nov 22 17:32:23 2012 From: christoph.straehle at iwr.uni-heidelberg.de (Christoph N. Straehle) Date: Thu, 22 Nov 2012 17:32:23 +0100 Subject: [ilastik-devel] On-Demand Operator-Wrapper for (hopefully) many images Message-ID: <50AE5397.60205@iwr.uni-heidelberg.de> Dear All, i pushed a branch called "lazy_wrapper" to github which contains an experimental implementation of a on-demand operator wrapper that instantiates an inner operator only when: * somebody accesses the subslot that would need this inner op * somebody accesses the .meta of a slot that would need this inner op It seems to work ok, but i would welcome comments on possible other approaches to the problem or things that i overlooked ! TODO: * management of created inner operators: last recently used, maximum count of MAX_COUNT inner ops ? other ideas ? * unit tests Greetings, Christoph From f.v.claus at googlemail.com Fri Oct 12 16:34:57 2012 From: f.v.claus at googlemail.com (Frederik Claus) Date: Fri, 12 Oct 2012 16:34:57 +0200 Subject: [ilastik-devel] volumina/setup.py nosetests fail with AssertionError: parent must be an operator! (lazyflow.graph) Message-ID: Hi mailing list, I'm trying to setup volumina, which does not work anymore after updating lazyflow from the repository. In the previously working version, I had a lazyflow clone with drtile without the necessity to instantiate a Graph instance and without the {input,output}Slots array. As far as I'm concerned all other dependencies are satisfied. Here is the full stack trace of one error: ====================================================================== ERROR: test_Roi_default_order (testOp5ifyer.TestOp5ifyer) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/fredo/mountpoint/workspace/ilastik/volumina/tests/testOp5ifyer.py", line 29, in setUp self.operator = Op5ifyer(graph) File "/home/fredo/mountpoint/workspace/ilastikenv/local/lib/python2.7/site-packages/lazyflow-0.0.0-py2.7.egg/lazyflow/graph.py", line 1246, in __call__ instance = type.__call__(cls,*args,**kwargs) File "/home/fredo/mountpoint/workspace/ilastik/volumina/volumina/adaptors.py", line 38, in __init__ super(Op5ifyer, self).__init__(*args, **kwargs) File "/home/fredo/mountpoint/workspace/ilastikenv/local/lib/python2.7/site-packages/lazyflow-0.0.0-py2.7.egg/lazyflow/graph.py", line 1303, in __init__ assert False, "parent must be an operator!" AssertionError: parent must be an operator! ---------------------------------------------------------------------- The full output is here: http://pastebin.com/Wusfn6rz . Lazyflow is at commit bcbaa9997ed6a5cf894ab5fba211f7df0e378d1e in the master branch. Thanks, Fredy From bergs at janelia.hhmi.org Fri Oct 12 18:49:30 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Fri, 12 Oct 2012 16:49:30 +0000 Subject: [ilastik-devel] volumina/setup.py nosetests fail with AssertionError: parent must be an operator! (lazyflow.graph) In-Reply-To: References: Message-ID: Hi Fredy, Your copy of volumina is out-of-date. For example, your stacktrace shows that line 29 of testOp5ifyer.py is: self.operator = Op5ifyer(graph) but in volumina/master, it is: self.operator = Op5ifyer(graph=graph) (see https://github.com/Ilastik/volumina/blob/master/tests/testOp5ifyer.py) which is the source of the particular crash you're getting. Unfortunately, the version dependency between lazyflow and volumina is not well documented at the moment. If you pull the latest rev of master for both repos, everything should work. HTH, Stuart ________________________________________ From: ilastik-devel-bounces at ilastik.org [ilastik-devel-bounces at ilastik.org] on behalf of Frederik Claus [f.v.claus at googlemail.com] Sent: Friday, October 12, 2012 10:34 AM To: ilastik-devel at ilastik.org Subject: [ilastik-devel] volumina/setup.py nosetests fail with AssertionError: parent must be an operator! (lazyflow.graph) Hi mailing list, I'm trying to setup volumina, which does not work anymore after updating lazyflow from the repository. In the previously working version, I had a lazyflow clone with drtile without the necessity to instantiate a Graph instance and without the {input,output}Slots array. As far as I'm concerned all other dependencies are satisfied. Here is the full stack trace of one error: ====================================================================== ERROR: test_Roi_default_order (testOp5ifyer.TestOp5ifyer) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/fredo/mountpoint/workspace/ilastik/volumina/tests/testOp5ifyer.py", line 29, in setUp self.operator = Op5ifyer(graph) File "/home/fredo/mountpoint/workspace/ilastikenv/local/lib/python2.7/site-packages/lazyflow-0.0.0-py2.7.egg/lazyflow/graph.py", line 1246, in __call__ instance = type.__call__(cls,*args,**kwargs) File "/home/fredo/mountpoint/workspace/ilastik/volumina/volumina/adaptors.py", line 38, in __init__ super(Op5ifyer, self).__init__(*args, **kwargs) File "/home/fredo/mountpoint/workspace/ilastikenv/local/lib/python2.7/site-packages/lazyflow-0.0.0-py2.7.egg/lazyflow/graph.py", line 1303, in __init__ assert False, "parent must be an operator!" AssertionError: parent must be an operator! ---------------------------------------------------------------------- The full output is here: http://pastebin.com/Wusfn6rz . Lazyflow is at commit bcbaa9997ed6a5cf894ab5fba211f7df0e378d1e in the master branch. Thanks, Fredy _______________________________________________ ilastik-devel mailing list ilastik-devel at ilastik.org http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From f.v.claus at googlemail.com Sun Oct 14 17:50:46 2012 From: f.v.claus at googlemail.com (Frederik Claus) Date: Sun, 14 Oct 2012 17:50:46 +0200 Subject: [ilastik-devel] volumina/setup.py nosetests fail with AssertionError: parent must be an operator! (lazyflow.graph) In-Reply-To: References: Message-ID: Hi Stuart, Thanks for your help. Pulling the head solved the problem Fredy 2012/10/12 Berg, Stuart : > Hi Fredy, > > Your copy of volumina is out-of-date. > > For example, your stacktrace shows that line 29 of testOp5ifyer.py is: > self.operator = Op5ifyer(graph) > > but in volumina/master, it is: > self.operator = Op5ifyer(graph=graph) > > (see https://github.com/Ilastik/volumina/blob/master/tests/testOp5ifyer.py) > > which is the source of the particular crash you're getting. > > Unfortunately, the version dependency between lazyflow and volumina is not well documented at the moment. If you pull the latest rev of master for both repos, everything should work. > > HTH, > Stuart > > ________________________________________ > From: ilastik-devel-bounces at ilastik.org [ilastik-devel-bounces at ilastik.org] on behalf of Frederik Claus [f.v.claus at googlemail.com] > Sent: Friday, October 12, 2012 10:34 AM > To: ilastik-devel at ilastik.org > Subject: [ilastik-devel] volumina/setup.py nosetests fail with AssertionError: parent must be an operator! (lazyflow.graph) > > Hi mailing list, > > I'm trying to setup volumina, which does not work anymore after > updating lazyflow from the repository. In the previously working > version, I had a lazyflow clone with drtile without the necessity to > instantiate a Graph instance and without the {input,output}Slots > array. As far as I'm concerned all other dependencies are satisfied. > Here is the full stack trace of one error: > > ====================================================================== > ERROR: test_Roi_default_order (testOp5ifyer.TestOp5ifyer) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/fredo/mountpoint/workspace/ilastik/volumina/tests/testOp5ifyer.py", > line 29, in setUp > self.operator = Op5ifyer(graph) > File "/home/fredo/mountpoint/workspace/ilastikenv/local/lib/python2.7/site-packages/lazyflow-0.0.0-py2.7.egg/lazyflow/graph.py", > line 1246, in __call__ > instance = type.__call__(cls,*args,**kwargs) > File "/home/fredo/mountpoint/workspace/ilastik/volumina/volumina/adaptors.py", > line 38, in __init__ > super(Op5ifyer, self).__init__(*args, **kwargs) > File "/home/fredo/mountpoint/workspace/ilastikenv/local/lib/python2.7/site-packages/lazyflow-0.0.0-py2.7.egg/lazyflow/graph.py", > line 1303, in __init__ > assert False, "parent must be an operator!" > AssertionError: parent must be an operator! > > ---------------------------------------------------------------------- > > The full output is here: http://pastebin.com/Wusfn6rz . Lazyflow is at > commit bcbaa9997ed6a5cf894ab5fba211f7df0e378d1e in the master branch. > > Thanks, > Fredy > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From f.v.claus at googlemail.com Sun Oct 14 18:00:00 2012 From: f.v.claus at googlemail.com (Frederik Claus) Date: Sun, 14 Oct 2012 18:00:00 +0200 Subject: [ilastik-devel] Changing layout of layerViewerGui Message-ID: Hi list, I want to use the layerViewerGui, part of the layerViewer applet, as a base class for my gui, as recommended in the doc string of the class. Is there a way to change the layout? I want to modify the size and position of the 2 dimensional image views. Seems that the layout for the quadview widget is defined in its constructor. What is the recommended way to define a custom layout? Frederik From bergs at janelia.hhmi.org Sun Oct 14 19:47:02 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Sun, 14 Oct 2012 17:47:02 +0000 Subject: [ilastik-devel] Changing layout of layerViewerGui In-Reply-To: References: Message-ID: <599CD909-D8ED-46D2-9CDB-DD6C0D543366@janelia.hhmi.org> An HTML attachment was scrubbed... URL: From bernhard.kausler at iwr.uni-heidelberg.de Mon Oct 15 09:19:06 2012 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Mon, 15 Oct 2012 09:19:06 +0200 Subject: [ilastik-devel] Changing layout of layerViewerGui In-Reply-To: <599CD909-D8ED-46D2-9CDB-DD6C0D543366@janelia.hhmi.org> References: <599CD909-D8ED-46D2-9CDB-DD6C0D543366@janelia.hhmi.org> Message-ID: <507BB8EA.1090504@iwr.uni-heidelberg.de> On 10/14/2012 07:47 PM, Berg, Stuart wrote: > > QUESTION FOR VOLUMINA DEVELOPERS: > Both of the solutions I'm suggesting above are somewhat hackish, because they rely on volume editor and quadsplitter > implementation details. As a result, there's always a chance that future changes to volumina will break the code in > this email. Is arbitrary arrangement of the slicing views a feature we should "officially" support in the > VolumeEditorWidget API? It's definitely necessary some time in the future; not only rearranging them but having more than three ImageViews allowing to display other slicings like time-space. But it has no priority for the 0.6 release. Best, Bernhard From f.v.claus at googlemail.com Tue Oct 16 12:40:42 2012 From: f.v.claus at googlemail.com (Frederik Claus) Date: Tue, 16 Oct 2012 12:40:42 +0200 Subject: [ilastik-devel] Custom SlicingProjection in volumeEditor Message-ID: Hi list, I want to have custom slicing projections in the volumeEditor. What I want is the following: alongTXC = SliceProjection( abscissa = 2, ordinate = 3, along = [0,1,4] ) alongTYC = SliceProjection( abscissa = 1, ordinate = 3, along = [0,2,4] ) # alongTZC = SliceProjection( abscissa = 1, ordinate = 2, along = [0,3,4] ) alongTZC = SliceProjection( abscissa = 0, ordinate = 2, along = [1,3,4]) So I only want to change the last projection. I tried adding parts of the constructor code to my subclassed LayerViewerGui, which either shows nothing in the image views or breaks the ui completely. Is there another way to accomplish this? Thanks, Fredy From f.v.claus at googlemail.com Sat Oct 27 14:58:44 2012 From: f.v.claus at googlemail.com (Frederik Claus) Date: Sat, 27 Oct 2012 14:58:44 +0200 Subject: [ilastik-devel] Open project in GUI programmatically Message-ID: Hi list, Is there a way to script the ilastik shell Gui that it will automatically open a project on startup? I was looking for something similiar to the pixelClassificationHeadless workflow that uses shell.openProjectPath(). Thanks, Frederik From bernhard.kausler at iwr.uni-heidelberg.de Mon Oct 29 10:30:25 2012 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Mon, 29 Oct 2012 10:30:25 +0100 Subject: [ilastik-devel] Open project in GUI programmatically In-Reply-To: References: Message-ID: <508E4CB1.8030800@iwr.uni-heidelberg.de> Dear Frederik, you can give pixelClassificationWorkflowMainGui.py a project file as a command line argument. If that is not enough, please have a look into the above file. There you will find examples how to start the shell with different debugging configurations. Best, Bernard On 27.10.2012 14:58, Frederik Claus wrote: > Hi list, > > Is there a way to script the ilastik shell Gui that it will > automatically open a project on startup? > I was looking for something similiar to the > pixelClassificationHeadless workflow that uses > shell.openProjectPath(). > > Thanks, > > Frederik > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > From f.v.claus at googlemail.com Tue Oct 30 15:02:32 2012 From: f.v.claus at googlemail.com (Frederik Claus) Date: Tue, 30 Oct 2012 15:02:32 +0100 Subject: [ilastik-devel] Why are Multislots necessary? Message-ID: Hi list, I digged around the code for a while, but couldn't find an answer. Why are Multislots necessary? They are used in every Applet class and in the LayerViewerGui. Frederik From bernhard.kausler at iwr.uni-heidelberg.de Wed Oct 31 12:32:25 2012 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Wed, 31 Oct 2012 12:32:25 +0100 Subject: [ilastik-devel] Why are Multislots necessary? In-Reply-To: References: Message-ID: <50910C49.5080702@iwr.uni-heidelberg.de> Hi Frederik, you need them if you want to share an operator together with its state between several instances of the same workflow. The best example is a classifier that you want to train on several input images; but prediction and feature computation should be independet for each image. Have a look at the OpTrainRandomForest: https://github.com/Ilastik/lazyflow/blob/master/lazyflow/operators/obsolete/classifierOperators.py#L15 You can see that the "Images" and "Labels" InputSlots are MultiSlots (as indicated by "level=1") You can make all Slots of a common Operator MultiSlots by using the OperatorWrapper class. That corresponds to the default behaviour of treating different datasets independently. That way the shell can handle an arbitrary number of input data. (Alternatively, one could just open another Ilastik. But sometimes its more convenient to compare datasets in the same instance of the shell). Btw. until recent there where two classes Slot and MultiSlot. Now there are only Slots with the "level" argument. Higher levels are necessary if you have a recursive situation like training an ensemble of classifiers on an ensemble of input data. Don't worry about these concepts too much. Just use normal Slots. In most scenarios you won't need the multislots. What you have to consider is the "setImageIndex" method when implementing your own applets: https://github.com/Ilastik/applet-workflows/blob/master/ilastik/applets/base/appletGuiInterface.py#L99 The shell will call this function whenever a new image is opened by the user or when the user switches the currently active image. Best, Bernhard On 30.10.2012 15:02, Frederik Claus wrote: > Hi list, > > I digged around the code for a while, but couldn't find an answer. Why > are Multislots necessary? They are used in every Applet class and in > the LayerViewerGui. > > Frederik > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > From bergs at janelia.hhmi.org Wed Oct 31 22:18:08 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 31 Oct 2012 21:18:08 +0000 Subject: [ilastik-devel] Renamed ilastik organization and 2 repositories Message-ID: Hi all, I've started to implement the slight changes mentioned in applet-workflows issue #26: http://github.com/ilastik/ilastik-0.6/issues/26 Please make note of the following changes: 1) On github, our organization's name is now "ilastik" not "Ilastik" (note the capitalization). For urls, it shouldn't matter. For git commands (e.g. git clone), it seems to make a difference. 2) The repo for ilastik v0.5 has been renamed to ilastik-0.5 3) The repo for applet-workflows has been renamed to ilastik-0.6 4) A new repo called ilastik-meta has been made for tagging release repo revisions. Note that if you have a local copy of the applet-workflows repo, you'll have to associate it with a new remote. Assuming github is your "origin" remote, you would rename it as follows: $ git remote -v origin ssh://git at github.com/ilastik/ilastik-0.6 (fetch) origin ssh://git at github.com/ilastik/ilastik-0.6 (push) $ git remote rm origin $ git remote add origin ssh://git at github.com/ilastik/ilastik-0.6 Similarly, you may need to rename your local copy of the ilastik 0.5 repo, if you have one. You may need to replace ssh with http, depending on how your git setup. -Stuart From bergs at janelia.hhmi.org Wed Oct 31 22:21:30 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 31 Oct 2012 21:21:30 +0000 Subject: [ilastik-devel] API changes Message-ID: Hi all, I committed a change to the ilastik-0.6 repo that will break your existing workflows when you update. The breaking change is minor: Your Workflow class must now inherit from lazyflow.graph.Operator. Also, applets used to accept the lazyflow graph as their first constructor argument. Now they expect the workflow. All workflows in the master branch have already been adapted to this change. Let me know if you have any questions. -Stuart From bergs at janelia.hhmi.org Wed Oct 31 22:29:54 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 31 Oct 2012 21:29:54 +0000 Subject: [ilastik-devel] Applet API Documentation Message-ID: <44F90911-52B4-401E-9F09-6460EA2592DA@janelia.hhmi.org> Hi all, The ilastik-0.6 repo has some developer documentation now. It's not complete, but it should help beginners get a handle on basic workflow design. The pre-built files are located in ilastik-0.6/docs/_build/html, or you can read them online here: http://ilastik.github.com/applet-workflows/ That online version won't update automatically. If you make changes to the documentation, let me know and I'll update the online copy. By the way, you can get rudimentary visualizations of your operators via the "Export Operator Diagram" menu item in the "Settings" menu of the ilastik shell. The svg diagram it produces MUST be opened with InkScape and exported before you can view it with Firefox. Let me know if you have any questions or suggestions for improvements. Stuart From markus.nullmeier at iwr.uni-heidelberg.de Wed Sep 19 17:28:05 2012 From: markus.nullmeier at iwr.uni-heidelberg.de (markus.nullmeier at iwr.uni-heidelberg.de) Date: Wed, 19 Sep 2012 17:28:05 +0200 Subject: [ilastik-devel] Ilastik Mail server hopefully working again Message-ID: <20120919172805.849bp99u1kc040wk@wwwmail.urz.uni-heidelberg.de> Dear all, after a certain hiatus, the ilastik.org mail services are going to be restored now. Please report any malfunctioning to markus.nullmeier at_glyph iwr.uni-heidelberg.de -- except for the list archives on mailman.ilastik.org, these have known defects and it will take some time to mend them. Kind regards, Markus From anna.kreshuk at iwr.uni-heidelberg.de Fri Sep 21 11:31:25 2012 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Fri, 21 Sep 2012 11:31:25 +0200 Subject: [ilastik-devel] documentation again Message-ID: <505C33ED.5020901@iwr.uni-heidelberg.de> Dear all, I made pdf documentation, which might be more convenient to look at. Cheers, Anna -------------- next part -------------- A non-text attachment was scrubbed... Name: cc-tab.pdf Type: application/pdf Size: 242501 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: project_tab.pdf Type: application/pdf Size: 3750882 bytes Desc: not available URL: From ullrich.koethe at iwr.uni-heidelberg.de Fri Sep 21 12:45:44 2012 From: ullrich.koethe at iwr.uni-heidelberg.de (Ullrich Koethe) Date: Fri, 21 Sep 2012 12:45:44 +0200 Subject: [ilastik-devel] documentation again In-Reply-To: <505C33ED.5020901@iwr.uni-heidelberg.de> References: <505C33ED.5020901@iwr.uni-heidelberg.de> Message-ID: <505C4558.9060501@iwr.uni-heidelberg.de> Hi Anna, excellent! Regarding the connected components functionality (not documentation): would it be useful to guess the background color, when the user asked for "CC with background" without giving a bg label? The guess would probably be right 99% of the time, and the user can still provide a scribble if it wasn't. Best regards Ulli > > I made pdf documentation, which might be more convenient to look at. > > Cheers, > Anna > > > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > From anna.kreshuk at iwr.uni-heidelberg.de Fri Sep 21 12:49:17 2012 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Fri, 21 Sep 2012 12:49:17 +0200 Subject: [ilastik-devel] documentation again In-Reply-To: <505C4558.9060501@iwr.uni-heidelberg.de> References: <505C33ED.5020901@iwr.uni-heidelberg.de> <505C4558.9060501@iwr.uni-heidelberg.de> Message-ID: <505C462D.2010605@iwr.uni-heidelberg.de> Hi Ulli, This would be great and would really simplify things. This distinction of "with/without" background is not easy to explain, and as you said in 99% of cases it's quite clear what the background is. Anna On 09/21/2012 12:45 PM, Ullrich Koethe wrote: > Hi Anna, > > excellent! > > Regarding the connected components functionality (not documentation): > would it be useful to guess the background color, when the user asked > for "CC with background" without giving a bg label? The guess would > probably be right 99% of the time, and the user can still provide a > scribble if it wasn't. > > Best regards > Ulli >> >> I made pdf documentation, which might be more convenient to look at. >> >> Cheers, >> Anna >> >> >> _______________________________________________ >> ilastik-devel mailing list >> ilastik-devel at ilastik.org >> http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel >> > > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From bergs at janelia.hhmi.org Wed Apr 24 18:15:30 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 24 Apr 2013 16:15:30 +0000 Subject: [ilastik-devel] Workflow input data constraints Message-ID: An HTML attachment was scrubbed... URL: From ullrich.koethe at iwr.uni-heidelberg.de Wed Apr 24 19:26:37 2013 From: ullrich.koethe at iwr.uni-heidelberg.de (Ullrich Koethe) Date: Wed, 24 Apr 2013 19:26:37 +0200 Subject: [ilastik-devel] Workflow input data constraints In-Reply-To: References: Message-ID: <517815CD.1040600@iwr.uni-heidelberg.de> Hi Stuart, very useful, thanks! Best regards Ulli From f.v.claus at googlemail.com Sun Feb 3 17:22:39 2013 From: f.v.claus at googlemail.com (Frederik Claus) Date: Sun, 3 Feb 2013 17:22:39 +0100 Subject: [ilastik-devel] execute() in toplevelOperator still not called Message-ID: Hi, After adding/removing the ImageLanes from the OutputSlot in both addLane and removeLane the execute method is still not called. I tried the Operator as a SingleLaneOperator and a MultiLaneOperator with different results. As SingleLaneOperator, setupOutputs is called with the correct Input shape but execute() is never called. As MultiLaneOperator, setupOutputs is called with a Input shape of None execute() is also never called. I have updated the code in 'lightfield-rebased' and removed everything unnecessary. The lightfieldApplet.py as well as the opLightfield.py have methods for both configurations. Also, for the sake of simplicity, the execute() of the opLightfield is a mere "raise RuntimeError("It works")". I am sorry to bother you with the same lame issue again, but I looked through the ilastik source and documentation several times trying to find out what the problem might be. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard.kausler at iwr.uni-heidelberg.de Mon Feb 4 16:53:29 2013 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Mon, 04 Feb 2013 16:53:29 +0100 Subject: [ilastik-devel] Accessing shell requests from StandardApplet Message-ID: <510FD979.3090801@iwr.uni-heidelberg.de> Hi Stuart, what is the canonical way to send shell requests when using the StandardApplet? Neither the GUI nor the SingleLaneOperator class have access to the applet and therefore the shell request mechanism. (Background: I want to use the progress bar shell request) Best, Bernhard From bergs at janelia.hhmi.org Tue Feb 5 17:04:07 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Tue, 5 Feb 2013 16:04:07 +0000 Subject: [ilastik-devel] Accessing shell requests from StandardApplet In-Reply-To: <510FD979.3090801@iwr.uni-heidelberg.de> References: <510FD979.3090801@iwr.uni-heidelberg.de> Message-ID: <3ED16114-1C48-4E56-8F2D-9F8EDCEEA599@janelia.hhmi.org> Hi Bernhard, > what is the canonical way to send shell requests when using the > StandardApplet? > > Neither the GUI nor the SingleLaneOperator class have access to the > applet and therefore the shell request mechanism. The signals you refer to are owned by the applet itself, but the applet is free to pass references to them to the gui(s) via __init__ parameters. Assuming your applet inherits from StandardApplet, the canonical way to do this would be to override StandardApplet.createSingleLaneGui(), in which you would pass in any extra args needed to construct your gui. For example, have a look at PixelClassificationApplet.createSingleLaneGui(). For a brief summary of the options for GUI construction in a StandardApplet subclass, see the doctoring for StandardApplet: http://ilastik.github.com/ilastik/applet_api.html#standardapplet-base-class > (Background: I want to use the progress bar shell request) Quick tip: The shell depends on a special protocol for applet progress updates: - Your task must begin with an update of 0 - Your task must eventually finish with a progress of 100 (unless you specify canceled=True). For example: self.progressSignal(0) self.progressSignal(0) # Repeat is okay self.progressSignal(50) self.progressSignal(100) self.progressSignal(100) # Repeat is okay I just noticed this protocol is not mentioned in the docs. I'll fix that. Lastly, if the progress updates will be originating from your operator, I recommend instantiating a lazyflow.utility.OrderedSignal in the operator itself, and then connecting that signal directly to the applet signal. Again, see the PixelClassificationApplet for an example. Best, Stuart From f.v.claus at googlemail.com Tue Jan 15 12:13:16 2013 From: f.v.claus at googlemail.com (Frederik Claus) Date: Tue, 15 Jan 2013 12:13:16 +0100 Subject: [ilastik-devel] applet-workflows nosetests fail Message-ID: Hi list, The tests for applet-workflows fail on my machine with the following error: Traceback (most recent call last): File "/home/.../workspace/applet-workflows/ilastik/applets/autocontextClassification/__init__.py", line 1, in from autocontextClassificationApplet import * File "/home/.../workspace/applet-workflows/ilastik/applets/autocontextClassification/autocontextClassificationApplet.py", line 2, in from opAutocontextClassification import OpAutocontextClassification File "/home/.../workspace/applet-workflows/ilastik/applets/autocontextClassification/opAutocontextClassification.py", line 9, in from context.operators.contextVariance import OpContextVariance ImportError: No module named context.operators.contextVariance I updated all depending projects and also grepped around for the python module context, but I can't find it anywhere. The opAutocontext Operator also seems to be the only operator that wants the context module. I have also noticed that there are now installation instructions for applet-workflows or maybe I can't find them. In the requirements/build_drtile.sh are also some system-specific paths, which I don't think belong there: cd lazyflow/drtile cmake -DVIGRA_NUMPY_CORE_LIBRARY=/home/travis/virtualenv/lib/python2.7/site-packages/vigra/vigranumpycore.so . make Thanks From bergs at janelia.hhmi.org Wed Jan 16 17:41:01 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 16 Jan 2013 16:41:01 +0000 Subject: [ilastik-devel] applet-workflows nosetests fail In-Reply-To: References: Message-ID: <597CE99A-F140-45BF-A229-C33014C5DE3F@janelia.hhmi.org> Hi Frederik, > The tests for applet-workflows fail on my machine with the following error: Thanks for reporting this. This particular failure shouldn't matter to you unless you need the autocontext workflow, but we shouldn't let the absence of the context library on your machine cause unrelated tests to fail. This is now fixed in the latest version of ilastik/master. > In the requirements/build_drtile.sh are also some system-specific > paths, which I don't think belong there: Good point. That script is used by our continuous integration tool. I understand your confusion at seeing it seeing it in the requirements directory, so I've moved it into a separate (hidden) directory now. -Stuart On Jan 15, 2013, at 6:13 AM, Frederik Claus wrote: > Hi list, > > The tests for applet-workflows fail on my machine with the following error: > > Traceback (most recent call last): > File "/home/.../workspace/applet-workflows/ilastik/applets/autocontextClassification/__init__.py", > line 1, in > from autocontextClassificationApplet import * > File "/home/.../workspace/applet-workflows/ilastik/applets/autocontextClassification/autocontextClassificationApplet.py", > line 2, in > from opAutocontextClassification import OpAutocontextClassification > File "/home/.../workspace/applet-workflows/ilastik/applets/autocontextClassification/opAutocontextClassification.py", > line 9, in > from context.operators.contextVariance import OpContextVariance > ImportError: No module named context.operators.contextVariance > > I updated all depending projects and also grepped around for the > python module context, but I can't find it anywhere. The opAutocontext > Operator also seems to be the only operator that wants the context > module. I have also noticed that there are now installation > instructions for applet-workflows or maybe I can't find them. > > In the requirements/build_drtile.sh are also some system-specific > paths, which I don't think belong there: > > cd lazyflow/drtile > cmake -DVIGRA_NUMPY_CORE_LIBRARY=/home/travis/virtualenv/lib/python2.7/site-packages/vigra/vigranumpycore.so > . > make > > Thanks > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From bergs at janelia.hhmi.org Wed Jan 16 18:06:43 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 16 Jan 2013 17:06:43 +0000 Subject: [ilastik-devel] ilastik batch process In-Reply-To: <50F6D595.30109@iwr.uni-heidelberg.de> References: <50F68848.7070504@iwr.uni-heidelberg.de> <0377AD8D-22B4-4B38-B164-B8786DD66345@janelia.hhmi.org> <50F6D595.30109@iwr.uni-heidelberg.de> Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: compose-unknown-contact.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1300 bytes Desc: postbox-contact.jpg URL: From luca.fiaschi at iwr.uni-heidelberg.de Wed Jan 16 21:31:41 2013 From: luca.fiaschi at iwr.uni-heidelberg.de (Luca Fiaschi) Date: Wed, 16 Jan 2013 21:31:41 +0100 Subject: [ilastik-devel] ilastik batch process In-Reply-To: References: <50F68848.7070504@iwr.uni-heidelberg.de> <0377AD8D-22B4-4B38-B164-B8786DD66345@janelia.hhmi.org> <50F6D595.30109@iwr.uni-heidelberg.de> Message-ID: > On a related note, I've been using JSON in other parts of ilastik lately. Perhaps it would be worth writing a general GUI window or widget that provides control over JSON parameters. The basic idea would be that the programmer specifies a JSON pseudo-schema, and GUI would be auto-generated from that schema. If we develop a mechanism like this, we should make sure it can also help us work towards the goal of "making GUI programming Interesting idea, and I think somebody have already implemented something like this: I found this old project but we should have our own clean implementation to avoid dependencies http://code.google.com/p/pyjsoneditor/ -- This mail was written on a iPhone keyboard, I apologize if the message is terse and for any spelling mistake Il giorno 16/gen/2013, alle ore 18:06, "Berg, Stuart" ha scritto: > Hi Luca, > > Since we're talking about both implementation issues and UI issues, I think this warrants some discussion. I've CC'd the mailing list. > >> I produce one single compressed hd5 volume out of the 1000 images (which includes subgroups for probability, original data , segmentation ... ). > > At the moment, the batch processing applet is designed with the assumption that it will be reading data from only a single slot, and outputting the data from that slot to a separate file for each image. Your use case sounds different. We have two options: Adapt the existing batch processing applet to handle more use-cases, or write a new batch processing applet for each use-case (hopefully sharing code for the common functionality). > >> Ideally I would like that the batch processing script of ilastik reads some configuration parameters from a json file: >> - files to precess >> - output file or files >> - output format >> - weather to store probability, segmentation,original data, features ... >> - level of compression for each output >> - weather to parallelize prediction at image level or process several images together. > > > In the current implementation, some of these parameters are hard-coded and some are controlled by the GUI. I agree that it would be good to support JSON as a configuration option, but we should still offer GUI control over these settings. > > On a related note, I've been using JSON in other parts of ilastik lately. Perhaps it would be worth writing a general GUI window or widget that provides control over JSON parameters. The basic idea would be that the programmer specifies a JSON pseudo-schema, and GUI would be auto-generated from that schema. If we develop a mechanism like this, we should make sure it can also help us work towards the goal of "making GUI programming optional". > > -Stuart > > > On Jan 16, 2013, at 11:30 AM, Luca Fiaschi wrote: > >> Hi, >> thanks for the quick reply. >> >> Just some number to convince ourself that it really makes sense to implement this approach: >> processing 1000 images right now takes > 3 hrs in a 24 core server (the cores are really badly exploited!) >> >> I have implemented a batch processing which produces several images in parallel with an external script >> The same 1000 images are done in around 5 min on the same machine. >> >> Of course would be much better to have a clean implementation inside the ilastik framework. >>> What format do you need it to produce? I could implement support for producing .png (or whatever) files. It would also be fairly easy for me to add a checkbox for "execute in parallel" or something like that. I don't know if I could do this today, but I could do it soon. When do you need it? >> I produce one single compressed hd5 volume out of the 1000 images (which includes subgroups for probability, original data , segmentation ... ). >> It is easy to compress them passing a level of compression flag to h5py. >> This can be a tremendous saving in memory for my type of data which have large areas of background reducing a file of several GB to few MB even with a very low compression. >> >> Ideally I would like that the batch processing script of ilastik reads some configuration parameters from a json file: >> - files to precess >> - output file or files >> - output format >> - weather to store probability, segmentation,original data, features ... >> - level of compression for each output >> - weather to parallelize prediction at image level or process several images together. >> When do you need it? >> As always would be better to have it as soon as possible ;-) >> >> Best >> Luca >> >> >> >> >> >> >> >>> Berg, Stuart January 16, 2013 5:07 PM >>> Hi Luca, >>> >>>> - Would the new ilastik process several images completely in parallel? >>> >>> >>> In the current implementation, no. It uses the OpH5WriterBigDataset to produce the output, which is tuned for volumes. I want to make it more adaptive in the future. Right now, it will work on each image serially, but the output image itself is broken up into blocks, and the blocks are computed in parallel. That's reasonable behavior for computing results for several large volumes, but not the right behavior for computing thousands of small images. >>> >>>> - Could I specify to save the results in compressed format so that I do not overflow my hard drive space. >>> >>> The batch operator is written to allow multiple output formats, but the only format implemented so far is hdf5. By default, it does not compress the output. >>> >>>> if not how much effort would it be to implement these capabilities. >>> >>> What format do you need it to produce? I could implement support for producing .png (or whatever) files. It would also be fairly easy for me to add a checkbox for "execute in parallel" or something like that. I don't know if I could do this today, but I could do it soon. When do you need it? >>> >>> -Stuart >>> >>> On Jan 16, 2013, at 6:00 AM, Luca Fiaschi wrote: >>> >>>> Hi Stuart, >>>> I have a technical question. >>>> I have to process around 60.000 images each one 1400*1400 pixels. ilastik 0.5 is taking ages because process serially each image, (taking 5-10 seconds per image), not exploiting the multiple cores of the server I'm working on. >>>> >>>> - Would the new ilastik process several images completely in parallel? >>>> - Could I specify to save the results in compressed format so that I do not overflow my hard drive space. >>>> >>>> if not how much effort would it be to implement these capabilities. >>>> >>>> >>>> Best and Thanks, >>>> Luca >>>> >>>> -- >>>> Luca Fiaschi >>>> IWR - Heidelberg University >>>> Speyerer str. 6 - office H2.12 >>>> 69115 Heidelberg >>>> Tel: +49 (6221) 54 - 5280 >>>> Fax: +49 (6221) 54 - 5276 >>>> >>> >>> Luca Fiaschi January 16, 2013 12:00 PM >>> Hi Stuart, >>> I have a technical question. >>> I have to process around 60.000 images each one 1400*1400 pixels. ilastik 0.5 is taking ages because process serially each image, (taking 5-10 seconds per image), not exploiting the multiple cores of the server I'm working on. >>> >>> - Would the new ilastik process several images completely in parallel? >>> - Could I specify to save the results in compressed format so that I do not overflow my hard drive space. >>> >>> if not how much effort would it be to implement these capabilities. >>> >>> >>> Best and Thanks, >>> Luca >> >> -- >> Luca Fiaschi >> IWR - Heidelberg University >> Speyerer str. 6 - office H2.12 >> 69115 Heidelberg >> Tel: +49 (6221) 54 - 5280 >> Fax: +49 (6221) 54 - 5276 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.v.claus at googlemail.com Fri Jan 18 18:16:29 2013 From: f.v.claus at googlemail.com (Frederik Claus) Date: Fri, 18 Jan 2013 18:16:29 +0100 Subject: [ilastik-devel] How to subclass LayerViewerGUI properly Message-ID: Hi, I have run into a problem. Here is the scenario: I have a Gui that inherits from LayerViewerGui and a Operator, that has been a WrappedOperator before the lane paradigm was introduced. I assume the LayerViewerGui cannot be used with getMultiLaneGui, therefore I have to use the properties singleLaneOperatorClass and broadcastingSlots. I have attached the operator diagram of how it is supposed to work. No matter what I return from broadcastingSlots, I always run into this error: File "/home/.../ilastik/utility/gui/threadRouter.py", line 43, in routed func(*args, **kwargs) File "/home/.../ilastik/applets/layerViewer/layerViewerGui.py", line 280, in updateAllLayers raise RuntimeError(msg) RuntimeError: All layers must have unique names. You're attempting to use these layer names: ['Outputs 0', 'Outputs 0'] This array is returned from the LayerViewerGui.setupLayers() method. I dug around a little and found out that the name of a slot got lost starting line 118 of the layerViewerGui file. for slot in observedSlots: if slot.level == 0: # To be monitored and updated correctly by this GUI, slots must have level=1, but this slot is of level 0. # Pass it through a trivial "up-leveling" operator so it will have level 1 for our purposes. opPromoteInput = Op1ToMulti(graph=slot.operator.graph) opPromoteInput.Input.connect(slot) slot = opPromoteInput.Outputs self._orphanOperators.append( opPromoteInput ) Afterwards the slot.name seems to always return "Output". I have also pushed my code into the branch 'lightfield' into the ilastik.applets.lightfield module. Here is the Operator definition: InputImage = InputSlot() outerScale = InputSlot() innerScale = InputSlot() Output = OutputSlot() Here the applet code: @property def singleLaneGuiClass(self): from lightfieldGui import LightfieldGui return LightfieldGui @property def singleLaneOperatorClass(self): return LightfieldOperator @property def broadcastingSlots(self): # return ["outerScale", "innerScale"] # return ["InputImage"] return [] Thanks for your help -------------- next part -------------- A non-text attachment was scrubbed... Name: Wrapped Operator (base class).svg Type: image/svg+xml Size: 9411 bytes Desc: not available URL: From bergs at janelia.hhmi.org Fri Jan 18 20:33:52 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Fri, 18 Jan 2013 19:33:52 +0000 Subject: [ilastik-devel] How to subclass LayerViewerGUI properly In-Reply-To: References: Message-ID: <4AA839F2-A710-424B-84F5-555E12E9AEB3@janelia.hhmi.org> Hi Frederik, > No matter what I return from broadcastingSlots, I always run into this error: > RuntimeError: All layers must have unique names. Thanks for the detailed description of your problem, and thanks (especially) for pushing your code so I could investigate. In most cases, applet authors should override the default implementation of LayerViewerGui.setupLayers(). In fact, previous versions of the LayerViewerGui *required* you to override it (it was an abstract method). However, a default implementation is now provided as a convenience for prototyping. Unfortunately, that default version had a bug that you ran into. The bug is now fixed in ilastik/master. Side note: I find the "git rebase" command (and git rebase --interactive) to be very useful in cases such as yours, where you are developing a branch in parallel to master. Instead of periodically *merging* from ilastik/master into your branch, it may be easier to periodically *rebase* your branch from ilastik/master. Sometimes rebasing avoids messy merge issues, and the commit graph is usually easier to follow when viewed in gitk. (It's a matter of opinion.) In case you find it helpful, I've pushed a new version of your branch called "lightfield-rebased", which is based on the most recent version of ilastik/master. There are a few caveats to be aware of, so read the man page first. If you already know about git-rebase, then sorry to bore you :-) Best regards, Stuart On Jan 18, 2013, at 12:16 PM, Frederik Claus wrote: > Hi, > > I have run into a problem. Here is the scenario: > I have a Gui that inherits from LayerViewerGui and a Operator, that > has been a WrappedOperator before the lane paradigm was introduced. I > assume the LayerViewerGui cannot be used with getMultiLaneGui, > therefore I have to use the properties singleLaneOperatorClass and > broadcastingSlots. I have attached the operator diagram of how it is > supposed to work. > > No matter what I return from broadcastingSlots, I always run into this error: > File "/home/.../ilastik/utility/gui/threadRouter.py", line 43, in routed > func(*args, **kwargs) > File "/home/.../ilastik/applets/layerViewer/layerViewerGui.py", line > 280, in updateAllLayers > raise RuntimeError(msg) > RuntimeError: All layers must have unique names. > You're attempting to use these layer names: > ['Outputs 0', 'Outputs 0'] > > This array is returned from the LayerViewerGui.setupLayers() method. > > I dug around a little and found out that the name of a slot got lost > starting line 118 of the layerViewerGui file. > > for slot in observedSlots: > if slot.level == 0: > # To be monitored and updated correctly by this GUI, > slots must have level=1, but this slot is of level 0. > # Pass it through a trivial "up-leveling" operator so > it will have level 1 for our purposes. > opPromoteInput = Op1ToMulti(graph=slot.operator.graph) > opPromoteInput.Input.connect(slot) > slot = opPromoteInput.Outputs > self._orphanOperators.append( opPromoteInput ) > > Afterwards the slot.name seems to always return "Output". > I have also pushed my code into the branch 'lightfield' into the > ilastik.applets.lightfield module. > > Here is the Operator definition: > > InputImage = InputSlot() > outerScale = InputSlot() > innerScale = InputSlot() > > Output = OutputSlot() > > Here the applet code: > > @property > def singleLaneGuiClass(self): > from lightfieldGui import LightfieldGui > return LightfieldGui > > @property > def singleLaneOperatorClass(self): > return LightfieldOperator > > @property > def broadcastingSlots(self): > # return ["outerScale", "innerScale"] > # return ["InputImage"] > return [] > > Thanks for your help > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From bergs at janelia.hhmi.org Tue Jan 22 17:17:59 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Tue, 22 Jan 2013 16:17:59 +0000 Subject: [ilastik-devel] Request Framework upgrade merged to lazyflow/master. Message-ID: Hi all, An upgraded implementation of the lazyflow request framework has been merged into lazyflow/master. For the most part, the new implementation works on the same principles as the old version, but with a few new features. The API was cleaned up a little bit, but -- for now -- the old API is still supported. This means that you shouldn't be forced to upgrade any of your code (yet). Even so, the old implementation hasn't been deleted yet. If you want to quickly switch between request system back-end implementations, edit lazyflow/request/__init__.py. The request system now has fairly comprehensive documentation: http://ilastik.github.com/lazyflow/request.html If you have any questions about the new functionality or its implementation, please read the docs. Also, lots of examples can be found in the unit tests: tests/testRequestRewrite.py. Briefly, the most important new features are: 1) If an exception is thrown within a request, it is propagated to its parent request. This makes debugging much easier, and allows you to handle failures in the usual python way (exception handling). 2) Requests can be cancelled. From the request's point of view, cancellation results in an exception. 3) The special Request Lock mechanism has been improved. Now you can use it from within requests and non-request threads. 4) Performance in real-world use-cases is comparable to the old implementation, but the ThreadPool queuing scheme is now configurable to allow us to quickly and cleanly experiment with Request prioritization schemes in the future. Best regards, Stuart From bernhard.kausler at iwr.uni-heidelberg.de Tue Jan 22 17:32:01 2013 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Tue, 22 Jan 2013 17:32:01 +0100 Subject: [ilastik-devel] Request Framework upgrade merged to lazyflow/master. In-Reply-To: References: Message-ID: <50FEBF01.7000704@iwr.uni-heidelberg.de> Stuart, beautiful work! - Bernhard On 22/01/13 17:17, Berg, Stuart wrote: > Hi all, > > An upgraded implementation of the lazyflow request framework has been merged into lazyflow/master. > > For the most part, the new implementation works on the same principles as the old version, but with a few new features. The API was cleaned up a little bit, but -- for now -- the old API is still supported. This means that you shouldn't be forced to upgrade any of your code (yet). Even so, the old implementation hasn't been deleted yet. If you want to quickly switch between request system back-end implementations, edit lazyflow/request/__init__.py. > > The request system now has fairly comprehensive documentation: http://ilastik.github.com/lazyflow/request.html > > If you have any questions about the new functionality or its implementation, please read the docs. Also, lots of examples can be found in the unit tests: tests/testRequestRewrite.py. > > Briefly, the most important new features are: > > 1) If an exception is thrown within a request, it is propagated to its parent request. This makes debugging much easier, and allows you to handle failures in the usual python way (exception handling). > > 2) Requests can be cancelled. From the request's point of view, cancellation results in an exception. > > 3) The special Request Lock mechanism has been improved. Now you can use it from within requests and non-request threads. > > 4) Performance in real-world use-cases is comparable to the old implementation, but the ThreadPool queuing scheme is now configurable to allow us to quickly and cleanly experiment with Request prioritization schemes in the future. > > Best regards, > Stuart > > > > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > From bergs at janelia.hhmi.org Tue Jan 22 18:48:25 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Tue, 22 Jan 2013 17:48:25 +0000 Subject: [ilastik-devel] Request Framework upgrade merged to lazyflow/master. In-Reply-To: References: <50FEBF01.7000704@iwr.uni-heidelberg.de> Message-ID: An HTML attachment was scrubbed... URL: From thorben.kroeger at iwr.uni-heidelberg.de Wed Jan 23 15:30:23 2013 From: thorben.kroeger at iwr.uni-heidelberg.de (Thorben Kroeger) Date: Wed, 23 Jan 2013 15:30:23 +0100 Subject: [ilastik-devel] Request Framework upgrade merged to lazyflow/master. In-Reply-To: References: Message-ID: <50FFF3FF.5060306@iwr.uni-heidelberg.de> Hi Stuart, > The request system now has fairly comprehensive documentation: http://ilastik.github.com/lazyflow/request.html That's really outstanding documentation! Cheers, Thorben From f.v.claus at googlemail.com Thu Jan 24 15:25:36 2013 From: f.v.claus at googlemail.com (Frederik Claus) Date: Thu, 24 Jan 2013 15:25:36 +0100 Subject: [ilastik-devel] execute() in toplevelOperator not called Message-ID: Hi, The setupLayers() problem seems to be resolved now. But now when I chang the value of my InputSlots the execute() method of my Operator is never executed. Kind of clueless what to do I tried to copy the exact setup of the deviationFromMean workflow, because it also uses the LayerViewerGui. Now I get this error: File "/home/.../workflows/lightfield/lightfieldWorkflow.py", line 41, in connectLane opLightfield = self.lightfieldApplet.topLevelOperatorView.getLane(laneIndex) File "/home/.../ilastik/applets/lightfield/opCalcDepth.py", line 111, in getLane return OperatorSubView(self, laneIndex) File "/home/.../ilastik/utility/operatorSubView.py", line 56, in __init__ self.outputs[slot.name] = slot[index] File "/home/.../ilastikenv/local/lib/python2.7/site-packages/lazyflow-0.0.0-py2.7.egg/lazyflow/graph.py", line 769, in __getitem__ return self._subSlots[key] IndexError: list index out of range I really don't understand whats going on since the Operator looks identical to the one in deviationFromMean. The code still resides in lightfield-rebased. From bergs at janelia.hhmi.org Wed Jan 30 00:26:39 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Tue, 29 Jan 2013 23:26:39 +0000 Subject: [ilastik-devel] execute() in toplevelOperator not called In-Reply-To: References: Message-ID: <78D284E9-2C52-48D1-986E-D0AE2CC0A436@janelia.hhmi.org> Hi Frederik, It looks like the OpCalcDepth.addLane() function is not resizing the output slot, but it needs to. I've pushed a fix for this to your branch. You aren't the first person to have this problem, so I've tried to clear up the confusion regarding addLane() with a note in the documentation: http://ilastik.github.com/ilastik/utilities.html#ilastik.utility.MultiLaneOperatorABC I hope that helps. Best regards, Stuart On Jan 24, 2013, at 9:25 AM, Frederik Claus wrote: > Hi, > > The setupLayers() problem seems to be resolved now. But now when I > chang the value of my InputSlots the execute() method of my Operator > is never executed. Kind of clueless what to do I tried to copy the > exact setup of the deviationFromMean workflow, because it also uses > the LayerViewerGui. Now I get this error: > > File "/home/.../workflows/lightfield/lightfieldWorkflow.py", line > 41, in connectLane > opLightfield = self.lightfieldApplet.topLevelOperatorView.getLane(laneIndex) > File "/home/.../ilastik/applets/lightfield/opCalcDepth.py", line > 111, in getLane > return OperatorSubView(self, laneIndex) > File "/home/.../ilastik/utility/operatorSubView.py", line 56, in __init__ > self.outputs[slot.name] = slot[index] > File "/home/.../ilastikenv/local/lib/python2.7/site-packages/lazyflow-0.0.0-py2.7.egg/lazyflow/graph.py", > line 769, in __getitem__ > return self._subSlots[key] > IndexError: list index out of range > > I really don't understand whats going on since the Operator looks > identical to the one in deviationFromMean. The code still resides in > lightfield-rebased. > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From bernhard.kausler at iwr.uni-heidelberg.de Wed Jul 24 17:35:25 2013 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Wed, 24 Jul 2013 17:35:25 +0200 Subject: [ilastik-devel] Ilastik Online Auto Updater Message-ID: <51EFF43D.8090909@iwr.uni-heidelberg.de> Dear all, an online auto update mechanism for already deployed ilastik installations would be an excellent new feature for ilastik >= 0.7. If found a pycon talk discussing various options: "Deep Freeze: building better stand-alone apps with Python" by Ryan Kelly http://lanyrd.com/2012/pycon/spckh/ The purpose of this email is to preserve the information for future use :) - Bernhard Abstract: """ here's more to shipping a stand-alone python app than just running py2exe over your code. Want to deploy automatic updates? Want to be sure it runs on legacy platforms? Want to add professional touches like code signing? And want to do this all in a cross-platform manner? This talk will show you the tools you can use to make your frozen apps better in a variety of small yet important ways. Overview Python has a powerful and mature suite tools of tools for "freezing" your python scripts into a stand-alone application, including py2exe, py2app, cxfreeze, bbfeezee and PyInstaller. But there's more to shipping a stand-alone app than just running py2exe over your code. This talk will show you the tools you can use to make your frozen apps better in a variety of small yet important ways. Want to deploy automatic updates? The "esky" package provides a simple API for building, publishing and installing updates, and jumps through all the hoops needed to ensure failed updates won't leave your program unusable. Need to run on older versions of OSX or ancient linux boxes? The "myppy" package can build a python runtime optimized for portable deployment and binary compatibility with older systems. Want to add code-signing for that professional touch? The "signedimp" package provides cross-platform hooks for code signing and extends the protection to code loaded at runtime. Each of these tools has been extracted from a real-life build process for a complex cross-platform application, and each is designed to help make your frozen applications just that little bit better. """ -- gpg: 4096R/CB6C6107 2013-07-21 Fingerprint=DE4D E0F5 DA9E 13A2 68EC 61E8 36EF ABDE CB6C 6107 From bergs at janelia.hhmi.org Wed May 29 06:04:04 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 29 May 2013 04:04:04 +0000 Subject: [ilastik-devel] ilastik testing vm Message-ID: Hi all, I pushed a new repo to github called ilastik-test-vm. It's a VM that we can all use to record test cases for our workflows. The VM gives us a common platform for debugging and verification of incorrect behavior. Tests generated in the VM should also run on Travis-CI. The basic usage is explained in the Readme file in the repo: http://github.com/ilastik/ilastik-test-vm If you have moment, please give it a try. Once you've installed the VM, you should be able to run the existing test cases by typing this into the VM shell: $ cd ilastik $ ./tests/run_recorded_tests.sh If that worked, try recording a simple (or not-so-simple) test-case for your favorite workflow. We need more test cases. Best regards, Stuart From timony+ilastik.org at hkl.hms.harvard.edu Fri Oct 18 17:38:28 2013 From: timony+ilastik.org at hkl.hms.harvard.edu (Mick Timony) Date: Fri, 18 Oct 2013 11:38:28 -0400 Subject: [ilastik-devel] run-ilastik-linux.sh: PYTHONPATH Typo Message-ID: Hello, The Linux 64-bit tarball available on the download page has a typo in the run-ilastik-linux.sh script. PYTHONPATH is set to the following, and one of the instances of PREFIX is misspelt as PREFX: export PYTHONPATH=$PREFIX:$PREFIX/lib:$PREFX/lib/python2.7/site-packages This should be: export PYTHONPATH=$PREFIX:$PREFIX/lib:$PREFOX/lib/python2.7/site-packages The tarball is linked to from this page: http://klimt.iwr.uni-heidelberg.de/index.php?cat=Download The location of the tarball is at: http://klimt.iwr.uni-heidelberg.de/cms/download.php?cat=15_Download&file=ilastik-0.5-linux-v0.5.12-x86-64.tar.gz Regards Mick Timony -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumartr at gmail.com Wed Sep 11 17:59:55 2013 From: kumartr at gmail.com (Kumar Rajamani) Date: Wed, 11 Sep 2013 21:29:55 +0530 Subject: [ilastik-devel] Reg: Import of Classifier Message-ID: Dear All, There exist option to save a classifier once it has been trained on some samples This is an export classifier which exists Unfortunately there is no feature to import a learnt classifier (from a earlier training using ilastik) This is generally needed if one happens to train/test over several days and wants to export the classifier This might be a good feature to be incorporated into ilastik in future realses Warm Regards Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From timony+ilastik.org at hkl.hms.harvard.edu Thu Sep 12 00:16:22 2013 From: timony+ilastik.org at hkl.hms.harvard.edu (Mick Timony) Date: Wed, 11 Sep 2013 18:16:22 -0400 Subject: [ilastik-devel] Source tarball link broken Message-ID: Hello the link at the following page http://www.ilastik.org/index.php?cat=Download to the latest source tar ball doesn't work. The link points to https://github.com/Ilastik/ilastik/tarball/v0.5.12 . Thanks -- Mick Timony Scientific Web Services Developer SBGrid Consortium - SBGrid.org Harvard Medical School -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From burcin at erocal.org Thu Sep 12 10:06:23 2013 From: burcin at erocal.org (Burcin Erocal) Date: Thu, 12 Sep 2013 10:06:23 +0200 Subject: [ilastik-devel] Fw: Source tarball link broken Message-ID: <20130912100623.5fa454ba@carl.erocal.org> The following was intended for the list. Coffee takes a while to kick in apparently. Cheers, Burcin Begin forwarded message: Date: Thu, 12 Sep 2013 09:56:18 +0200 From: Burcin Erocal To: Mick Timony Subject: Re: [ilastik-devel] Source tarball link broken Hi Mick, On Wed, 11 Sep 2013 18:16:22 -0400 Mick Timony wrote: > Hello the link at the following page > > http://www.ilastik.org/index.php?cat=Download > > to the latest source tar ball doesn't work. > > The link points to > https://github.com/Ilastik/ilastik/tarball/v0.5.12 . Indeed, this is just asking github to package the sources for the given tag. It seems that the only tag in the repository is gh-pages-start-commit. @ilastik team, were the tags lost at some point? As a workaround, the source tarball is also available here: http://www.ilastik.org/cms/download.php?cat=15_Download&file=ilastik-v0.5.12.tar.gz Cheers, Burcin From kumartr at gmail.com Sat Sep 14 10:18:12 2013 From: kumartr at gmail.com (Kumar Rajamani) Date: Sat, 14 Sep 2013 13:48:12 +0530 Subject: [ilastik-devel] Reg: Import of Classifier Message-ID: Dear Christoph Thanks for your prompt response and for sharing your suggestions I have tried the option of saving the ilastik project and reloading it on restart As I observed, when restarted, the training information done in earlier session is lost and ilastik has to be retrained, This takes up time and is repeated effort Another observation is that, just like export helps in connecting bridging two applications (ilastik and CellProfiler) Similarly Import would help to bridge two users of ilastik One expert builds the classifier and saves as HF5 file using export Another regular user could use this by importing the HF5 classifier file and testing on other datasets Hence I suggested having a import of classifier could be a good option to have Also it would help to connect and use another Classifier like those within Fiji (ImageJ) and building over it using ilastik viz - (Fiji, ilastik connect) Warm Regards Kumar On Thu, Sep 12, 2013 at 2:23 PM, Christoph Sommer < christoph.sommer at imba.oeaw.ac.at> wrote: > Dear Kumar, > > to achieve this, simply save an ilastik project. Also in there the > classifier is saved. The export function is just needed to interface to > other tools such as CellProfiler or commercial software. > > Best, > Christoph > > > learnt classifier (from a earlier training using ilastik) >> This is generally needed if one happens to train/test over several days >> and wants to export the classifier >> This might be a good feature to be incorporated into ilastik in future >> realses >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard.kausler at iwr.uni-heidelberg.de Mon Sep 16 11:21:38 2013 From: bernhard.kausler at iwr.uni-heidelberg.de (Bernhard X. Kausler) Date: Mon, 16 Sep 2013 11:21:38 +0200 Subject: [ilastik-devel] Fw: Source tarball link broken In-Reply-To: <20130912100623.5fa454ba@carl.erocal.org> References: <20130912100623.5fa454ba@carl.erocal.org> Message-ID: <5236CDA2.3000907@iwr.uni-heidelberg.de> Dear Burcin and Mick, just to unveil the mystery: some time ago we renamed the ilastik 0.5 from "ilastik" to "ilastik-05" and "ilastik" is now 0.6 and later. That's why the tag disappeared. Best, Bernhard On 09/12/2013 10:06 AM, Burcin Erocal wrote: > The following was intended for the list. Coffee takes a while to kick > in apparently. > > Cheers, > Burcin > > Begin forwarded message: > > Date: Thu, 12 Sep 2013 09:56:18 +0200 > From: Burcin Erocal > To: Mick Timony > Subject: Re: [ilastik-devel] Source tarball link broken > > > Hi Mick, > > On Wed, 11 Sep 2013 18:16:22 -0400 > Mick Timony wrote: > >> Hello the link at the following page >> >> http://www.ilastik.org/index.php?cat=Download >> >> to the latest source tar ball doesn't work. >> >> The link points to >> https://github.com/Ilastik/ilastik/tarball/v0.5.12 . > > Indeed, this is just asking github to package the sources for > the given tag. It seems that the only tag in the repository is > gh-pages-start-commit. > > @ilastik team, were the tags lost at some point? > > > As a workaround, the source tarball is also available here: > > http://www.ilastik.org/cms/download.php?cat=15_Download&file=ilastik-v0.5.12.tar.gz > > > Cheers, > Burcin > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > From anna.kreshuk at iwr.uni-heidelberg.de Tue Apr 8 09:08:32 2014 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Tue, 08 Apr 2014 09:08:32 +0200 Subject: [ilastik-devel] ilastik vtk problem In-Reply-To: <020c01cf52f1$daf3cb00$90db6100$@helsinki.fi> References: <5321EDBD.6080806@iwr.uni-heidelberg.de> <020c01cf52f1$daf3cb00$90db6100$@helsinki.fi> Message-ID: <5343A070.9000509@iwr.uni-heidelberg.de> Hi Ilya, Thanks so much for your feedback! > Is there any difference between drawing one long seed or several smaller > ones? Seeds are locations where the object is "anchored". I don't think there is a universal recipe: for an elongated, but thin object it might make sense to draw one long seed, for a more round one with a lot of clutter around the boundary it might be better to add several small seeds near that boundary. > 1. The Clear button - it wipes everything without even confirming whether it > is really needed. And since it is next to the Segment button it is very easy > to press. I accidently pressed it at least twice while trying to reach the > Erase button. We'll make a pop-up to confirm (I added an issue at http://github.com/ilastik/ilastik/issues/873). > 2. In my program I use Ctrl+Mouse click to enable eraser, why can't you add > it as well? It is very handy when it is required to erase a wrong seen. The > current shortcuts are in different part of the keyboard and thus not easy to > reach. We used to have it in 0.5 and then it didn't make it over to 1.0. I'm not sure if there is a reason for it (maybe the other devs know?), if not we'll add it back. > 3. Shortcuts for Background (1) and Object (2) do not work. Will be fixed (https://github.com/ilastik/ilastik/issues/874) > 4. Is it possible to import own labels (background/object) to the Carving > module? It would be nice to have such possibility (something like the Import > labels button). No, it's currently not even possible for pixel classification, where it would really make sense. It's on our todo list, people keep asking for it. > 5. Is there any Undo system? You mean, besides the Eraser? No. But we want to add the possibility to quickly navigate between the labels/seeds, and once it's there we'll hopefully not need the real Undo. > 6. Is it so that I can't have Background and Two objects in this mode? No, you can't. We found that having only 1 active object makes the book-keeping of objects much simpler. But you can draw background seeds on the already completed and saved objects. Thanks again and don't hesitate to contact us if you have any other comments or suggestions (and especially if you find things not working as you would expect). Anna > > > > -----Original Message----- > From: Anna Kreshuk [mailto:anna.kreshuk at iwr.uni-heidelberg.de] > Sent: 13 March 2014 19:41 > To: ilya.belevich at helsinki.fi > Cc: Burcin Erocal > Subject: ilastik vtk problem > > Hi Ilya, > > About that ilastik crash you had when you tried the new version. I talked > with the other devs, and it seems like this error has been observed before > on a machine w/o a proper openGL installation. Besides, it might be some > other vtk corner case which we don't detect properly. > Can you send your graphic card specs to help us debug it further? > > Hope you are enjoying the rest of your Ghent visit. > > Thanks, > Anna > From anna.kreshuk at iwr.uni-heidelberg.de Wed Apr 9 11:20:15 2014 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Wed, 09 Apr 2014 11:20:15 +0200 Subject: [ilastik-devel] [Team] Test beta In-Reply-To: References: <534398F1.2070505@iwr.uni-heidelberg.de> <5343C829.8060500@iwr.uni-heidelberg.de> Message-ID: <534510CF.9080405@iwr.uni-heidelberg.de> Hi James, It looks like you have the path to the result file pasted twice. It starts with C:/ and then has another C:/ in the middle. I did a quick check, and I see that we paste the default path behind the selected path. This is, of course, a bug and we'll fix it right away. Meanwhile, you could try to input this location manually. I attached a screenshot of the choose settings dialogue. Try to replace the {dataset_dir} by some meaningful name, like "test_export". Afterwards, check that it's correct in the "Export location" field of the applet (another screenshot). Otherwise, I think ilastik is perfectly suited for your task, but unfortunately there are still bugs standing in your way. Sorry for the inconvenience Anna On 09.04.2014 09:36, James Burchfield wrote: > Hi Anna, > Thanks for the info. I am struggling a little. > With version 0.5xxxx, i generated a classifier and batch processed. > Got the *.h5 files, but cannot seem to do anything with them. Tried > an .H5 viewer. I can reopen them in Ilastik and the data seems to be > there. I found an imageJ plugin for openiing HD5 images but his > didn't work either. > With the new version, I attempted to import the old project file, but > this failed. > I generated a new project and classifier, but have got stuck trying to > batch process. I get the error > Inline image 1 > Essentially what I am attempting to do is identify objects in a > section of tissue, count them and calculate the area. > Any help and or suggestions would be much appreciated. > > Cheers, > James > > __ > *Dr James Burchfield* > The Garvan Institute of Medical Research > 384 Victoria Street > Darlinghurst, NSW, 2010 > Australia > > Email: j.burchfield at garvan.org.au > Phone:+61 2 92958229 > Web:_www.garvan.org.au _ > > > On Tue, Apr 8, 2014 at 7:58 PM, Anna Kreshuk > > wrote: > > This version has been specifically developed for large datasets! > You can now explore and label in different parts of the image and > only the current field of view will be computed. Of course, you > can then process the whole image blockwise in batch mode. The one > thing not to do is zoom out fully and try to predict the whole > image in "live update" mode. This will actually try to compute the > whole image, like the 0.5 version. Otherwise, I think the new > version should be much better suited to your needs. > > Let me know if something does not work as expected or if you want > some pointers about the new version. > Anna > > > On 08.04.2014 10:24, James Burchfield wrote: >> Thanks Anna, >> I will have a play. >> Is this version better at handling large datasets? >> We often deal with large mosaic images (~250MB) and I find that >> version 0.5x tends to struggle. >> Having said that, the power of this software is awesome. >> Cheers, >> James >> >> __ >> *Dr James Burchfield* >> The Garvan Institute of Medical Research >> 384 Victoria Street >> Darlinghurst, NSW, 2010 >> Australia >> >> Email: j.burchfield at garvan.org.au >> Phone:+61 2 92958229 >> Web:_www.garvan.org.au _ >> >> >> On Tue, Apr 8, 2014 at 4:36 PM, Anna Kreshuk >> > > wrote: >> >> Hi James, >> >> Thanks for your interest! You can find the binaries for all >> platforms here: http://ilastik.github.io/download. There are >> also test datasets on the same page and the documentation is >> at http://ilastik.github.io/documentation/index.html. >> >> We'd appreciate your feedback for this version, so don't >> hesitate to contact us in case of any problems with the >> installation or anything else, >> Anna >> >> >> On 08.04.2014 02:11, James Burchfield wrote: >>> Hi there, >>> I would be interested in testing the beta version of Ilastik 1.0 >>> Cheers, >>> James >>> __ >>> *Dr James Burchfield* >>> The Garvan Institute of Medical Research >>> 384 Victoria Street >>> Darlinghurst, NSW, 2010 >>> Australia >>> >>> Email: j.burchfield at garvan.org.au >>> >>> Phone:+61 2 92958229 >>> Web:_www.garvan.org.au _ >>> >>> >>> >>> _______________________________________________ >>> team mailing list >>> team at ilastik.org >>> http://mailman.ilastik.org/cgi-bin/mailman/listinfo/team >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 17883 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Image Export Options_727.png Type: image/png Size: 67500 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: export_location.png Type: image/png Size: 478755 bytes Desc: not available URL: From anna.kreshuk at iwr.uni-heidelberg.de Wed Apr 9 14:06:43 2014 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Wed, 09 Apr 2014 14:06:43 +0200 Subject: [ilastik-devel] [Team] Test beta In-Reply-To: References: <534398F1.2070505@iwr.uni-heidelberg.de> <5343C829.8060500@iwr.uni-heidelberg.de> <534510CF.9080405@iwr.uni-heidelberg.de> Message-ID: <534537D3.2040600@iwr.uni-heidelberg.de> Hi James, I fixed the bug, but it will take us a while more to roll out the new binaries. Meanwhile, you can do the following to batch process multiple images: 1) Select all the images you want in the Batch Inputs applet 2) In the batch export applet (last tab from the bottom), click "Choose settings". 3) You will see {dataset_dir}/{nickname}_export.h5 in the filename string. This means that the ilastik predictions for your files will be exported to the same directory, where the raw images were, under the same filename with a suffix "_export". If you want a different directory, type it it instead of the {dataset_dir}. If you want a different suffix, type it instead of "_export". The pattern will be applied to all your files, you only have to do it once. 4) Click "Export All" button, or individual "Export" buttons near the file names. Unfortunately, we only provide the export of probability maps in batch mode. Providing segmentations is high on our priority list, but it's not there yet. However, you can easily do it in FiJi, which should also have plugins for area measurement (save as tiff for later FiJi use). I am not a FiJi expert myself, but on theilastik documentation page , right under "User documentation" heading, there is a link to a manual, written for a FiJi/ilastik course. In particular, you might be interested in chapter 4. It's about the 3D Object based colocalization, but the ilastik part is the same as in your case. Thanks a lot for your feedback and patience. Anna On 09.04.2014 12:07, James Burchfield wrote: > Hi Anna, > Thanks for the response. > Lets say I have a test set that I have trained. > And I now want to apply the classifier to all images in the dataset. > All I want is to export is the hard segmentation, not the > probabilities. How do I do this. Alternatively if i want to count > objects and measure area, can i do this within the software of do i > need to do this externally? > I feel close to having achieved my goal but I am unsure of how to > proceed. > Hope this make sense. > Cheers, > James > > __ > *Dr James Burchfield* > The Garvan Institute of Medical Research > 384 Victoria Street > Darlinghurst, NSW, 2010 > Australia > > Email: j.burchfield at garvan.org.au > Phone:+61 2 92958229 > Web:_www.garvan.org.au _ > > > On Wed, Apr 9, 2014 at 7:20 PM, Anna Kreshuk > > wrote: > > Hi James, > > It looks like you have the path to the result file pasted twice. > It starts with C:/ and then has another C:/ in the middle. I did a > quick check, and I see that we paste the default path behind the > selected path. This is, of course, a bug and we'll fix it right > away. Meanwhile, you could try to input this location manually. I > attached a screenshot of the choose settings dialogue. Try to > replace the {dataset_dir} by some meaningful name, like > "test_export". Afterwards, check that it's correct in the "Export > location" field of the applet (another screenshot). > > Otherwise, I think ilastik is perfectly suited for your task, but > unfortunately there are still bugs standing in your way. > > Sorry for the inconvenience > Anna > > > > > On 09.04.2014 09:36, James Burchfield wrote: >> Hi Anna, >> Thanks for the info. I am struggling a little. >> With version 0.5xxxx, i generated a classifier and batch >> processed. Got the *.h5 files, but cannot seem to do anything >> with them. Tried an .H5 viewer. I can reopen them in Ilastik >> and the data seems to be there. I found an imageJ plugin for >> openiing HD5 images but his didn't work either. >> With the new version, I attempted to import the old project file, >> but this failed. >> I generated a new project and classifier, but have got stuck >> trying to batch process. I get the error >> Inline image 1 >> Essentially what I am attempting to do is identify objects in a >> section of tissue, count them and calculate the area. >> Any help and or suggestions would be much appreciated. >> >> Cheers, >> James >> >> __ >> *Dr James Burchfield* >> The Garvan Institute of Medical Research >> 384 Victoria Street >> Darlinghurst, NSW, 2010 >> Australia >> >> Email: j.burchfield at garvan.org.au >> Phone:+61 2 92958229 >> Web:_www.garvan.org.au _ >> >> >> On Tue, Apr 8, 2014 at 7:58 PM, Anna Kreshuk >> > > wrote: >> >> This version has been specifically developed for large >> datasets! You can now explore and label in different parts of >> the image and only the current field of view will be >> computed. Of course, you can then process the whole image >> blockwise in batch mode. The one thing not to do is zoom out >> fully and try to predict the whole image in "live update" >> mode. This will actually try to compute the whole image, like >> the 0.5 version. Otherwise, I think the new version should be >> much better suited to your needs. >> >> Let me know if something does not work as expected or if you >> want some pointers about the new version. >> Anna >> >> >> On 08.04.2014 10:24, James Burchfield wrote: >>> Thanks Anna, >>> I will have a play. >>> Is this version better at handling large datasets? >>> We often deal with large mosaic images (~250MB) and I find >>> that version 0.5x tends to struggle. >>> Having said that, the power of this software is awesome. >>> Cheers, >>> James >>> >>> __ >>> *Dr James Burchfield* >>> The Garvan Institute of Medical Research >>> 384 Victoria Street >>> Darlinghurst, NSW, 2010 >>> Australia >>> >>> Email: j.burchfield at garvan.org.au >>> >>> Phone:+61 2 92958229 >>> Web:_www.garvan.org.au _ >>> >>> >>> On Tue, Apr 8, 2014 at 4:36 PM, Anna Kreshuk >>> >> > wrote: >>> >>> Hi James, >>> >>> Thanks for your interest! You can find the binaries for >>> all platforms here: http://ilastik.github.io/download. >>> There are also test datasets on the same page and the >>> documentation is at >>> http://ilastik.github.io/documentation/index.html. >>> >>> We'd appreciate your feedback for this version, so don't >>> hesitate to contact us in case of any problems with the >>> installation or anything else, >>> Anna >>> >>> >>> On 08.04.2014 02:11, James Burchfield wrote: >>>> Hi there, >>>> I would be interested in testing the beta version of >>>> Ilastik 1.0 >>>> Cheers, >>>> James >>>> __ >>>> *Dr James Burchfield* >>>> The Garvan Institute of Medical Research >>>> 384 Victoria Street >>>> Darlinghurst, NSW, 2010 >>>> Australia >>>> >>>> Email: j.burchfield at garvan.org.au >>>> >>>> Phone:+61 2 92958229 >>>> Web:_www.garvan.org.au _ >>>> >>>> >>>> >>>> _______________________________________________ >>>> team mailing list >>>> team at ilastik.org >>>> http://mailman.ilastik.org/cgi-bin/mailman/listinfo/team >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 17883 bytes Desc: not available URL: From anna.kreshuk at iwr.uni-heidelberg.de Wed Apr 9 15:31:08 2014 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Wed, 09 Apr 2014 15:31:08 +0200 Subject: [ilastik-devel] Ilastik question In-Reply-To: References: <53440422.4090509@iwr.uni-heidelberg.de> Message-ID: <53454B9C.4030404@iwr.uni-heidelberg.de> Hi Carlos, We just had a skype meeting of the core developers and discussed the question of context features. There is nothing that seems infeasible with the plan now (to re-iterate for others, we are talking about the "monolith" plan, where features and classifier are tied in the same object, which gets raw data and some integral volume features from ilastik and outputs predictions). However, there are some points to consider: - Suppose you get some labels and train your classifier. Do you then keep the feature selections fixed or would you re-draw if you have to re-train, because user made more labels? Does it make sense to cache the already computed random features for the previously labeled points? - How do you serialize the classifier? We have to have serialization, so that we could save it into an ilastik project. However, the exact way it's serialized is not so important, we'll just copy it into the hdf5 file. The other plan with separation of feature computation and classification also seems very feasible and would make the caching from the first point above fairly simple. Serialization is needed in either case. Let us know what you think and how we can help you to proceed, Anna On 08.04.2014 16:34, Carlos Becker wrote: > Thanks Anna for all the info. I will keep you posted. > > Regarding the plan we talked about last Friday, let me know whenever > you have news about the feasibility/or if you and the people at > Heidelberg think there is anything to change. > > Cheers. > > > ------------------------------------------ > Carlos > > > On Tue, Apr 8, 2014 at 4:13 PM, Anna Kreshuk > > wrote: > > Hi again, > > I was just discussing your stuff with our Janelia developer and he > thinks you might find this unit test useful: > lazyflow/tests/testOpTrainRandomForestFromFeatures.py. > > Cheers, > Anna > > On 08.04.2014 09:42, Carlos Becker wrote: >> Hi Anna, >> >> hope you got there fine and had a great weekend. We had great >> weather over here, I hope you did as well there. >> >> I wanted to ask you about adding a classifier to Ilastik. I think >> it would be worth trying what Boosted Trees do, because in some >> cases they could lead to faster training/prediction times, >> important for interactivity. So, with regards to that, can you >> give me a hint about where to look in the Ilastik source code to >> get started? >> >> Thanks! >> >> ------------------------------------------ >> Carlos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anna.kreshuk at iwr.uni-heidelberg.de Thu Apr 10 11:32:59 2014 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Thu, 10 Apr 2014 11:32:59 +0200 Subject: [ilastik-devel] Fwd: Re: Ilastik question In-Reply-To: References: Message-ID: <5346654B.8060905@iwr.uni-heidelberg.de> Hi all, Looks like a good plan to me. -------- Original Message -------- Subject: Re: Ilastik question Date: Thu, 10 Apr 2014 10:33:31 +0200 From: Carlos Becker To: Anna Kreshuk , Pol Mons? Purt? Hi Anna, that sounds great! I reply to you because I suppose I don't have rights to send to ilastik-devel. I am adding Pol as well in CC. I answer below: - Suppose you get some labels and train your classifier. Do you then keep the feature selections fixed or would you re-draw if you have to re-train, because user made more labels? Does it make sense to cache the already computed random features for the previously labeled points? Feature selection happens 'automatically' because of the way boosting works. So it would be better to re-train from scratch when adding new ground truth, even though online-learning algorithms could be devised. We could cache the selected features, but maybe it is better to start with a simpler implementation that does not. What we do need are the integral images to be cached, that would surely save time once they are computed. This would be on the ilastik side though, as we discussed previously. - How do you serialize the classifier? We have to have serialization, so that we could save it into an ilastik project. However, the exact way it's serialized is not so important, we'll just copy it into the hdf5 file. Now we use libconfig to save the trained model, but we can adapt it to almost anything else, I guess HDF5 is more than enough for what we need to store. The other plan with separation of feature computation and classification also seems very feasible and would make the caching from the first point above fairly simple. Serialization is needed in either case. What I am afraid of in the case of separating them is training/prediction speed, because requesting a feature would need to have python in between, which may be very detrimental in terms of speed. I would first prefer to stick to ilastik creating the integral images. Let us know what you think and how we can help you to proceed, We could start with the following; * *Pol and me:* clean up the boosting code to take different sub-volumes as input (each one corresponding to a ROI in ilastik). Each subvolume would have the integral images pre-computed by ilastik and ground truth. We then generate a python wrapper so that we can do something like boostedModel.train( roiList, parameters ), where roiList is a python list or dictionary with the necessary data. This would be called from Ilastik. * In the mean time, can you take a look at how to prepare Ilastik to be able to call code like the one in the line above? For prediction, we would have something like boostedModel.predict( roiList ) Let me know what you think, Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From anna.kreshuk at iwr.uni-heidelberg.de Thu Apr 10 14:55:09 2014 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Thu, 10 Apr 2014 14:55:09 +0200 Subject: [ilastik-devel] Ilastik question In-Reply-To: References: <53440422.4090509@iwr.uni-heidelberg.de> <53454B9C.4030404@iwr.uni-heidelberg.de> Message-ID: <534694AD.30602@iwr.uni-heidelberg.de> Hi Carlos, You should be able to write to ilastik-devel now. Concerning the order: integral volumes will be computed in vigra, where you can define the order of MultiArrays. I'm not sure we can exploit it directly from ilastik, but there should be some way. I think, once you clean up the code to contain only the stuff that is currently used, we should go through it together and look at the ITK dependencies more closely. If we could do a drop-in replacement with vigra functions, the life of people who have to build the ilastik binaries will become much easier. Cheers, Anna On 10.04.2014 11:59, Carlos Becker wrote: > I forgot about something important: *storage order*! > > We are storing 3D matrices/volumes ITK-like, which is generally the > opposite to what numpy does. > Would it be possible to keep the integral images in ilastik (python) > in column-major order? We probably can't afford converting from row- > to column-major everytime training is needed. > > cheers. > > > ------------------------------------------ > Carlos > > > On Thu, Apr 10, 2014 at 10:33 AM, Carlos Becker > > wrote: > > Hi Anna, that sounds great! > I reply to you because I suppose I don't have rights to send to > ilastik-devel. I am adding Pol as well in CC. > > I answer below: > > > - Suppose you get some labels and train your classifier. Do > you then keep the feature selections fixed or would you > re-draw if you have to re-train, because user made more > labels? Does it make sense to cache the already computed > random features for the previously labeled points? > > > Feature selection happens 'automatically' because of the way > boosting works. So it would be better to re-train from scratch > when adding new ground truth, even though online-learning > algorithms could be devised. > We could cache the selected features, but maybe it is better to > start with a simpler implementation that does not. > What we do need are the integral images to be cached, that would > surely save time once they are computed. This would be on the > ilastik side though, as we discussed previously. > > - How do you serialize the classifier? We have to have > serialization, so that we could save it into an ilastik > project. However, the exact way it's serialized is not so > important, we'll just copy it into the hdf5 file. > > > Now we use libconfig to save the trained model, but we can adapt > it to almost anything else, I guess HDF5 is more than enough for > what we need to store. > > The other plan with separation of feature computation and > classification also seems very feasible and would make the > caching from the first point above fairly simple. > Serialization is needed in either case. > > > What I am afraid of in the case of separating them is > training/prediction speed, because requesting a feature would need > to have python in between, which may be very detrimental in terms > of speed. > I would first prefer to stick to ilastik creating the integral images. > > Let us know what you think and how we can help you to proceed, > > > We could start with the following; > > * *Pol and me:* clean up the boosting code to take different > sub-volumes as input (each one corresponding to a ROI in > ilastik). Each subvolume would have the integral images > pre-computed by ilastik and ground truth. We then generate a > python wrapper so that we can do something like > boostedModel.train( roiList, parameters ), where roiList is a > python list or dictionary with the necessary data. This would > be called from Ilastik. > * In the mean time, can you take a look at how to prepare > Ilastik to be able to call code like the one in the line > above? For prediction, we would have something like > boostedModel.predict( roiList ) > > > Let me know what you think, > Carlos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlosbecker at gmail.com Tue Apr 15 21:46:10 2014 From: carlosbecker at gmail.com (Carlos Becker) Date: Tue, 15 Apr 2014 21:46:10 +0200 Subject: [ilastik-devel] Ilastik question In-Reply-To: <534694AD.30602@iwr.uni-heidelberg.de> References: <53440422.4090509@iwr.uni-heidelberg.de> <53454B9C.4030404@iwr.uni-heidelberg.de> <534694AD.30602@iwr.uni-heidelberg.de> Message-ID: Hello all, Refactoring is almost done. My code now accepts a set of ROIs as input. I will make it available soon online. Initially we can try feeding it with ROIs containing the raw image + ground truth (where ground truth is a volume where pix = 1 means negative class, pix = 2 positive). Would it be easy to modify Ilastik to make such call with the ROIs annotated by the user? We can ignore the integral images at this step (I can compute this inside the code). The model would be then returned as a python data structure, and used later to run the prediction on different ROIs. Cheers. ------------------------------------------ Carlos On Thu, Apr 10, 2014 at 2:55 PM, Anna Kreshuk < anna.kreshuk at iwr.uni-heidelberg.de> wrote: > Hi Carlos, > > You should be able to write to ilastik-devel now. > > Concerning the order: integral volumes will be computed in vigra, where > you can define the order of MultiArrays. I'm not sure we can exploit it > directly from ilastik, but there should be some way. I think, once you > clean up the code to contain only the stuff that is currently used, we > should go through it together and look at the ITK dependencies more > closely. If we could do a drop-in replacement with vigra functions, the > life of people who have to build the ilastik binaries will become much > easier. > > Cheers, > Anna > > > On 10.04.2014 11:59, Carlos Becker wrote: > > I forgot about something important: *storage order*! > > We are storing 3D matrices/volumes ITK-like, which is generally the > opposite to what numpy does. > Would it be possible to keep the integral images in ilastik (python) in > column-major order? We probably can't afford converting from row- to > column-major everytime training is needed. > > cheers. > > > ------------------------------------------ > Carlos > > > On Thu, Apr 10, 2014 at 10:33 AM, Carlos Becker wrote: > >> Hi Anna, that sounds great! >> I reply to you because I suppose I don't have rights to send to >> ilastik-devel. I am adding Pol as well in CC. >> >> I answer below: >> >> >> - Suppose you get some labels and train your classifier. Do you then >>> keep the feature selections fixed or would you re-draw if you have to >>> re-train, because user made more labels? Does it make sense to cache the >>> already computed random features for the previously labeled points? >>> >> >> Feature selection happens 'automatically' because of the way boosting >> works. So it would be better to re-train from scratch when adding new >> ground truth, even though online-learning algorithms could be devised. >> We could cache the selected features, but maybe it is better to start >> with a simpler implementation that does not. >> What we do need are the integral images to be cached, that would surely >> save time once they are computed. This would be on the ilastik side though, >> as we discussed previously. >> >> >> >>> - How do you serialize the classifier? We have to have serialization, >>> so that we could save it into an ilastik project. However, the exact way >>> it's serialized is not so important, we'll just copy it into the hdf5 file. >>> >> >> Now we use libconfig to save the trained model, but we can adapt it to >> almost anything else, I guess HDF5 is more than enough for what we need to >> store. >> >> >> >>> The other plan with separation of feature computation and >>> classification also seems very feasible and would make the caching from the >>> first point above fairly simple. Serialization is needed in either case. >>> >> >> What I am afraid of in the case of separating them is >> training/prediction speed, because requesting a feature would need to have >> python in between, which may be very detrimental in terms of speed. >> I would first prefer to stick to ilastik creating the integral images. >> >> >> >>> Let us know what you think and how we can help you to proceed, >>> >> >> We could start with the following; >> >> - *Pol and me:* clean up the boosting code to take different >> sub-volumes as input (each one corresponding to a ROI in ilastik). Each >> subvolume would have the integral images pre-computed by ilastik and ground >> truth. We then generate a python wrapper so that we can do something like boostedModel.train( >> roiList, parameters ), where roiList is a python list or dictionary >> with the necessary data. This would be called from Ilastik. >> - In the mean time, can you take a look at how to prepare Ilastik to >> be able to call code like the one in the line above? For prediction, we >> would have something like boostedModel.predict( roiList ) >> >> >> Let me know what you think, >> Carlos >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anna.kreshuk at iwr.uni-heidelberg.de Tue Apr 22 16:25:04 2014 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Tue, 22 Apr 2014 16:25:04 +0200 Subject: [ilastik-devel] Ilastik question In-Reply-To: References: <53440422.4090509@iwr.uni-heidelberg.de> <53454B9C.4030404@iwr.uni-heidelberg.de> <534694AD.30602@iwr.uni-heidelberg.de> Message-ID: <53567BC0.6050302@iwr.uni-heidelberg.de> Hi Carlos, For the ground truth, can you take sparsely labeled ROIs? Say, a rectangle bounding box, where some lines are labeled? Do you have a github or other repo with the code? Maybe you could share a private branch with some of us? I think it would make looking at the code easier. Otherwise, it looks like you are well on the way and if the code can handle sparse annotations, we could start combining it with ilastik. Cheers, Anna On 15.04.2014 21:46, Carlos Becker wrote: > Hello all, > > Refactoring is almost done. My code now accepts a set of ROIs as input. > I will make it available soon online. > > Initially we can try feeding it with ROIs containing the raw image + > ground truth (where ground truth is a volume where pix = 1 means > negative class, pix = 2 positive). > Would it be easy to modify Ilastik to make such call with the ROIs > annotated by the user? We can ignore the integral images at this step > (I can compute this inside the code). > > The model would be then returned as a python data structure, and used > later to run the prediction on different ROIs. > > Cheers. > > > ------------------------------------------ > Carlos > > > On Thu, Apr 10, 2014 at 2:55 PM, Anna Kreshuk > > wrote: > > Hi Carlos, > > You should be able to write to ilastik-devel now. > > Concerning the order: integral volumes will be computed in vigra, > where you can define the order of MultiArrays. I'm not sure we can > exploit it directly from ilastik, but there should be some way. I > think, once you clean up the code to contain only the stuff that > is currently used, we should go through it together and look at > the ITK dependencies more closely. If we could do a drop-in > replacement with vigra functions, the life of people who have to > build the ilastik binaries will become much easier. > > Cheers, > Anna > > > On 10.04.2014 11:59, Carlos Becker wrote: >> I forgot about something important: *storage order*! >> >> We are storing 3D matrices/volumes ITK-like, which is generally >> the opposite to what numpy does. >> Would it be possible to keep the integral images in ilastik >> (python) in column-major order? We probably can't afford >> converting from row- to column-major everytime training is needed. >> >> cheers. >> >> >> ------------------------------------------ >> Carlos >> >> >> On Thu, Apr 10, 2014 at 10:33 AM, Carlos Becker >> > wrote: >> >> Hi Anna, that sounds great! >> I reply to you because I suppose I don't have rights to send >> to ilastik-devel. I am adding Pol as well in CC. >> >> I answer below: >> >> >> - Suppose you get some labels and train your classifier. >> Do you then keep the feature selections fixed or would >> you re-draw if you have to re-train, because user made >> more labels? Does it make sense to cache the already >> computed random features for the previously labeled points? >> >> >> Feature selection happens 'automatically' because of the way >> boosting works. So it would be better to re-train from >> scratch when adding new ground truth, even though >> online-learning algorithms could be devised. >> We could cache the selected features, but maybe it is better >> to start with a simpler implementation that does not. >> What we do need are the integral images to be cached, that >> would surely save time once they are computed. This would be >> on the ilastik side though, as we discussed previously. >> >> - How do you serialize the classifier? We have to have >> serialization, so that we could save it into an ilastik >> project. However, the exact way it's serialized is not so >> important, we'll just copy it into the hdf5 file. >> >> >> Now we use libconfig to save the trained model, but we can >> adapt it to almost anything else, I guess HDF5 is more than >> enough for what we need to store. >> >> The other plan with separation of feature computation and >> classification also seems very feasible and would make >> the caching from the first point above fairly simple. >> Serialization is needed in either case. >> >> >> What I am afraid of in the case of separating them is >> training/prediction speed, because requesting a feature would >> need to have python in between, which may be very detrimental >> in terms of speed. >> I would first prefer to stick to ilastik creating the >> integral images. >> >> Let us know what you think and how we can help you to >> proceed, >> >> >> We could start with the following; >> >> * *Pol and me:* clean up the boosting code to take >> different sub-volumes as input (each one corresponding to >> a ROI in ilastik). Each subvolume would have the integral >> images pre-computed by ilastik and ground truth. We then >> generate a python wrapper so that we can do something >> like boostedModel.train( roiList, parameters ), where >> roiList is a python list or dictionary with the necessary >> data. This would be called from Ilastik. >> * In the mean time, can you take a look at how to prepare >> Ilastik to be able to call code like the one in the line >> above? For prediction, we would have something like >> boostedModel.predict( roiList ) >> >> >> Let me know what you think, >> Carlos >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlosbecker at gmail.com Tue Apr 22 16:32:19 2014 From: carlosbecker at gmail.com (Carlos Becker) Date: Tue, 22 Apr 2014 16:32:19 +0200 Subject: [ilastik-devel] Ilastik question In-Reply-To: <53567BC0.6050302@iwr.uni-heidelberg.de> References: <53440422.4090509@iwr.uni-heidelberg.de> <53454B9C.4030404@iwr.uni-heidelberg.de> <534694AD.30602@iwr.uni-heidelberg.de> <53567BC0.6050302@iwr.uni-heidelberg.de> Message-ID: Hi Anna, On Tue, Apr 22, 2014 at 4:25 PM, Anna Kreshuk < anna.kreshuk at iwr.uni-heidelberg.de> wrote: > Hi Carlos, > > For the ground truth, can you take sparsely labeled ROIs? Say, a rectangle > bounding box, where some lines are labeled? > Yes, exactly. The idea is that the rectangle/cube is passed through a pointer to its raw image data and a pointer to the label data. How are labels used in Ilastik? would it be the case that there would be a label volume, with value 0 if it is not labeled, 1 for class 1, 2 for class 2, etc? Do you have a github or other repo with the code? Maybe you could share a > private branch with some of us? I think it would make looking at the code > easier. > Yes sure, I have to work on the python part and then I will put it online. Cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anna.kreshuk at iwr.uni-heidelberg.de Tue Apr 22 16:33:40 2014 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Tue, 22 Apr 2014 16:33:40 +0200 Subject: [ilastik-devel] Ilastik question In-Reply-To: References: <53440422.4090509@iwr.uni-heidelberg.de> <53454B9C.4030404@iwr.uni-heidelberg.de> <534694AD.30602@iwr.uni-heidelberg.de> <53567BC0.6050302@iwr.uni-heidelberg.de> Message-ID: <53567DC4.4060508@iwr.uni-heidelberg.de> Hi there, > How are labels used in Ilastik? would it be the case that there would be a label volume, with value 0 if it is not labeled, 1 for class 1, 2 for class 2, etc? Exactly like this, yes. >>Do you have a github or other repo with the code? Maybe you could share a private branch with some of us? I think it would make looking at the code easier. > Yes sure, I have to work on the python part and then I will put it online. Looking forward! Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlosbecker at gmail.com Thu Apr 24 11:16:01 2014 From: carlosbecker at gmail.com (Carlos Becker) Date: Thu, 24 Apr 2014 11:16:01 +0200 Subject: [ilastik-devel] Ilastik question In-Reply-To: <53567DC4.4060508@iwr.uni-heidelberg.de> References: <53440422.4090509@iwr.uni-heidelberg.de> <53454B9C.4030404@iwr.uni-heidelberg.de> <534694AD.30602@iwr.uni-heidelberg.de> <53567BC0.6050302@iwr.uni-heidelberg.de> <53567DC4.4060508@iwr.uni-heidelberg.de> Message-ID: Hello, I've just put online the new version https://github.com/cbecker/iiboost Currently, the python wrapper works like this: ----------- import IIBoost model = Booster() # Train: note that we pass a list of stacks, img and gt # both are uint8 nparrays model.train( [img], [gt], numStumps=200, debugOutput=True) # to predict predStack = model.predict( img ) ----------- internally it creates an integral image of `img` and trains the classifier.\ It also computes the orientation image on its own. The trick now is calling that function from ilastik, how shall we proceed? Cheers. ------------------------------------------ Carlos On Tue, Apr 22, 2014 at 4:33 PM, Anna Kreshuk < anna.kreshuk at iwr.uni-heidelberg.de> wrote: > Hi there, > > > How are labels used in Ilastik? would it be the case that there would be > a label volume, with value 0 if it is not labeled, 1 for class 1, 2 for > class 2, etc? > > Exactly like this, yes. > > > >>Do you have a github or other repo with the code? Maybe you could >> share a private branch with some of us? I think it would make looking at >> the code easier. >> > > > Yes sure, I have to work on the python part and then I will put it > online. > > > Looking forward! > Anna > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anna.kreshuk at iwr.uni-heidelberg.de Fri Apr 25 17:58:45 2014 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Fri, 25 Apr 2014 17:58:45 +0200 Subject: [ilastik-devel] Ilastik question In-Reply-To: References: <53440422.4090509@iwr.uni-heidelberg.de> <53454B9C.4030404@iwr.uni-heidelberg.de> <534694AD.30602@iwr.uni-heidelberg.de> <53567BC0.6050302@iwr.uni-heidelberg.de> <53567DC4.4060508@iwr.uni-heidelberg.de> Message-ID: <535A8635.8090309@iwr.uni-heidelberg.de> Hi Carlos, Sorry for not getting back to you, I want to take a more detailed look at the code and I really hope to do that early next week. Let's discuss the next steps to take afterwards. Have a good weekend, Anna On 24.04.2014 11:16, Carlos Becker wrote: > Hello, > > I've just put online the new version https://github.com/cbecker/iiboost > > Currently, the python wrapper works like this: > > ----------- > import IIBoost > model = Booster() > > # Train: note that we pass a list of stacks, img and gt > # both are uint8 nparrays > model.train( [img], [gt], numStumps=200, debugOutput=True) > > # to predict > predStack = model.predict( img ) > ----------- > > internally it creates an integral image of `img` and trains the > classifier.\ > It also computes the orientation image on its own. > > The trick now is calling that function from ilastik, how shall we proceed? > > > Cheers. > > > > ------------------------------------------ > Carlos > > > On Tue, Apr 22, 2014 at 4:33 PM, Anna Kreshuk > > wrote: > > Hi there, > > > How are labels used in Ilastik? would it be the case that there > would be a label volume, with value 0 if it is not labeled, 1 for > class 1, 2 for class 2, etc? > > Exactly like this, yes. > > >>Do you have a github or other repo with the code? Maybe you > could share a private branch with some of us? I think it would > make looking at the code easier. > > > > Yes sure, I have to work on the python part and then I will put > it online. > > Looking forward! > Anna > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From glendon.holst at kaust.edu.sa Thu Dec 4 11:38:50 2014 From: glendon.holst at kaust.edu.sa (Glendon Holst) Date: Thu, 4 Dec 2014 13:38:50 +0300 Subject: [ilastik-devel] Advice for label import functionality Message-ID: <548039BA.5030500@kaust.edu.sa> Howdy! I'm investigating adding Import functionality for Labels to ilastik, and I wanted to get some general guidance on the best way (and where) to insert temporary sources into the lazyflow chain, and what sort of image-to-label-seeds support already exists. With Export Segmentation and Import Labals, it will be possible to incorporate other tools (such as TrakEM2) into our workflow, and lock down segmented areas we are satisfied with (by incorporating manually tweaked segmentation back into the seeds). I found a place in volumina/widgets/layercontextmenu.py :: layercontextmenu to create the Export... menu item, and am looking at get_settings_and_export_layer for inspiration for use on an input layer. I have a general sense of lazyflow (have read the documentation). I also have a manual proof-of-concept for taking an image stack from TrakEM2 (Fiji), processing it in ImageMagick to create the enumerated list of colors, then importing that directly into the *.ilp HD5 file. 1) Where is the fg_voxels data relative to the layer? The layer binding the menu is ColortableLayer, but I'm not sure if that is the node we want or where the voxels are (data._inputSlot? datasources.dataSlot?)? I see it (I think) referenced via opCarving.WriteSeeds in carvingSerializer.py. Do I need to go back up from the ColortableLayer, up to the node for opCarving and modify it there like _deserializerFromHdf5 does? 2) Are there any image processing utilities in ilastik that could convert from a tiff image into color enumeration-list (like ImageMagick's 'convert ... txt:-' utility)? Any advice is appreciated. Glendon PS. Thanks again for making ilastik available. ________________________________ This message and its contents including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anna.kreshuk at iwr.uni-heidelberg.de Mon Dec 8 15:52:49 2014 From: anna.kreshuk at iwr.uni-heidelberg.de (Anna Kreshuk) Date: Mon, 08 Dec 2014 15:52:49 +0100 Subject: [ilastik-devel] Advice for label import functionality In-Reply-To: <548039BA.5030500@kaust.edu.sa> References: <548039BA.5030500@kaust.edu.sa> Message-ID: <5485BB41.5000109@iwr.uni-heidelberg.de> Hi Glendon, Do you want to use the manually segmented areas as seeds or to have them fixed in the final segmentation result? 1) You are on the right track with the WriteSeeds. As you can see, it's connected to labelingSlots.labelInput. This is the one you need to set to the values you import. In general, take a look at the labeling applet in ilastik/applets/labeling, all the label operations are handled through it. If you can import labels there, carving should be the same. I hope other devs can comment on this point in more detail. 2) No, we don't have that yet, but it's necessary to be able to import labels, whether in carving or in any other workflow. I can think of some quick way to do it in numpy, with unique() or something related, but you probably have one already. Keep us posted on your experience, we'd be happy to help more. Anna On 04.12.2014 11:38, Glendon Holst wrote: > Howdy! > > I'm investigating adding Import functionality for Labels to ilastik, > and I wanted to get some general guidance on the best way (and where) > to insert temporary sources into the lazyflow chain, and what sort of > image-to-label-seeds support already exists. > > With Export Segmentation and Import Labals, it will be possible to > incorporate other tools (such as TrakEM2) into our workflow, and lock > down segmented areas we are satisfied with (by incorporating manually > tweaked segmentation back into the seeds). > > I found a place in volumina/widgets/layercontextmenu.py :: > layercontextmenu to create the Export... menu item, and am looking at > get_settings_and_export_layer for inspiration for use on an input > layer. I have a general sense of lazyflow (have read the > documentation). I also have a manual proof-of-concept for taking an > image stack from TrakEM2 (Fiji), processing it in ImageMagick to > create the enumerated list of colors, then importing that directly > into the *.ilp HD5 file. > > 1) Where is the fg_voxels data relative to the layer? The layer > binding the menu is ColortableLayer, but I'm not sure if that is the > node we want or where the voxels are (data._inputSlot? > datasources.dataSlot?)? I see it (I think) referenced via > opCarving.WriteSeeds in carvingSerializer.py. Do I need to go back up > from the ColortableLayer, up to the node for opCarving and modify it > there like _deserializerFromHdf5 does? > > 2) Are there any image processing utilities in ilastik that could > convert from a tiff image into color enumeration-list (like > ImageMagick's 'convert ... txt:-' utility)? > > Any advice is appreciated. > > Glendon > > PS. Thanks again for making ilastik available. > > ------------------------------------------------------------------------ > > This message and its contents including attachments are intended > solely for the original recipient. If you are not the intended > recipient or have received this message in error, please notify me > immediately and delete this message from your computer system. Any > unauthorized use or distribution is prohibited. Please consider the > environment before printing this email. > > > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From burcin at erocal.org Tue Feb 11 11:34:25 2014 From: burcin at erocal.org (Burcin Erocal) Date: Tue, 11 Feb 2014 11:34:25 +0100 Subject: [ilastik-devel] GSoC mentoring org - machine learning, python, etc. In-Reply-To: References: <20140130115516.31b3cf71@carl.erocal.org> Message-ID: <20140211113425.2a3514ad@carl.erocal.org> Hi Nilesh, sorry for the really late response. I was on vacation for a week and GSoC related messages are inflating my inbox a lot more than usual... I'm copying this message to the ilastik-devel at ilastik.org mailing list where others can answer your questions about project ideas. Perhaps you should send a short self introduction to the list explaining your interests. Cheers, Burcin On Fri, 31 Jan 2014 23:12:30 +0530 Nilesh Chakraborty wrote: > Hi Burcin, > > Thanks for your email! :) ilastik looks interesting. I couldn't really > understand what the "Proof-reading of the results" was about - does it > involve learning using some model and/or predicting something? The > language isn't too clear. > > More algorithmic stuff, implementing algorithms in Python etc. would > be more to my tastes, so I think I'll be very interested in what > projects can be worked on related to lazyflow. Can you please let me > know what kind of ideas you're going to suggest about lazyflow? > > Cheers, > Nilesh > > On 1/30/14, Burcin Erocal wrote: > > Hi Nilesh, > > > > I saw your post on the GSoC-discuss list digest. :) > > > > We are developing a machine learning / image processing software > > suite aimed at biologists: > > > > http://ilastik.github.io/index10.html > > > > We will be suggesting some projects for GSoC this year, either under > > the PSF umbrella, or as another organization: > > > > https://github.com/ilastik/ilastik/wiki/GSoC-Project-Ideas > > > > If you're interested in more algorithmic stuff, or infrastructure > > work, we can also put a couple of projects related to lazyflow: > > > > https://github.com/ilastik/lazyflow > > > > > > Feel free to contact the group at ilastik-devel at ilastik.org: > > > > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > > > > > > Cheers, > > Burcin > > > > From evelzw at gmail.com Fri Jan 3 06:12:23 2014 From: evelzw at gmail.com (Zhaowen Liu) Date: Fri, 3 Jan 2014 00:12:23 -0500 Subject: [ilastik-devel] Advice on identifying different particle shapes Message-ID: Hi everyone, I have batches of SEM images of gold nano particles. Particles are formed in different shapes, singlets, dimers, trimers and big clusters etc. I would like to identify them with Ilsatik. The dark part of the image is background and bright objects are nano particles. I tried Classification in Ilastic with 5 color labels, red for background, green for singlets, yellow for dimers, blue for trimers and magenta for big clusters. But according to the Segmentation result, they can not be separated form each other no matter how many labels i added. So i am wondering if it is possible to classify different object types of similar color with Ilastik. Or if it is not, do you have any suggestion for some other methods to identify singlets, dimers and clusters etc? To illustrate what different shapes look like, I attached the original SEM image, the diagram of shapes and the Segmentation output from Ilastik as follows. Thanks a lot for your time and for making such a nice tool! Best, Evelyn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: particle_types.tiff Type: image/tiff Size: 732862 bytes Desc: not available URL: From Elizabeth.Jurrus at pnnl.gov Sat Jan 4 00:12:00 2014 From: Elizabeth.Jurrus at pnnl.gov (Jurrus, Elizabeth R) Date: Fri, 3 Jan 2014 23:12:00 +0000 Subject: [ilastik-devel] what stable version should I use? Message-ID: <5B40CED398A3F446BC621BF2A52CB8ED0B047814@EX10MBOX06.pnnl.gov> Hi there, We've generated some really nice results for image classification using ilastik with the .5 release. I'd like to upgrade to the gifthub 1.0 version but am having trouble building lazyflow on linux. Is there a release available or should I continue to use the .5 version? Also, we'd like to incorporate the classifier methods from ilastik into another tool. Do you have some test code that isolates the classification that we could look at to do this? Thanks in advance! - liz -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred.hamprecht at iwr.uni-heidelberg.de Tue Jan 7 14:53:38 2014 From: fred.hamprecht at iwr.uni-heidelberg.de (Fred Hamprecht) Date: Tue, 07 Jan 2014 14:53:38 +0100 Subject: [ilastik-devel] Advice on identifying different particle shapes In-Reply-To: References: Message-ID: <52CC06E2.4090203@iwr.uni-heidelberg.de> Hello Evelyn, at least in my mail client (thunderbird) I could not see the image you mentioned. Could you please send it again as an attachment? Thanks and regards, Fred On 03.01.2014 06:12, Zhaowen Liu wrote: > Hi everyone, > > I have batches of SEM images of gold nano particles. Particles are > formed in different shapes, singlets, dimers, trimers and big clusters > etc. I would like to identify them with Ilsatik. The dark part of the > image is background and bright objects are nano particles. I tried > Classification in Ilastic with 5 color labels, red for background, green > for singlets, yellow for dimers, blue for trimers and magenta for big > clusters. But according to the Segmentation result, they can not be > separated form each other no matter how many labels i added. > > So i am wondering if it is possible to classify different object types > of similar color with Ilastik. Or if it is not, do you have any > suggestion for some other methods to identify singlets, dimers and > clusters etc? > > To illustrate what different shapes look like, I attached the original > SEM image, the diagram of shapes and the Segmentation output from > Ilastik as follows. > > Thanks a lot for your time and for making such a nice tool! > > Best, > Evelyn > > > > > _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From fred.hamprecht at iwr.uni-heidelberg.de Tue Jan 7 18:01:01 2014 From: fred.hamprecht at iwr.uni-heidelberg.de (Fred Hamprecht) Date: Tue, 07 Jan 2014 18:01:01 +0100 Subject: [ilastik-devel] Advice on identifying different particle shapes In-Reply-To: <52CC06E2.4090203@iwr.uni-heidelberg.de> References: <52CC06E2.4090203@iwr.uni-heidelberg.de> Message-ID: <52CC32CD.5000507@iwr.uni-heidelberg.de> Hello Evelyn, a colleague _could_ open the image and resent it to me. Did Stuart Berg's advice work for you? Regards, Fred On 07.01.2014 14:53, Fred Hamprecht wrote: > > Hello Evelyn, > > at least in my mail client (thunderbird) I could not see the image you > mentioned. Could you please send it again as an attachment? > > Thanks and regards, > > Fred > > > > On 03.01.2014 06:12, Zhaowen Liu wrote: >> Hi everyone, >> >> I have batches of SEM images of gold nano particles. Particles are >> formed in different shapes, singlets, dimers, trimers and big clusters >> etc. I would like to identify them with Ilsatik. The dark part of the >> image is background and bright objects are nano particles. I tried >> Classification in Ilastic with 5 color labels, red for background, green >> for singlets, yellow for dimers, blue for trimers and magenta for big >> clusters. But according to the Segmentation result, they can not be >> separated form each other no matter how many labels i added. >> >> So i am wondering if it is possible to classify different object types >> of similar color with Ilastik. Or if it is not, do you have any >> suggestion for some other methods to identify singlets, dimers and >> clusters etc? >> >> To illustrate what different shapes look like, I attached the original >> SEM image, the diagram of shapes and the Segmentation output from >> Ilastik as follows. >> >> Thanks a lot for your time and for making such a nice tool! >> >> Best, >> Evelyn >> >> >> >> >> _______________________________________________ >> ilastik-devel mailing list >> ilastik-devel at ilastik.org >> http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel From hughesadam87 at gmail.com Tue Jan 7 18:57:46 2014 From: hughesadam87 at gmail.com (Adam Hughes) Date: Tue, 7 Jan 2014 12:57:46 -0500 Subject: [ilastik-devel] Advice on identifying different particle shapes In-Reply-To: <52CC32CD.5000507@iwr.uni-heidelberg.de> References: <52CC06E2.4090203@iwr.uni-heidelberg.de> <52CC32CD.5000507@iwr.uni-heidelberg.de> Message-ID: Hi Fred, Evelyn is away for the week, but she and I are colleagues on the same project. I had originally started using Ilastik with our images, but she has done most of the work and is more knowledgeable about the program than me. Thanks for getting back to us. The solution that Stuart suggested looked downright amazing. He had mentioned not to share the beta program/docs, and we will certainly respect his wishes. Is there any schedule timeline for its release? I ask because Evelyn and I are releasing a few papers, one of which directly is related to general image processing of nanoparticle images. We will cite Ilastik either way, but I'd really like to be able to mention the object classifier, as it seems to be the most discerning tool for our task of separating dimers/trimers/tetramers etc... even a small nod like "ilastik's object classifier looks to be highly adept for descriminating different particle families, and then show an image similar to what Stuart sent to us". Do you guys have any feelings on this? On Tue, Jan 7, 2014 at 12:01 PM, Fred Hamprecht < fred.hamprecht at iwr.uni-heidelberg.de> wrote: > > Hello Evelyn, > > a colleague _could_ open the image and resent it to me. > > Did Stuart Berg's advice work for you? > > Regards, > > Fred > > > > > > On 07.01.2014 14:53, Fred Hamprecht wrote: > >> >> Hello Evelyn, >> >> at least in my mail client (thunderbird) I could not see the image you >> mentioned. Could you please send it again as an attachment? >> >> Thanks and regards, >> >> Fred >> >> >> >> On 03.01.2014 06:12, Zhaowen Liu wrote: >> >>> Hi everyone, >>> >>> I have batches of SEM images of gold nano particles. Particles are >>> formed in different shapes, singlets, dimers, trimers and big clusters >>> etc. I would like to identify them with Ilsatik. The dark part of the >>> image is background and bright objects are nano particles. I tried >>> Classification in Ilastic with 5 color labels, red for background, green >>> for singlets, yellow for dimers, blue for trimers and magenta for big >>> clusters. But according to the Segmentation result, they can not be >>> separated form each other no matter how many labels i added. >>> >>> So i am wondering if it is possible to classify different object types >>> of similar color with Ilastik. Or if it is not, do you have any >>> suggestion for some other methods to identify singlets, dimers and >>> clusters etc? >>> >>> To illustrate what different shapes look like, I attached the original >>> SEM image, the diagram of shapes and the Segmentation output from >>> Ilastik as follows. >>> >>> Thanks a lot for your time and for making such a nice tool! >>> >>> Best, >>> Evelyn >>> >>> >>> >>> >>> _______________________________________________ >>> ilastik-devel mailing list >>> ilastik-devel at ilastik.org >>> http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel >>> >> _______________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/cgi-bin/mailman/listinfo/ilastik-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred.hamprecht at iwr.uni-heidelberg.de Thu Jan 9 17:47:33 2014 From: fred.hamprecht at iwr.uni-heidelberg.de (Fred Hamprecht) Date: Thu, 09 Jan 2014 17:47:33 +0100 Subject: [ilastik-devel] Advice on identifying different particle shapes In-Reply-To: References: <52CC06E2.4090203@iwr.uni-heidelberg.de> <52CC32CD.5000507@iwr.uni-heidelberg.de> Message-ID: <52CED2A5.4060207@iwr.uni-heidelberg.de> Hello Adam, thanks for the interesting news! I plan on finishing the manuscript describing the software at the end of next week. We want to submit to Nature Methods, so should have a fairly quick turnaround time and know by the end of February. If you want to submit before that, I am afraid you could only cite preliminary experiments or a personal communication, but not show the actual images. If on the other hand this timeline is compatible with your plans, you could of course show everything you like. Best regards, Fred On 07.01.2014 18:57, Adam Hughes wrote: > Hi Fred, > > Evelyn is away for the week, but she and I are colleagues on the same > project. I had originally started using Ilastik with our images, but > she has done most of the work and is more knowledgeable about the > program than me. > > Thanks for getting back to us. The solution that Stuart suggested > looked downright amazing. He had mentioned not to share the beta > program/docs, and we will certainly respect his wishes. Is there any > schedule timeline for its release? I ask because Evelyn and I are > releasing a few papers, one of which directly is related to general > image processing of nanoparticle images. We will cite Ilastik either > way, but I'd really like to be able to mention the object classifier, as > it seems to be the most discerning tool for our task of separating > dimers/trimers/tetramers etc... even a small nod like "ilastik's object > classifier looks to be highly adept for descriminating different > particle families, and then show an image similar to what Stuart sent to > us". Do you guys have any feelings on this? > > > On Tue, Jan 7, 2014 at 12:01 PM, Fred Hamprecht > > wrote: > > > Hello Evelyn, > > a colleague _could_ open the image and resent it to me. > > Did Stuart Berg's advice work for you? > > Regards, > > Fred > > > > > > On 07.01.2014 14:53, Fred Hamprecht wrote: > > > Hello Evelyn, > > at least in my mail client (thunderbird) I could not see the > image you > mentioned. Could you please send it again as an attachment? > > Thanks and regards, > > Fred > > > > On 03.01.2014 06:12, Zhaowen Liu wrote: > > Hi everyone, > > I have batches of SEM images of gold nano particles. > Particles are > formed in different shapes, singlets, dimers, trimers and > big clusters > etc. I would like to identify them with Ilsatik. The dark > part of the > image is background and bright objects are nano particles. I > tried > Classification in Ilastic with 5 color labels, red for > background, green > for singlets, yellow for dimers, blue for trimers and > magenta for big > clusters. But according to the Segmentation result, they can > not be > separated form each other no matter how many labels i added. > > So i am wondering if it is possible to classify different > object types > of similar color with Ilastik. Or if it is not, do you have any > suggestion for some other methods to identify singlets, > dimers and > clusters etc? > > To illustrate what different shapes look like, I attached > the original > SEM image, the diagram of shapes and the Segmentation output > from > Ilastik as follows. > > Thanks a lot for your time and for making such a nice tool! > > Best, > Evelyn > > > > > _________________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/__cgi-bin/mailman/listinfo/__ilastik-devel > > > _________________________________________________ > ilastik-devel mailing list > ilastik-devel at ilastik.org > http://mailman.ilastik.org/__cgi-bin/mailman/listinfo/__ilastik-devel > > From hughesadam87 at gmail.com Wed Jun 25 19:41:46 2014 From: hughesadam87 at gmail.com (Adam Hughes) Date: Wed, 25 Jun 2014 13:41:46 -0400 Subject: [ilastik-devel] Object identification with my own black and white image? Message-ID: Hello, I have been using object idenification in Ilastik v 1.0 and really love this tool. We are looking to compare some results from object groupings in Ilastik vs. some old predictions, and to be fair, I'd like to use the exact same binary image that we used back in the day. Is it possible to load an image and separately load a binarized image and immediately go into the object classificaiton workflow? As opposed to segmenting in Ilastik and then performing object classification? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From bergs at janelia.hhmi.org Wed Jun 25 19:58:18 2014 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 25 Jun 2014 17:58:18 +0000 Subject: [ilastik-devel] Object identification with my own black and white image? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From hughesadam87 at gmail.com Wed Jun 25 23:08:07 2014 From: hughesadam87 at gmail.com (Adam Hughes) Date: Wed, 25 Jun 2014 17:08:07 -0400 Subject: [ilastik-devel] Object identification with my own black and white image? In-Reply-To: References: Message-ID: Awesome, thanks! Sorry, I had still been looking at the documenation of ilastik's website, not the github docs. On Wed, Jun 25, 2014 at 1:58 PM, Berg, Stuart wrote: > Hi Adam, > > We're glad to hear ilastik is useful to you! > > Yes, there is a way to do exactly what you're looking for. The Object > Classification workflow comes in three varieties. When you first create a > project, choose "Object Classification (from binary image)" as the workflow > type. On the "Input Data" page, you will need to provide two files: "Raw > Data" and "Segmentation Image" (the binary image file). > > In case it's useful, this feature is briefly mentioned in the > documentation for the Object Classification workflow: > http://ilastik.github.io/documentation/objects/objects.html > > But of course, feel free to write back with any questions you have. > > Best, > Stuart > > From: Adam Hughes > Date: Wednesday, June 25, 2014 1:41 PM > To: "ilastik-devel at ilastik.org" > Subject: [ilastik-devel] Object identification with my own black and > white image? > > Hello, > > I have been using object idenification in Ilastik v 1.0 and really love > this tool. > > We are looking to compare some results from object groupings > in Ilastik vs. some old predictions, and to be fair, I'd like to use the > exact same binary image that we used back in the day. Is it possible to > load an image and separately load a binarized image and immediately go into > the object classificaiton workflow? As opposed to segmenting in Ilastik and > then performing object classification? > > Thanks > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at kausler.net Tue Mar 4 22:50:11 2014 From: bernhard at kausler.net (Bernhard X. Kausler) Date: Tue, 04 Mar 2014 22:50:11 +0100 Subject: [ilastik-devel] Your open source report card Message-ID: Dear all, I found the following site very amusing: osrc.dfm.io Did you know that Stuart is in the top 3% of the most active Python users on Github? Or that Annas developer personality is most similar to Lee Kamentsky? Best, Bernard -- sent from mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: