[hugin-ptx] Re: have you heard about TOAST projection?
On 22 Dez., 04:40, Tom Sharpless tksharpl...@gmail.com wrote: I keep suggesting that our primary stitching targets should include the cube, since so many of our panos end up that way. It would be only a little extra work to make an engine for that do the TOAST and Pierce Quincuncial projections too. This made me think of the 'panini perspective tool'. What became of that? I found a debian package panini_0.71.104-0ubuntu1~lucid_i386.deb which I installed on my Kubuntu 10.10 system, but somehow I can't get it to work for me. Maybe it's a setting thing, in the top of the window it says 'Panini at 0.00 Mpixels', as if it didn't have any memory to work with, and when I try to load an image or even set a projection, the thing plain freezes. I thought the concept was promising, but it looks like it's not developed any further? The package is from March this year. Kay -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: Attn translators: BugFix = added translation string, sorry.
I just downloaded the current es_la.po (http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/raw-file/6a5ac6a405c7/src/translations/es_la.po) and opened it in Poedit: - 47 untranslated strings - 161 fuzzy strings This version is from Dec. 6 so are you sure you uploaded your translations already as described in http://wiki.panotools.org/Hugin_translation_guide#Getting_Started_on_translations - 4. Submit your *.po file... ? Carl john doe schrieb am 22.12.10 03:37: where is the string???so i can included it in an updated hugin es_la.po?? On Sat, Dec 11, 2010 at 9:12 AM, Carl von Einem wrote: It turned out that Thomas already dealt with the German string, so Poedit was right in telling me there's nothing new :-) However I found some typos and also a few inaccurate translations which I now updated and uploaded. -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: why is vertical line detection so hard?
On 22 Dez., 04:16, Tom Sharpless tksharpl...@gmail.com wrote: Kay is right. There is no way software, just looking at an image, can tell which way is up. That requires outside information, either from a person, who can judge such things, or even better, from a sensor in the camera. Maybe intelligent guesswork could get it right in a reasonable number of cases, though: - roll isn't excessive - pitch isn't either - there are vertical linear edges detectable in the image with these guesses assumed true (and specified as prerequisites for the method to work), try - any detectable linear edges roughly parallel to assumed vertical are candidates - if a good number of these candidates are near paralel or can be found to converge in a common point, they probably are vertical too The person who takes the photo doesn't just hold the camera out randomly, particularly if the intent is to later make it into a panorama, so the approach might work just like auto-levelling in hugin works well with it's statistical approach if the images are reasonable. Most photographers will make an effort to get their verticals right, so it would only be a matter of fine-tuning the result. If that fails or the prerequisites aren't met, it can still be done manually. Kay -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: why is vertical line detection so hard?
I re-added a straightening function the the calibrate_lens tool. Call it with a -w 1 flag. It assumes that all lines that are taller than they are wide are vertical. Then it rotates these about the image centre such that the difference in their max/min x-coordinates is minimised, and returns the angle of rotation. It's very crude and I haven't really tested. Take a look in Straighten.cpp if you're interested. Cheers, Tim On 22 December 2010 10:44, kfj _...@yahoo.com wrote: On 22 Dez., 04:16, Tom Sharpless tksharpl...@gmail.com wrote: Kay is right. There is no way software, just looking at an image, can tell which way is up. That requires outside information, either from a person, who can judge such things, or even better, from a sensor in the camera. Maybe intelligent guesswork could get it right in a reasonable number of cases, though: - roll isn't excessive - pitch isn't either - there are vertical linear edges detectable in the image with these guesses assumed true (and specified as prerequisites for the method to work), try - any detectable linear edges roughly parallel to assumed vertical are candidates - if a good number of these candidates are near paralel or can be found to converge in a common point, they probably are vertical too The person who takes the photo doesn't just hold the camera out randomly, particularly if the intent is to later make it into a panorama, so the approach might work just like auto-levelling in hugin works well with it's statistical approach if the images are reasonable. Most photographers will make an effort to get their verticals right, so it would only be a matter of fine-tuning the result. If that fails or the prerequisites aren't met, it can still be done manually. Kay -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.comhugin-ptx%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: why is vertical line detection so hard?
On 22 Dez., 10:55, Tim Nugent timnug...@gmail.com wrote: I re-added a straightening function the the calibrate_lens tool. Call it with a -w 1 flag. It assumes that all lines that are taller than they are wide are vertical. Then it rotates these about the image centre such that the difference in their max/min x-coordinates is minimised, and returns the angle of rotation. Hi Tim! I tried to test your addition to calibrate_lens, but I'm not sure what to make of the output. I can't see anything that looks like an angle. Maybe it didn't succeed? Here's my output: k...@anja:/$ calibrate_lens -l 4 -f 8 -c 1.6 -w 1 *6778_tilted.jpg Lens calibration tool Version Pre-Release 2010.5.0.e7939a4f5bc7 Processing image IMG_6778_tilted.jpg Crop factor:1.6 Pixel density (pixels/mm): 171.2 Focal length (mm): 8 Focal length (pixels): 1369.6 Scaling by: 0.392927 New dimensions: 1600 x 1009 Minimum line length:480 Detecting edges... Writing IMG_6778_tilted_edges_threshold_4_scale_2.jpg edgeMap2linePts(saveimages 1): 12417 segments linePts2lineList(lmin 479 flpix 1369.6) debug plot dbg_goodlines.jpg 23 lines debug plot dbg_badlen.jpg 307 lines debug plot dbg_badori.jpg 2 lines 23 lines 23 lines found Found 23 lines. Writing lines to file IMG_6778_tilted.lines Camera digicam h 4072 (171.2/mm) v 2568 (171.2/mm) Lens stereographic FL 8.0 mm (1369.6 pixels) Levenberg-Marquardt returned in 29 iterations reason 1 - stopped by small gradient J^T e start ||e||_2 : 0.565467 final ||e||_2 : 0.474595 ||J^T e||_inf : 9.04995e-20 ||Dp||_2 : 0 mu/max[J^T...]: 1.21239e+44 iterations: 29 stop reason : 1 function evals: 34 Fitted parameters... Radial mean sq. dev. 0.0028 factors: 0. 0. 0. 0.0074 0. 0. 0. ... so I'm not sure what to make of it. There seem to be plenty of good lines it found. Maybe you can clarify? with regards Kay -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: Attn translators: BugFix = added translation string, sorry.
i didnt upload the file yuval did it.. On Wed, Dec 22, 2010 at 4:59 AM, Carl von Einem c...@einem.net wrote: I just downloaded the current es_la.po ( http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/raw-file/6a5ac6a405c7/src/translations/es_la.po) and opened it in Poedit: - 47 untranslated strings - 161 fuzzy strings This version is from Dec. 6 so are you sure you uploaded your translations already as described in http://wiki.panotools.org/Hugin_translation_guide#Getting_Started_on_translations - 4. Submit your *.po file... ? Carl john doe schrieb am 22.12.10 03:37: where is the string???so i can included it in an updated hugin es_la.po?? On Sat, Dec 11, 2010 at 9:12 AM, Carl von Einem wrote: It turned out that Thomas already dealt with the German string, so Poedit was right in telling me there's nothing new :-) However I found some typos and also a few inaccurate translations which I now updated and uploaded. -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.comhugin-ptx%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] on the way to 2010.4.0 RC1 (sorting out the translations)
The current release cycle has highlighted some weaknesses in how we deal with
translations. Below are my findings. Comments, verifications, sanity checks
welcome.
Most translations arrive as incremental additions/improvements/corrections to
existing po files.
The right way to update translations that already exist in the codebase is
`msgmerge -o merged_translation.po existing_translations.po
new_contributed_translations.po`
First question: the above is what I understand when reading msgmerge's
manpage. It is the opposite of what is described in the translation guide
[0]. Should the translation guide be corrected?
Anything else than `msgmerge`, including the process to keep code branches in
sync described at [1] works only in special cases and is better avoided for
translations.
The terms to be translated are in English. Not all developers are native
English speakers. The inevitable language errors have been discovered too
late in the process. Executing extract-messages.sh early and often will help
preventing last minute fixes.
KEY LEARNINGS
1. Development: Execute extract-messages.sh early in the integration process.
Don't wait for release branching. This is particularly important when the new
strings were added by non-native English speakers and need to be polished.
2. Translation: The best way to contribute a translation is to publish your
updated po file in the issue tracker [2]. If you have repository access, keep
translating in the default branch. Apply your translation to the release
branch with msgmerge (or ask a developer to do this for you).
3. Bug-fixing: While bug-fixing during the release cycle, do not mix code
changes with translation changes in the same commits. this is generally good
practice, and luckily all bug fixes in 2010.4 have been done this way.
4. Release-management: From the moment the strings in the default and release
branch divert, do not transplant changes to the translations. use msgmerge
instead. if there is a need to run extract-messages.sh again, do it
separately in default and release branch, do not transplant. I will update
the wiki documentation [1] accordingly.
NEXT STEPS
For the specific situation of 2010.4, I went back over the whole history of
the translations.
Because the divergence between 2010.4 and default is negligibly small (details
below), I decided to
* just fix the errors in the English that have been identified on the mailing
list;
* run extract-messages.sh again to have clean .po files in both default and
2010.4;
* keep the language files as they are;
* work through the back log of contributed language files (thank you,
Alexandre).
* publish 2010.4.0 RC1 in the coming hours.
If you are a translator listed in the details below, after 20104.0 RC1 is
published, please check your language. If strings that you have translated
have disappeared, let me know and we'll work together to trace the changes
back. If you posted them on either the tracker, the mailing list, or the
mercurial repository, they are still available and fixing the issue boils down
to grabbing your contribution from the archive and msmerge it agains the
current po file.
For the future, it has been suggested to adopt Launchpad's Translations. We
still need to determine if it would make a difference (from reading its
description [3] my educated guess is that it will). What we already know now:
a mandatory requirement for Launchpad's Translations (as noted by Lukas) is
that they be BSD-Licensed. This is necessary for the translations to
propagate/share well. For Hugin it would mean that we either get the
translators to agree and relicense their work under the BSD license, or we
regress on the translations that can't be relicensed. To be discussed after
2010.4.0 is released.
DETAILS
Traditional code inspection tools such as `diff` don't work well on po-files
that have been edited with poedit or msgmerge. Moreover, not being fluent in
all concerned languages, it is difficult to conclusively say if the
translations are OK or not.
2010.4 branched out Nov 24 2010 at revision 4597, and we executed extract-
messages.sh twice since.
To obtain a list of the significant changesets, I did the following:
* added the following line to the [alias] section of ~/.hgrc:
ulog = log --template '{rev}\t{author|person}\t{desc|firstline}\n'
* listed the changes to default an 2010.4 branches into two files with
hg ulog -b default -r 4597: src/translations/* default.changes.txt
hg ulog -b 2010.4 -r 4597: src/translations/* release.changes.txt
* determined affected translations
- Czech (Vaclav Cerny)
- Venezoelan / Latin American Spanish (Ernesto Enrique Alvarado Viloria)
- Spanish (Uwe Koch Kronberg)
- Italian (Cristian Marchi)
- German (Joachim Schneider, Carl von Einem, Thomas Modes)
- Dutch (Harry van der Wolf)
- French (Jean-Luc Coulon)
- Hungarian (Lajos Höss)
* with the exception
