Bug#922584: [Help] Re: FTBFS against opencv 4.0.1 (exp)
I agree, it’s also unmaintained. Let’s take it out. Roelof (Author and original packager) Von meinem Mobiltelefon gesendet. > Am 02.12.2022 um 10:38 schrieb Andreas Tille : > > Am Thu, Dec 01, 2022 at 11:39:47PM +0200 schrieb Adrian Bunk: >> [1] contains a patch from a Debian porter, but considering the facts >> that limereg already missed the current Debian stable bullseye and the >> comment from upstream (who is also the original Debian packager) in [2], >> removal from Debian might be a better option? >> >> I do not know how limereg compares to other tools like for example >> elastix (based on ITK) or registrationx (part of CMTK) or other tools, >> but neither the upstream bug tracker nor the Debian BTS indicate that >> there would be an active userbase who report bugs or complained that >> limereg is not in bullseye. > > I'll immediately ask for removal of this package. > > Kind regards > > Andreas. > >> [1] https://github.com/RoelofBerg/limereg/issues/3 >> [2] https://github.com/RoelofBerg/limereg/issues/3#issuecomment-1296863979 > > -- > http://fam-tille.de >
Bug#841406: Fixed, verification in progress
Fixed. Next steps would be: adt-run --unbuilt-tree=limereg --- null git tag -s -a debian/1.4.1-1 -m "Release 1.4.1-1" git push --all git push --tag But I have a: WARNING: 'automake-1.15' is missing on your system, so I cannot verify before creating the tag. Will move my development PC to SID, maybe there automake is more recent, would be cleaner anyway.
Bug#841406: Ok
Ok, work in progress ... Thanks for reporting.
Bug#798601: limereg: FTBFS on mips/mipsel
I changed the compiler settings as suggested. This is only a hotfix to enable the package-build again. Because the underlying problem might be safety relevant (BOF) I added an entry to upstream's issue tracker and added a note to inform debian, when the compiler can be reverted to more strict settings again. Being also upstream, I will adress further investigation with highest priority for the next version of Limereg.
Bug#798601: limereg: FTBFS on mips/mipsel
Wow, thanks a lot Jurica ! I'll take care of it asap. On 17.01.2016 19:52, Jurica Stanojkovic wrote: User: debian-m...@lists.debian.org Hello, I have found that changing -fstack-protector-strong to -fstack-protector (for test or for entire source) does make this issue disappear on mipsel. [...] Regards, Jurica
Bug#798601: Reproduction of #798601: limereg on mips
Damn. If I execute it in qemu (Mips), all tests pass. Cannot reproduce it (yet).
Bug#798601: Reproduction of #798601: qemu
Based on https://people.debian.org/~aurel32/qemu/mips/ wget https://people.debian.org/~aurel32/qemu/mips/debian_wheezy_mips_standard.qcow2 wget https://people.debian.org/~aurel32/qemu/mips/vmlinux-3.2.0-4-4kc-malta qemu-system-mips -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1 console=tty0" Thanks Aurel32 On 26.10.2015 21:47, Roelof Berg wrote: I wonder what might be the best way, to test my fix for MIPS.
Bug#798601: Bug Analyzation
I wonder what might be the best way, to test my fix for MIPS. Esp. I wonder how the Debian build server operates. I would normally assume a cross-compile - but the tests seem to be executed on a real MIPS. Might it be emulated ? On 28.09.2015 22:53, Roelof Berg wrote: I assume, the software is ok but the test automation is not. Regards, Roelof
Bug#798601: Bug Analyzation
I assume, the software is ok but the test automation is not. The 'algorithm under test' gives a bit fuzzy results depending on the multicore calling order and depending on numerical rounding issues. Therefore the automated tests accept results within a range of plausible values. Seems that one of the automated tests is too strict. This is probably best fixed by upstream (which is also me, have I told about my multiple personality disorder yet ? :). Regards, Roelof
Bug#792624: Bugfix uploaded, but the package remains on the old verison ?
Hi Andreas, thanks for explaining. On 22.08.2015 15:12, Andreas Tille wrote: Roelof, [...] Just add a proper Closes: #792624, #792625 line in your changelog entry. Fixed [...] Moreover the package currently does not build currently due to the gcc-5 transition: I upgraded my SID installation and was able to build by: git checkout ssh://u...@git.debian.org/git/debian-science/packages/limereg.git cd limereg automake cd .. sudo adt-run --unbuilt-tree=limereg --- null I also used conventional configure/make, and it worked fine. I used GCC V 5.2.1-17 (current default on SID), maybe an update fixed the issues ? Did you built from scratch ? I allways start over quite clean by calling 'git clean -xdf'. Im not sure now, how to reproduce your failing build, maybe you can send me how you build and on which Debian and gcc version. Thanks. The following packages have unmet dependencies: libcv-dev : Depends: libopencv-features2d-dev but it is not going to be installed Depends: libopencv-calib3d-dev but it is not going to be installed Depends: libopencv-objdetect-dev but it is not going to be installed Depends: libopencv-legacy-dev but it is not going to be installed E: Unable to correct problems, you have held broken packages. Interesting. Where can I see this errors on SID ? I don't see it when building the package. E.g. by adt-run. Would adt-run be the proper way to get this output ? [...] Kind regards Andreas. Thanks a lot for supporting me. I'm still getting used to automake, Debian packaging and stuff. Kind regards Roelof
Bug#798601: GCC Update
Probably related to the latest GCC update, I'll take care of it.
Bug#792624: Bugfix uploaded, but the package remains on the old verison ?
Hi, this is about the third or fourth time I'm asking this. Any help would be greatly aprechiated. I uploaded a new version 1.4.0-2 of limereg that fixes #792624 and #792625. But I don't see the new version on: http://blends.debian.org/science/tasks/imageanalysis , so I cannot close the bug (right?). What must I do to get the new version regarded in the automated packaging ? If the answer is to remain patient, that'd be ok for me - I'm just not shure wether I might have missed something in the process. http://anonscm.debian.org/cgit/debian-science/packages/limereg.git I'm also a bit confused, why I got no answers and hope I'm using the bug-tracker and the mailing-lists correctly. I also hope, that my last joke about identifying ourselves at conferences by wearing big beards, bellys and bushy eye-brows wasn't annoying. Well, at least I would meet this criteria - except that my beard is too small, so I'd have to use an artificial one. However, as I assume that most women would rather not like wearing artificial beards on conferences, just forget about it. Thanks, Roelof
Bug#792625: Updated limereg to V1.4.0-2, fixed #792624 and #792625
Hi, I git-pushed a patch for limereg that fixes #792624 and #792625. This is my first patch and I don't know what to do now, will the new git version automatically be added to sid and stretch ? Or do I need to contact someone ? Bug cause: Doxygen (not help2man) added the current date to liblimereg's man pages, this lead to different man pages for amd64/i386, which voids Debian's multiarch concept. Solution: As first patch I added to debian/rules: override_dh_install: sed -i 's/^.TH .*/.TH liblimereg 3 August 2015 liblimereg-1.4.0 \\ -*- nroff -*-/' debian/tmp/usr/share/man/man3/liblimereg.3 sed -i 's/^.TH .*/.TH limereg.h 3 August 2015 liblimereg-1.4.0 \\ -*- nroff -*-/' debian/tmp/usr/share/man/man3/limereg.h.3 dh_install In future upstream versions I will probably drop doxygen and use hand crafted documentation. Debian rocks ! Roelof http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792624 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792625 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792624: multiarch = same and different date-entries in generated man page of i32/i64
Understood, I put this on my release backlog. Esp. getting rid of doxygen which is clumsy in automake would be great (and isn't justified for a small plain C API). For the current version I will, however, just add some small bugfix inside the .../debian folder. Thanks ! On 11.08.2015 10:21, David Bremner wrote: Many people use some [...] markup language like rst, markdown, or POD [...] rst2man, pod2man [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792624: multiarch = same and different date-entries in generated man page of i32/i64
I had a look at the idea of writing manpages manually (as upstream) and unfortunately saw some difficulties: Because OpenBSD and Linux use different *roff syntax, man vs. mdoc, if I understodd it correctly, generating the man pages in the syntax of the actual operating system would be the most portable way (everyone: correct me if I'm wrong). I don't want to favor Linux or BSD or Windows (just kidding :) in the source tarball. Defining SOURCE_DATE_EPOCH and using the latest help2man version did _not_ fix the date on my system. Even worse: I'm also using doxygen for the man page of the library, which isn't capable of using SOURCE_DATE_EPOCH anyway. So SOURCE_DATE_EPOCH doesn't seem to be the right direction for me. I'm thinking of rude stuff now: Patching the manpages after generation with my own script, taking the date based on dpkg-parsechangelog as input. Maybe it's possible with SED. I can't be the first one facing this issues, right ? Thanks for the excellent feedback so far. Roelof -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792624: Fwd: Fwd: Re: multiarch = same and different date-entries in generated man page of i32/i64
help2man 1.47.1 IS used. Next I will try as a workaround setting export SOURCE_DATE_EPOCH = $(shell date -d $$(dpkg-parsechangelog --count 1 -SDate) +%s) manually in debian/rules.
Bug#792624: Fwd: Fwd: Re: multiarch = same and different date-entries in generated man page of i32/i64
Hmm, good point, David. Because I'm also upstream this would easily be possible. It had to stay in sync then to the application/api behavior, which is, however, only a matter of discipline. Maybe I can use some familiar tool like LaTeX for writing. Thanks for the impulse, I hadn't considered it before :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792624: Fwd: Fwd: Re: multiarch = same and different date-entries in generated man page of i32/i64
Possibly a help2man https://bugs.debian.org/787444 version below 1.47.1 is used on the build server and help2man doesn't support SOURCE_DATE_EPOCH before this date. (See: https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal). I'm not familiar with the debian automated build infrastructure, and I will have to ask some newsgroups how to examine the build toolchain. Roelof
Bug#792624: Fwd: Re: multiarch = same and different date-entries in generated man page of i32/i64
Back from vacation: This is a consequence of #787675. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787675 Thanks to Anton Gladky for pointing me to that. The fix is on its way ... Roelof -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792624: and Bug#792625: limereg: arch-dependent file in \Multi-Arch: same\ package
Thanks for notifying, I will take care of it asap. The cause might be that I use enhanced speed optimization (which has to be considered in this particular case, as it is a computing intense algorithm that takes significant benefit from optimization/SSE/Vector-Units etc.). Roelof -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777000: Uploaded Limereg V1.4.0
Hi, I uploaded the latest upstream version of Limereg V 1.4.0 to alioth. I also added test automation during build time (by automake) and after installation (by autopkgtest). Location: git.debian.org/git/debian-science/packages/limereg.git On http://blends.debian.org/science/tasks/imageanalysis the package is listed as 'Packaging has started'. I'd be glad if that package could be updated to V 1.4.0, and possibly be reviewed for being turned into an official Debian package. Release notes: * Support for arbitrary aspect ratios * Support for color images as input image (will be loaded as greyscale) * Support for arbitrary image backgrounds * Added parameter --invert * Reduced the default value for --maxrot * Bugfix: Allow limereg parameters --outfile and --nogui to be coexistent Outlook: The next upstream version in a few wheeks or months will be V 1.5 with more stability and the possibility to search for subimages inside a bigger image (with the same API interface). Thanks for sponsoring :) Regards, Roelof -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777000: Uploaded Limereg_1.3.2 (optional)
Hi Andreas and List, I made a minor update of Limereg to V1.3.2 as upstream and uploaded it to Aliot (GUI-Bugfix: wrong difference image). This update is optional, because V1.4 will come out in about a month. By the way, if anyone wants to see some quick example of limereg: git clone ssh://y...@git.debian.org/git/debian-science/packages/limereg.git cd limereg ./configure CFLAGS=-Ofast CXXFLAGS=-Ofast make cd exe ./limereg --tfile ../tests/testimg/T_512.bmp --rfile ../tests/testimg/R_512.bmp Regards, Roelof On 27.04.2015 15:02, Roelof Berg wrote: Ok, I'm fine with an early release of V1.3.1 (which was accepted by the package server allready). I was just concerned wether the current version would be good enough for Debian. If not, V1.4 certainly will be. If V1.3.1 is allready sufficient, great, then go ahead :) Thanks for the fast feedback. Von meinem Mobiltelefon gesendet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777000: Limereg_1.4 release schedule
Ok, I'm fine with an early release of V1.3.1 (which was accepted by the package server allready). I was just concerned wether the current version would be good enough for Debian. If not, V1.4 certainly will be. If V1.3.1 is allready sufficient, great, then go ahead :) Thanks for the fast feedback. Von meinem Mobiltelefon gesendet. Am 27.04.2015 um 13:42 schrieb Andreas Tille andr...@an3as.eu: Hi Roelof, On Mon, Apr 27, 2015 at 01:32:20PM +0200, Roelof Berg wrote: limereg 1.3.1 is in ITP state. This version is limited to square image dimensions, grayscale colors and a dark image background. The upcoming V1.4 will not have any of theese limitations anymore, and can take virtually any image in any format. It will be released at 1st of June. It might make sence to wait for this V1.4 release before further processing my ITP. I do not think so. If you ask me uploading 1.3.1 to the new queue now will bring it into Debian before June and upgrading to latest upstream will then went quickly. Otherwise you will end up at the end of the queue in June. But finally its your decision. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150427114227.gi15...@an3as.eu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777000: Limereg_1.4 release schedule
Hi, limereg 1.3.1 is in ITP state. This version is limited to square image dimensions, grayscale colors and a dark image background. The upcoming V1.4 will not have any of theese limitations anymore, and can take virtually any image in any format. It will be released at 1st of June. It might make sence to wait for this V1.4 release before further processing my ITP. Regards, Roelof -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777000: Howto add my package to the (imageanalysis) tasks list ?
Hi Andreas, done (and verified by 'diff'ing the ...orig.tar.gz output to the upstream tarball). Regards, Roelof On 11.04.2015 12:34, Andreas Tille wrote: Hi Roelof, I checked the packaging of limereg with my sponsors hat on. Could you please provide a pristine-tar branch to enable me (== git-buildpackage) to recreate the orig.tar.gz out of the Git repository. If you have no idea what I'm talking about please ask here. Kind regards Andreas. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777000: Sponsor for limereg: Lightweight Image Registration
cc'ing sponsorship request to bugs.debian.org (see below). Package: git.debian.org/git/debian-science/packages/limereg.git Forwarded Message Subject:Sponsor for limereg: Lightweight Image Registration Date: Tue, 07 Apr 2015 00:36:02 +0200 From: Roelof Berg rb...@berg-solutions.de To: debian-scie...@lists.debian.org Hi, I'm new to Debian packaging and pepared everything to close my ITP #777000. I announced the location of the new files on debian-science-maintainers-requ...@lists.alioth.debian.org and I'm not shure what comes next. I might need a sponsor and will announce this on: https://wiki.debian.org/DebianPureBlends/SoB. Is there anything else I have to do now ? Somebody would like to sponsor this ? --- snip --- Package description: limereg V 1.3.1: Lightweight Image Registration, finds the alignment of two 2D greyscale images taken from different angles or views or points in time (rigid, analytical, derivative/optimization based, very fast (1s usually, kind of unique aproach), paper available at Springer JRTIP). It can either output the rigid registration parameters (angle and shift for the best detected overlay) or it can output the registered and/or difference image. The interface is ready for a registration-based subimage search with an optional stencil-map, this feature will come in the next upstream version. The interface is extendable to affine instead of rigid transformations, this is planned for an upcoming major release. The current version has one limitation: The image size must be square, that will be solved in the next minor release V1.4, then arbitrary aspect ratios will be supported. The packaging consists out of a library (liblimereg1, liblimereg-dev) that does the math and has no special dependencies. Furthermore there's a command-line tool (limereg) with UI and file in/output and depencencies to OpenCV. The library might be added to ImageMagick (under investigation, looks good) and maybe also to other frameworks like maybe OpenCV. Homepage: http://embedded-software-architecture.com/?p=183 --- snip --- Regards, Thanks Roelof
Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).
Thanks, I will proceed as you suggested. Because limereg is versatile and not limited to medical applications I'd prefer d-science, if I may choose. Regards, Roelof Am 10.02.2015 um 22:30 schrieb Andreas Tille andr...@an3as.eu: On Tue, Feb 10, 2015 at 06:24:04PM +, Ghislain Vaillant wrote: Added cc to debian-med. I personally disagree with your statement on medical image registration. I believe both fast and sophisticated registration tools can live together. Your package would fit perfectly in d-science or d-med, if not both. ... but usually we will not compete about packages between both teams. I'd recommend to pick the team you feel most comfortable in. Before actually finding a sponsor, you'd need to prepare the packaging somewhere, in your personal or chosen debian team git repository for instance, and make sure it is of sufficient quality for an upload (using tools like Lintian). Then, you will file an RFS bug, which will point prospective sponsors to the location of your packaging and give them instructions on how to build and test the resulting binary packages. I'd recommend https://wiki.debian.org/DebianPureBlends/SoB which (intentionally!) requires joining a team and using their VCS. ;-) Anyway, I need a sponsor, if this shall become part of Debian. That's granted via SoB. Kind regards and thanks to you both for the fruitful discussion Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).
Ok, thanks a lot ! I think, that's all assistance I needed for now, and I have enough information available for preparing the delivery. Debian rocks :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).
Great, I really appreciate this. Thank you. I plan to contribute three packages. I hope, the naming scheme is correct: limereg: Commandline application for image registration (available) liblimereg: Shared object library for image registration (in development) liblimereg-dev: Headers etc. for development (in development) Then I plan to integrate liblimereg to more common software like Imagemagick, maye OpenCV (if I'll be allowed to - by the package owners and by my family - well, in fact my wife, who doesn't like me sitting at the laptop all the time ;). I'm not sure which maintainer team would be better suited. It is meant for practical (!) application in all areas, from science over industrial automation up to end users. For medical image registration, however, it might be less suitable in many cases, because it is based on a very fast approach (ssd distance measure and linear interpolation), and in a medical setup usually more sophisticated (and probably more time consuming) approaches with a higher accuracy are used. I'm not sure if I will add these other algorithms (like ngf, spline ...) later. Well, maybe I will sometimes, because I'm working for a big medical device vendor in my daylight-life and just love this working field :) Anyway, I need a sponsor, if this shall become part of Debian. Regards, Roelof Von meinem Mobiltelefon gesendet. Am 10.02.2015 um 13:59 schrieb Andreas Tille andr...@an3as.eu: Hi Roelof, this sounds pretty interesting. Since I see some scientific application I added limereg-dev (assuming that the development library will be named that way) to Debian Science imaging and Debian Med imaging-dev tasks. I wonder whether it might make sense to maintain the package inside the Debian Science team or alternatively the Debian Phototools team (both teams in CC) Kind regards and thanks for this interesting ITP Andreas. On Tue, Feb 03, 2015 at 11:42:22PM +0100, Roelof Berg wrote: Package: wnpp Severity: wishlist Owner: Roelof Berg rb...@berg-solutions.de * Package name: limereg Version : 1.1.0 Upstream Author : Roelof Berg rb...@berg-solutions.de * URL : https://github.com/RoelofBerg/limereg * License : BSD Programming Lang: C++ Description : Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content). I developed this application as part of a scientific project. It offers 2D, grayscale, rigid image registration with a powerful derivative based approach and operates very fast and memory efficient (compared to traditional derivative-based aproaches). OpenCV is used to load and store the image data. The user can either output the registered image (image aligned/shifted/rotated upon another one) or it can output the numeric registration result (x-shift, y-shift and rotation). I want to develop this application further and want to maintain the .deb package. Furthermore I will publish the functionality as a library in an additional lib.deb and lib- dev.deb package. When the lib.deb package has been released I want to add it to imagemagik. This would enable people to register images just by using imagemagik :) I'm not aware of any other package offering image registration (if at all) in this speed and quality. Our mathematical aproach (regarding speed and memory usage) is very new and it is extremely unlikely that any other package can offer it. We just published it in a scientific magazine. Preprint: http://www.embedded-software- architecture.com/Berg2014Highly_Preprint.pdf Applications: HDR-Photograpy, Industrial Imaging (compare an actual photography to a reference picture), Medical Imaging (align images from different times or sensors), motion detection/compensation, and many more ... I will put as much effort in the packaging as necessary. As I'm an experienced software developer (e.g. Embedded Linux) my skills will be sufficient. The effort is low as it is only a small command line tool (yet ;) and I can do it alone. However, I'm new to Open Source and to the packaging. Do I need a sponsor to get the package accepted ? Also a review from an experienced packager would be required as this is my first step into Open Source contribution. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150203224222.27076.66773.reportbug@DellRBE -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).
Thank you for giving so much details. Well, I'd be happy off course if the package will be part of d-science and/or d-med. I will apply your suggested naming scheme, maybe with one exception: I'd prefer that the package named 'limereg' stands for the command line tool, this makes it easy for users that don't know what a shared lib is, and who only want to use the shell-utility named limereg. Then I could for example add liblimereg-src as a source package, if that is ok regarding the naming conventions. There is already ppa in launchpad for Ubuntu (ppa:roelofberg/limereg) that satisfies lintian. So if I understood everything correctly I will do the following: - Finish the library interface - Check for quality (there is a limitation for square image dimensions which I probably should eliminate before looking for a sponsor) - Port the Ubuntu launchpad package to Debian - Add further packages (lib, dev, dbg, src) - Publish the packaging projects in branches of my original github limereg project (right ?) - Then ask for a sponsor by providing build and test instructions Well, this will take a while. Thanks to everyone for supporting me so excellently. Regards, Roelof On 10.02.2015 19:24, Ghislain Vaillant wrote: Added cc to debian-med. I personally disagree with your statement on medical image registration. I believe both fast and sophisticated registration tools can live together. Your package would fit perfectly in d-science or d-med, if not both. Regarding your naming scheme, I have nothing against it. However, if your project becomes a large library associated with an executable, you might want to consider using limereg (source package name), liblimereg (shared object), liblimereg-dev (symlinks + headers), liblimereg-dbg (debug symbols) and liblimereg-tools or liblimereg-bin (executables). Your call. I would also suggest to finalize the separation between executable and library first before doing the packaging. Before actually finding a sponsor, you'd need to prepare the packaging somewhere, in your personal or chosen debian team git repository for instance, and make sure it is of sufficient quality for an upload (using tools like Lintian). Then, you will file an RFS bug, which will point prospective sponsors to the location of your packaging and give them instructions on how to build and test the resulting binary packages. Hope that helps. Ghis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).
Thanks for the links and the welcoming words. This is the motivation I need :) I'm currently busy with making my .deb package compatible to launchpad ppa as a quality measure. Am I allowed to use full optimization (-Ofast) ? Or is it mandatory to use -O2 ? I hope, this will find a sponsor. I contacted the Imagemagick package maintainers at first, before I submit a sponsorship-request. Wish me luck :) Von meinem Mobiltelefon gesendet. Am 05.02.2015 um 05:49 schrieb Asheesh Laroia ashe...@asheesh.org: Hi Roelof! I'm excited you want to work on this. On Tuesday, February 3, 2015, Roelof Berg rb...@berg-solutions.de wrote: I developed this application as part of a scientific project. It offers 2D, grayscale, rigid image registration with a powerful derivative based approach and operates very fast and memory efficient (compared to traditional derivative-based aproaches). OpenCV is used to load and store the image data. The user can either output the registered image (image aligned/shifted/rotated upon another one) or it can output the numeric registration result (x-shift, y-shift and rotation). Awesome. I want to develop this application further and want to maintain the .deb package. Furthermore I will publish the functionality as a library in an additional lib.deb and lib- dev.deb package. When the lib.deb package has been released I want to add it to imagemagik. This would enable people to register images just by using imagemagik :) That'd be splendid. I'm not aware of any other package offering image registration (if at all) in this speed and quality. Our mathematical aproach (regarding speed and memory usage) is very new and it is extremely unlikely that any other package can offer it. We just published it in a scientific magazine. Preprint: http://www.embedded-software- architecture.com/Berg2014Highly_Preprint.pdf Applications: HDR-Photograpy, Industrial Imaging (compare an actual photography to a reference picture), Medical Imaging (align images from different times or sensors), motion detection/compensation, and many more ... I will put as much effort in the packaging as necessary. As I'm an experienced software developer (e.g. Embedded Linux) my skills will be sufficient. The effort is low as it is only a small command line tool (yet ;) and I can do it alone. However, I'm new to Open Source and to the packaging. Do I need a sponsor to get the package accepted ? Also a review from an experienced packager would be required as this is my first step into Open Source contribution. As always, in Debian, if you're not a Developer in Debian yet, you'll need a sponsor to get the package accepted. In many things, and in Debian packaging too, I recommend trying to get something working first, then good, then great. My bandwidth for mentorship on this might not be huge, but I hope you can find a sponsor and a reviewer. If you have trouble, send me an email. Happy hacking! Asheesh, aka paulproteus at debian.org.
Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).
Package: wnpp Severity: wishlist Owner: Roelof Berg rb...@berg-solutions.de * Package name: limereg Version : 1.1.0 Upstream Author : Roelof Berg rb...@berg-solutions.de * URL : https://github.com/RoelofBerg/limereg * License : BSD Programming Lang: C++ Description : Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content). I developed this application as part of a scientific project. It offers 2D, grayscale, rigid image registration with a powerful derivative based approach and operates very fast and memory efficient (compared to traditional derivative-based aproaches). OpenCV is used to load and store the image data. The user can either output the registered image (image aligned/shifted/rotated upon another one) or it can output the numeric registration result (x-shift, y-shift and rotation). I want to develop this application further and want to maintain the .deb package. Furthermore I will publish the functionality as a library in an additional lib.deb and lib- dev.deb package. When the lib.deb package has been released I want to add it to imagemagik. This would enable people to register images just by using imagemagik :) I'm not aware of any other package offering image registration (if at all) in this speed and quality. Our mathematical aproach (regarding speed and memory usage) is very new and it is extremely unlikely that any other package can offer it. We just published it in a scientific magazine. Preprint: http://www.embedded-software- architecture.com/Berg2014Highly_Preprint.pdf Applications: HDR-Photograpy, Industrial Imaging (compare an actual photography to a reference picture), Medical Imaging (align images from different times or sensors), motion detection/compensation, and many more ... I will put as much effort in the packaging as necessary. As I'm an experienced software developer (e.g. Embedded Linux) my skills will be sufficient. The effort is low as it is only a small command line tool (yet ;) and I can do it alone. However, I'm new to Open Source and to the packaging. Do I need a sponsor to get the package accepted ? Also a review from an experienced packager would be required as this is my first step into Open Source contribution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
