Bug#693963: ITP: python-casmoothing -- Context-aware mesh smoothing for biomedical applications
Package: wnpp Owner: Thiago Franco de Moraes X-Debbugs-CC: debian-med@lists.debian.org Severity: wishlist * Package name: python-casmoothing Version : 0.1.0 Upstream Author : Thiago Franco de Moraes * URL : https://github.com/tfmoraes/python-casmoothing * License : GPL-2.0 Programming Lang: C++, Python Description : Context-aware mesh smoothing for biomedical applications Smoothing algorithms allow to reduce artifacts from mesh generation, but often degrade accuracy. The method described in the paper "Context-aware mesh smoothing for biomedical applications" identifies staircase artifacts which result from image inhomogeneities and binary segmentation in medical image data for subsequent removal by adaptive mesh smoothing. Thus, context-aware smoothing enables to adaptively smooth artifact areas, while non-artifact features can be preserved. This is a implementation of this method in Cpp with Python bindings. -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMmoLX8NrZYgaDV=NnDymT1Pj+CG6FaLysskBidBf9=pvt7...@mail.gmail.com
Re: InVesalius 3 Beta
Hi Andreas, On Wed, Nov 21, 2012 at 12:25 PM, Andreas Tille wrote: > Hi Thiago, > > On Wed, Nov 21, 2012 at 09:57:34AM -0200, Thiago Franco Moraes wrote: >> >> Done. I tagged the version 0.1 in github. Ah, To get a tarball that >> matches python-casmoothing- pattern I had to rename the >> github repository to python-casmoothing. I updated this information in >> control and changelog files from debian packaging. > > Great - I verified this and commited a watch file to SVN that fetches > the source package. > >> > I also think that the package deserves a bit better long description - >> > some cut-n-pasted phrases from the paper abstract might do the trick. >> >> Done. I think it's better now. > > Yep - it is. Thanks for working on this. > > So the only remaining thing before we can upload is to file a so called > ITP bug. Do you want to fire up > > reportbug wnpp > > and fill in this form to do this once you have done most of the work. > If not I could do it for you. Done. The bug number is #693963. I CCed debian-med. > Kind regards > >Andreas. > > -- > http://fam-tille.de Thanks! -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMmoLX_WbZtH0xm2rwbSeWP_Nc=20muxgbemngbd_wvg2cq...@mail.gmail.com
Re: InVesalius 3 Beta
Hi Thiago, On Thu, Nov 22, 2012 at 08:51:22AM -0200, Thiago Franco Moraes wrote: > > Done. The bug number is #693963. I CCed debian-med. Congratulations, I just sponsored your first Debian package. I have no idea how quick it will pass ftpmaster - in the current freeze time the delay for initial uploads might be longer than usual. I hope this will be helpful to let InVesalius follow soon. Thanks for your work on this Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121122123123.gf21...@an3as.eu
Re: MIA - Software for medical image alaysis
Hello, thanks for the pointers. I made myself an Alioth account (gert-guest) and will star to move the packages from ubuntus bazaar to the git structure. First some additional status: vistaio: * Licencing: is distributed under a BSD style license (the original license). * Code: I did a release that changes all the function and structure names to avoid a possible name conflict with what is distributed in the libvia package. everything else: * Licencing: All GPL2+ or GPL3+, all contributions were made by me or under my supervision, so I made sure the license is correct. - Now for some questions: - should I make an ITP bug for each package, or is it better to group the ITPs for packages that are closely related. i.e. vistaio - required for all other packages mia + pymia + viewitgui (mia is required by the other two) mialm + mialmpick - (mialm is requiered by mialmpick) - anybody has used the git-bzr-ng tool to bridge between bazaar (Ubuntu packaging repro) and git (debian-med)? https://github.com/termie/git-bzr-ng the thing is it hasent seen a stable release yet. - lintian: My libmia package contains more than one shared library, so I guess I should override the "package-name-doesnt-match-sonames", right? The libmia-doc created by Doxygen contains a "jquery.js" (embedded-javascript-library). I read that one should add the according package as dependency and remove the javascript, tried it, but is seems that the system provided jquery.js is different, i.e. the documentation web page didn't work properly. So I'd override this as well. mia-viewitgui and mialmpick: binary-without-manpage - what kind of man page is common for GUI programs (apart from possible command line options)? IMHO a man page should be helpful, but a GUI program will probably fare better with a graphical tutorial, especially since specifying comand line options is not really needed. Many thanks, Gert -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50ae2d0a.5050...@gmail.com
Re: MIA - Software for medical image alaysis
Hi Gert, On Thu, Nov 22, 2012 at 02:47:54PM +0100, Gert Wollny wrote: > thanks for the pointers. I made myself an Alioth account > (gert-guest) and will star to move the packages from ubuntus bazaar > to the git structure. Sounds good. I just added gert-guest to the Debian Med project to enable commit permissions. Note: I also found gerddie-guest Gert Wollny on Alioth - perhaps an old yccount you might have forgot. It might be a good idea to ask Alioth admins for deleting this (admittedly I have no idea about the account administration on Alioth.) Please make sure you read the "SSH tips" in our Debian Med team policy: http://debian-med.alioth.debian.org/docs/policy.html#ssh-tips and specifically the link to the Wiki article. > - > Now for some questions: > - should I make an ITP bug for each package, or is it better to > group the ITPs for packages that are closely related. i.e. There is a 1:1 relation between ITP and package. The reason is simple: If you upload the package the bug is closed - so with the first upload there would be no remaining bug to close for the other packages. >vistaio - required for all other packages >mia + pymia + viewitgui (mia is required by the other two) >mialm + mialmpick - (mialm is requiered by mialmpick) > > - anybody has used the git-bzr-ng tool to bridge between bazaar > (Ubuntu packaging repro) and git (debian-med)? > https://github.com/termie/git-bzr-ng the thing is it hasent seen a > stable release yet. Sorry, I never used bzr and I'm just starting to understand Git ... > - lintian: > My libmia package contains more than one shared library, so I guess > I should override the "package-name-doesnt-match-sonames", right? It depends. Alternatively you might consider creating more than one binary package. It helps to decide if you answer the question whether it might make any sense to install a single library without all the others - in this case I'd vote for single binaries. Otherwise a lintian override might make sense. > The libmia-doc created by Doxygen contains a "jquery.js" > (embedded-javascript-library). I read that one should add the > according package as dependency and remove the javascript, tried it, > but is seems that the system provided jquery.js is different, i.e. > the documentation web page didn't work properly. So I'd override > this as well. I recently learned that this could be a dangerous decision. If the source code contains some compressed JavaScript people do consider this as "binary without source" which in turn deserves a RC bug (or ftpmaster will reject the initial upload). Are you really sure that doxygen created jquery functions are not properly rendered with Debian's packages jquery? > mia-viewitgui and mialmpick: > > binary-without-manpage - what kind of man page is common for GUI > programs (apart from possible command line options)? > IMHO a man page should be helpful, but a GUI program will probably > fare better with a graphical tutorial, especially since specifying > comand line options is not really needed. Usually some basic manpage is fine. In many cases it is easily possible to genereate a manpage using help2man. Hope this helps Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121122141542.gh21...@an3as.eu
Re: MIA - Software for medical image alaysis
Hello Andreas, On 11/22/12 15:15, Andreas Tille wrote: Sounds good. I just added gert-guest to the Debian Med project to enable commit permissions. Note: I also found Good. gerddie-guest Gert Wollny on Alioth - perhaps an old yccount you might have forgot. Indeed, I didn't remeber that one. First I'll try to recover the password. The problem is, I don't know which email address I was using. I doesn't seem to be my current work address. There is a 1:1 relation between ITP and package. The reason is simple: If you upload the package the bug is closed - so with the first upload there would be no remaining bug to close for the other packages. Okay. - lintian: My libmia package contains more than one shared library, so I guess I should override the "package-name-doesnt-match-sonames", right? It depends. Alternatively you might consider creating more than one binary package. It helps to decide if you answer the question whether it might make any sense to install a single library without all the others - in this case I'd vote for single binaries. Otherwise a lintian override might make sense. You're probably right, the dev package will stay monolithic, but the libraries (and programs) could be logically divided. I'll thing about how to do this. There's another thing I overlooked - MIA uses plug-ins similar to ocatave using modules *.oct, I decided that it might be better to name the modules *.mia to avoid that every platform has its own code path for searching these libs. The problem is, dh_strip doesn't recognice these files and leaves them unstripped. I've seen this issue discussed with regard to octave and a bug report regarding Go modules, all unresolved and quite old. Hence, my solution is to patch the dh_strip script to consider the *.mia files and include this patched version in the debian build script, but since my knowledge of perl is close to zero, this is really a one-time hack. You know of a better solution? The libmia-doc created by Doxygen contains a "jquery.js" (embedded-javascript-library). I read that one should add the according package as dependency and remove the javascript, tried it, but is seems that the system provided jquery.js is different, i.e. the documentation web page didn't work properly. So I'd override this as well. I recently learned that this could be a dangerous decision. If the source code contains some compressed JavaScript people do consider this as "binary without source" which in turn deserves a RC bug (or ftpmaster will reject the initial upload). Are you really sure that doxygen created jquery functions are not properly rendered with Debian's packages jquery? I just confirmed that it doesn't - the debian package provided version of jquery is v1.7.1, but the doxygen generated script claims to be v1.3.2. In addition, I've scanned the doxygen source code, and it creates different scripts depending on the Doxygen htmlgen options (doxygen/src/htmlgen.cpp) which leaves the question which of the two possible versions is provided by debian. Apart from that the Doxygen tarball distributes the same compressed javascript code (upstream and in at least in Ubuntu 12.04) as of version 1.8.1.2. I just checked, it seems that doxygen 1.8.2 (which is in experimental) uses the 1.7.1 jquery. So in light of being able to backport the package, it would be better to keep the script, considering the RC bug thingy, I would consider to add the uncompressed version of the script (if it is still available) to the source tarball in a contrib directory if doxygen is < 1.8.2, and otherwise use the package version. Then again there is the danger that doxygen will not sync to ne new jquery release at the same time debian provides a new package. best, Gert -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50ae81a0.8030...@gmail.com
Re: MIA - Software for medical image alaysis
Hi Gert, On Thu, Nov 22, 2012 at 08:48:48PM +0100, Gert Wollny wrote: > > gerddie-guest Gert Wollny > > > >on Alioth - perhaps an old yccount you might have forgot. > Indeed, I didn't remeber that one. First I'll try to recover the > password. The problem is, I don't know which email address I was > using. I doesn't seem to be my current work address. I guess asking admins to delete the account might be a shortcut to a solution of the issue. > There's another thing I overlooked - MIA uses plug-ins similar to > ocatave using modules *.oct, I decided that it might be better to > name the modules *.mia to avoid that every platform has its own code > path for searching these libs. The problem is, dh_strip doesn't > recognice these files and leaves them unstripped. I've seen this > issue discussed with regard to octave and a bug report regarding Go > modules, all unresolved and quite old. Hence, my solution is to > patch the dh_strip script to consider the *.mia files and include > this patched version in the debian build script, but since my > knowledge of perl is close to zero, this is really a one-time hack. > You know of a better solution? Sorry, I have not dealt with such kind of issues. Probably my first action would be to ping the bug reports you were mentioning above. I'd guess it should not be terribly hard to patch dh_strip in a way that it could regard some extra specified extensions. Another stupid hack would be to name the files in question *.so in the first place and once dh_strip has done its work renaming the files. Something like override_dh_strip: dh_strip for miafile in `find . ` ; do mv $miafile `basename $miafile .so`.mia ; done might do the trick. > I just confirmed that it doesn't - the debian package provided > version of jquery is v1.7.1, but the doxygen generated script claims > to be v1.3.2. In addition, I've scanned the doxygen source code, > and it creates different scripts depending on the Doxygen htmlgen > options (doxygen/src/htmlgen.cpp) which leaves the question which of > the two possible versions is provided by debian. Apart from that the > Doxygen tarball distributes the same compressed javascript code > (upstream and in at least in Ubuntu 12.04) as of version 1.8.1.2. I > just checked, it seems that doxygen 1.8.2 (which is in experimental) > uses the 1.7.1 jquery. > So in light of being able to backport the package, it would be > better to keep the script, considering the RC bug thingy, I would > consider to add the uncompressed version of the script (if it is > still available) to the source tarball in a contrib directory if > doxygen is < 1.8.2, and otherwise use the package version. Then > again there is the danger that doxygen will not sync to ne new > jquery release at the same time debian provides a new package. I'm not fully sure what to recommend here. Perhaps you might backup your opinion at debian-mentors list. I'm fine with whatever you do and ftpmaster will accept. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121122203827.gd5...@an3as.eu
