Re: [hugin-ptx] Mirroring in dual lens imeges
On Mon, Apr 13, 2020 at 11:39:54PM +0100, Bruno Postle wrote: > Hugin doesn't have any tools to work with mirror images directly, so > you will have to do some external processing. I would think that it is an artificial limit that would enforce that images cannot be mirrored in hugin. A negative scaling would map the image to its mirrored version. It is some "in hindsight unneccesary" limit check that checks for something negative to prevent mirrored images... Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20200414094741.GI23698%40BitWizard.nl.
Re: [hugin-ptx] Python help needed
On Sat, Aug 24, 2019 at 03:30:35PM +0200, 'Kay F. Jahnke' via hugin and other free panoramic software wrote: > The 'shebang' is a hint to a shell how to process code which is > launched by the shell; it's not part of python syntax (seen from the > python side, it's merely a comment, like the offending api-min and > api-max tags). If I remember correctly in the very old days when the shell was asked to execute say "/bin/which" (which is a #!/bin/sh shell script on my current system), the kernel would return "not an executable". The shell would indeed then open the file, check for #! as the first two characters and then launch the interpreter with the proper argument. This was in the days that we ran Unix on a PDP-11 with 256k RAM. (I don't remember if we ran BSD or sysV on that thing.) Anyway, on modern systems it is the kernel and not the shell that does this. I would vote for keeping the #! as the first two characters. What comes after that could either be /usr/bin/python, or /usr/bin/hugin . In both cases, this should be made to "do the right thing". If possible, this would mean starting the script within hugin. (I don't know what kinds of scripts we're talking about, but a script that asks the user to browse to say a specific type of pictures and then causes some preprocessing to happen before triggering an optimization and output step would make this possible. On the other hand if a script can only be run when you already have images loaded inside hugin, then this option does not apply. ) The other option for "right thing" would be to print an error message: "This can only be run from inside hugin". (*) When executing scripts hugin should try to enforce this first line to be correct. Take care that when it makes sense to be able to start scripts on their own, you should NOT check the PATH part of the "#!/...path.../program\n" . Just check for the #!/ first three letters and the right program name at the end of the line. Roger. (*) So the easiest way would be to have: #!/usr/bin/hugin -s as the first line of the script. Then the manual page for hugin would say: -s print "This script must be started from inside hugin" and exit. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20190824141914.GH12467%40BitWizard.nl.
Re: [hugin-ptx] Unable to assemble a simple 3x2 pano
On Mon, Aug 19, 2019 at 02:02:57PM +0200, Bruno Postle wrote:
> The fine-tune function does something else altogether. Here Hugin is
> directly comparing the image around each half of the control point -
> you can visualise this as subtracting one image fragment from the
> other and seeing if any features remain. This is much more like what
> you do when manually adjusting a control point, and the process gets
> very different results to cpfind.
This started me thinking about a good UI for a person to adjust a
control point.
Would it be easier for a human to fine-tune a control point if you
show the two images, overlapped across eachother, but with a
checkerboard pattern (say 3, 4 or 5 pixels to a square) determining
whether to show the left or the right image?
Roger.
--
+-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 --
- Datarecovery Services Nederland B.V. Delft. KVK: 30160549 -
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/20190819171503.GG20001%40BitWizard.nl.
Re: [hugin-ptx] Re: Question about "--new-lens" option of "pto_lensstack"
On Tue, Mar 19, 2019 at 08:41:22AM -0700, T. Modes wrote: > For scanned images this lens concept is not so good. So you would like to > optimize the field of view for each individual image. When I have an A4 scanner and say an A2 sized image, in theory four scans would cover the whole image, but to get some overlap to allow hugin to work I'll scan 9 images. Each of those scans will be precisely 2480*3508 pixels large and cover a real-life area of 210x297 mm. Why would you need to decouple and optimize the FOV separately? Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20190319160147.GL23430%40BitWizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] libpano gcc 8 warnings
On Sun, Sep 23, 2018 at 11:43:38PM +0100, Bruno Postle wrote:
>
>
> On 23 September 2018 13:48:10 BST, Andreas Metzler wrote:
> >
> >building libpano with gcc 8 (instead of 7) triggers a couple of new
> >warnings that might be interesting:
> >
> >parser.c: In function 'ReadImageDescription':
> >parser.c:1854:38: warning: '%s' directive writing up to 65535 bytes
> >into a region of size 256 [-Wformat-overflow=]
> > sprintf( sBuf.destName, "%s", buf );
> > ^~ ~~~
> It looks harmless to me, but my C isn't good enough to say for sure.
The compiler is saying that "sBuf.destName" is declared having a size
of 256, while "buf" is declared as being of size 65536.
When a compiler says such a thing it is usually right.
When this was written, someone probably thought about it and reused
the 65536 byte buffer "buf" for this small task. "buf" Needs to be
65536 bytes long for something else, and is now reused for this
purpose with "max 255" or even less still...
That said... Ignoring these warnings has for years caused serious
security leaks. These warnings didn't exist back then, but we should
take them serious.
In this case,
strncpy ( sBuf.destName, buf, 255);
is a quick rewrite of that specific line that a) avoids the warning
and b) avoids being unsafe even when someone external manages to get
"buf" filled further than expected.
The downside is that the API of strncpy is not convenient and requires
a sBuf.destName[255] = 0; at the end for the code fragment to become
really safe.
I would've liked something along the lines of:
char *mystrncpy (char *dst, char *src, int n)
{
if(!n) return;
n--;
while (*src && n--)
*dst++ = *src++;
*dst++ = 0;
return dst;
}
that always null-terminates the destination string even when the
buffer limit is reached. Alas they did not listen to me when I didn't
know this yet and was only 5 years old.
Roger.
--
+-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 --
- Datarecovery Services Nederland B.V. Delft. KVK: 30160549 -
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/20180924130644.GD4427%40BitWizard.nl.
For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Improving scan quality
On Tue, Feb 20, 2018 at 09:32:52AM -0800, T. Modes wrote: > Am Dienstag, 20. Februar 2018 17:57:08 UTC+1 schrieb Toolforger: > > Ah, the joys of too much editing. > > I tested with PNG and found that 300 dpi with the right settings are small > > enough. TIFF with one of its compression modes may work, too, > > > Sorry, but PNG and 300 dpi resolution have nothing in common. A JPEG and a > TIFF or a BMP can also have 300 dpi resolution. It seems you mix a lot up. Well, I do understand that after a bunch of non-information and wrong-writing, you start reading precisely what is written and nitpick on everything. But in this case, it's is pretty clear what is meant: When scanning the book at 300DPI, the resulting PNG is acceptable in (on-disk) size. PNG claims "lossless" compression. The question is: Is that relevant? If, say you scan at 600 DPI, and use a high-enough-quality JPG compression, I would expect that you can get better quality at less-bits-on-disk. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20180221144554.GP17324%40BitWizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Hugin 2018.0 beta1
On Wed, Dec 13, 2017 at 08:47:15AM +0100, Harry van der Wolf wrote: > I will alter the two fuzzy strings with the ampersand and look for an > available shortcut-character. > > 2017-12-12 17:21 GMT+01:00 T. Modes <thomas.mo...@gmx.de>: > > For instance the English text "" is in German "". I would expect the translation file then to contain "" -> "" for german. This would trigger a shortcut involving the B when german language is selected. When there is no letter available, I would expect the PO file to have something like: "" -> "afsluiten" to indicate that no hotkey is available in the Dutch translation. It would be wrong/fuzzy if you change the source text: "Quit" -> "afsluiten" Right? So looking for a hotkey is desirable, but not essential. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20171213123040.GQ32131%40BitWizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Keyboard shortcuts non working
On Sun, Nov 19, 2017 at 08:00:35AM -0800, T. Modes wrote: > There were alone 8 releases of GTK in the last 2 months. So it is difficult > to find a hint. In 3.22.25 the changelog mentions If you can use GIT, it is easy to pinpoint the exact commit that caused the problem. Just tell GIT: This version works,... this one does not. and then it will suggest a version for you to compile and test. Once that is done you say: this one works too. Or this one is bad too. and a new version is provided to test. In a few iterations you'll have the exact version that introduced the bug. A condition for this to work quickly however is that you can compile and test the issue for yourself. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20171120111932.GG6226%40BitWizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Simple rotation/translation stitching
On Tue, Aug 29, 2017 at 08:20:55AM -0700, T. Modes wrote: > > > Am Montag, 28. August 2017 18:22:37 UTC+2 schrieb Any One: > > Hugin appears to be very capable but in this case, I would say that simple > > rotation and translation would suffice > > > But this would require a rewrite of big parts of Hugin (optimizer, > remapper). What I suspect he means is that it would be nice to be able to select "simple rot/trnaslate only" say in the assistant. Would that require an essential rewrite??? Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20170829160206.GF9561%40BitWizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Strings from translation file
On Sun, Jul 03, 2016 at 04:42:59AM -0700, T. Modes wrote: > Hi, > > that comes early. A lot of the mentioned strings are used since years! When managing volunteers for an open source project, it does not help to give those volunteers a bad feeling. > > This string was already used by Hugin 0.7 (from 2008). And until now > nobody has complained. I will think about it. Here, a useful suggestion is provided. Even after years of doing it one way, it is useful if someone closely looks at the existing code/texts and provides feedback. IMHO, "nobody has complained" is not a valid argument. "Hmm. I think the text is clear enough like this. Thanks for your suggestion, but I think we'll keep the old text. Two arguments: First if we change it all translations have to be updated too, secondly, people using hugin have been used to this text for years. " sounds better. There are two projects where i occasionally find problems. Those maintainers are not good at managing my contributions. I then provide a patch like: "this fixes it for me but is not the proper fix. Let me know if you're going to accept the 'proper fix' patch ". When I hear nothing... nothing happens and bugs stay. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20160703115523.GE16042%40BitWizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Mildly off topic - rephotography?
On Mon, Feb 08, 2016 at 09:40:09AM +, paul womack wrote: > There was a lot of noise a while back (good $DEITY, it was 2010) > about some software at MIT that helped get the camera > into the right place; > > http://www.geek.com/news/new-camera-software-allows-you-to-line-up-your-photos-with-the-past-1272643/ > > (full paper: http://people.csail.mit.edu/soonmin/rephoto/rephoto.pdf) > > But I can't find any information that falls *BETWEEN* the 2 > extremes of "keep moving tilll you get it right" and the MIT software. > > Does anyone know of any other guides to technique and/or software aids? > I'm guessing lining up old and new photos might be mildly relevant to Hugin. Occasionally I too wonder if things couldn't be done better. In my local newspaper there is a column where they show an old and new photograph. Sometimes they get it quite right, sometimes almost I think that to gather enough information you would need to build a 3D model from the environment by taking a bunch of pictures with several viewpoints in the general area of where the old one was taken. Then, by matching the remaining buildings in th eold photograph to the 3D model you can calculate the camera position of the old photograph compared to the new images. Provided you've kept a precise log of where you took the "set of photographs for the 3D model", you should be able to calculate where to stand for the "NOW" picture... If hugin is capable of helping, it would be through the "XYZ offset" settings. Take a picture, import into hugin. Then, IIRC the XYZ offset system, you will have to make "a plane, say the front of a building" into the Z=0 plane. Check that everything on the building comes out straight and perpendicular when you create a projection on Z=0. Then when you match the old photograph to your new one, it should give you XYZ offset numbers An important parameter that needs to go into this would be the lens parameters for the old photograph. If that old photograph contains enough information about that in the picture itself (which is likely the only thing you have), remains to be seen. Interesting subject :-) Roger. > > BugBear > > -- > A list of frequently asked questions is available at: > http://wiki.panotools.org/Hugin_FAQ > --- You received this message because you are subscribed to the > Google Groups "hugin and other free panoramic software" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to hugin-ptx+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/hugin-ptx/56B86279.7070809%40papermule.co.uk. > For more options, visit https://groups.google.com/d/optout. > -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20160216142616.GC4978%40BitWizard.nl. For more options, visit https://groups.google.com/d/optout.
Fwd: [hugin-ptx] ACTION REQUIRED
Hi Elisabeth, Although I understand that sourceforge has gone through some effort to produce that video, it clearly shows that the creator of that video does not understand the basics of Hugin. Taking three pictures-of-dogs and making that into a "panorama" is the first clear hint. The second example is that she sets the JPG output quality to 100%. (JPEG compression at 95% is indistinguisable from 100%, and 100% only causes an unreasonable increase in size. If you want to prevent possible quality loss by using 100%, then you should not chose for a lossy compression like jpeg which will still lose quality at 100%. Choose tiff in that case.) Roger Wolff. - Forwarded message from Yuval Levy <goo...@levy.ch> - Date: Wed, 11 Nov 2015 18:17:58 -0500 From: Yuval Levy <goo...@levy.ch> To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] ACTION REQUIRED Hi Hugin community, Below is a message I just found in my mailbox. Before you continue to read, I suggest that you watch the youtube video sent with the message and make up your own mind. The link: <https://youtu.be/EYa21pinHJo> Give your feedback directly to Sourceforge -- contact details such as email and phone number are below. IMPORTANT: if SourceForge does not receive feedback within a week, this video will be on Hugin's project summary pages. My own opinion withheld. Yuv Forwarded Message Subject:Upgrade to Project Summary Pages - Hugin Date: Wed, 11 Nov 2015 14:25:25 -0800 From: Elizabeth Daniels <edani...@slashdotmedia.com> To: sfcommunity <communityt...@sourceforge.net> To help you enhance your project summary pages so visitors can quickly decide if your software fits their needs, we added a new feature to the page called the "Editor's Review <https://sourceforge.net/blog/announcing-new-editors-reviews>". Our Community Team, along with myself as the Senior Editor at SourceForge, manages this review. The Editor's Review includes a written review with the top features and images and/or a short video preview, depending on the project. For example, here’s a video we’ve come up with for your project: https://youtu.be/EYa21pinHJo If we don’t hear from you in a week, we’ll go ahead and update your SourceForge project page with this video review. If you wish us to edit or improve it, please let us know and we'll pause it until edited. If you think that a video just doesn't fit your Project Summary Page let us know, and we'll remove it right away. We can also help you obtain up-to-date screenshots that promote the best qualities of your product (or you can them to your project summary page). As you know, nothing grabs a user’s attention like images when they’re trying to decide on a product. Let us know if you have any questions and thanks for being part of the SourceForge community! Warmly, -- Elizabeth Daniels Senior Content Editor SourceForge.net <http://sourceforge.net> | 415.713.0229 -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5643CCA6.3060906%40levy.ch. For more options, visit https://groups.google.com/d/optout. - End forwarded message - -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/2015234300.GB8513%40BitWizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Paid Help Wanted with Hugin OSX 2014
On Fri, Oct 16, 2015 at 08:03:04AM -0700, T. Modes wrote: > > - Calculate optimal size > > > When selecting "create panorama" the width and height is already populated > with the optimal size. Hmm. When I last tried that (already around two years ago), the "optimal size" in the "expert interface" was around 1.5 times larger (both width and height) than what the "simple interface" used/suggested. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20151017090306.GT29030%40BitWizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] 2015 beta2 ram usage
On Tue, Jun 09, 2015 at 08:29:46AM -0700, T. Modes wrote: So the raw converter should update the focal plane resolution when it updates the image size tags. But this needs to checked if this is valid for different raw formats. This is beyond my scope. Again, this is the obviously right thing to do. Under my clause: if it makes interfacing with closed-source-hard-to-change-hard/software difficult, then a workaround might be implemented. But by default such a bug should be fixed first, and where it isn't applicable due to bugs in commercial/closed-source/embedded stuff, THEN a case-by-case exception could be made. The code likely does: copy the whole exif, add/overwrite the things we know (resolution in pixels) and done! Alas, it is not that simple. :-( Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20150610061310.GJ11256%40bitwizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] 2015 beta2 ram usage
On Thu, Jun 04, 2015 at 11:43:41AM -0700, T. Modes wrote: But I don't know if the breaks the calculation of other camera. Opinions? IMHO, we can/might work around bugs in commercial software or firmware in the cameras. Those take ages to get fixed.But if it is another open source package that wrote this we should tell those guys to fix their software. If we silently work around bugs in other open source software you're going to get an escalation of fix for bug - have to maintain compatiblity - even weirder shit. So if what we're doing is provably right. That's how it should be. (Sure we COULD use the other parameters leading to the correct result, but we SHOULD also be allowed to use the parameters that were actually used.) Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20150604214738.GD31513%40bitwizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Verdandi: the new blender
On Tue, Jun 02, 2015 at 10:52:27AM -0700, T. Modes wrote: Hi Harry, Am Dienstag, 2. Juni 2015 10:19:24 UTC+2 schrieb Harry van der Wolf: And a bug I think: I use a project and run the blending with enblend and afterwards close PTBatcherGUI. Then I change the blender to verdandi (integrated) from the preferences, save the project again rerun the stichting. Still enblend is used. I have to close Hugin and reopen it again to have it use verdandi. Tomorrow I have more time and I will check more thoroughly also w.r.t. the assumed bug. I don't think that this is a bug. This could be a feature ;-). In the preferences you set the default blender, which is used for *new* projects (the same as the output format directly above). This is used when you create a new project afterwards. If you want to change the blender in an existing project, go to the stitcher tab and change the blender there. After saving the project file PTBatcherGUI should pick up the change for this project and use the chosen blender. Can I make a suggestion? How about the blender setting in the stitcher tab that is: add a use the default blender. That setting will use the current hugin default, unless changed. With a bit of programming that would be: hugin default blender: now enblend, or hugin default blender: now verdani. I think that would work more intuitive for most users. On the other hand If you save and reload such a setting, thereby allowing the user to change the blender by changing the hugin-default, then the results would depend on the current settings of the hugin that opens the PTO. That might be undesirable for reproducability. (e.g. use hugin on the laptop to create a pano at half-res, then move to bigger computer and restitch the project just with a higher resolution) Still it is confusing for a user to say want to switch between enblend and verdani, look around in the menus, find a setting where you can choose between the two, and then. nothing changes. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20150602184113.GE32418%40bitwizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] One photo taken without tripod
On Wed, May 27, 2015 at 11:35:31PM +0100, 'boomslang' via hugin and other free panoramic software wrote: Hi all, I am working on a 360 degree panorama. All but the last photo are taken using a panorama head on a tripod. The largest control point distances all involve this last photo. How do I tell Hugin to optimise TrX/TrY/TrZ only for this specific photo? Currently I use Hugin 2014. I haven't been using Hugin for a while. So I've forgotten where everything is exactly. In the advanced settings for optimization, you can manually select what to optimize. The workflow I'd recommend would be to optimize normally (maybe even with the assistant: no special stuff necessary), and only then add the last picture to the project. Next, in the advanced settings, you optimize nothing except the roll/pitch and fov of the last picture, and the TrX/TrY/TrZ that you mentioned. That should make that last picture fit right in. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20150528064107.GE16445%40bitwizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] How to best use Hugin/enfuse for super-resolution imaging
The basic idea is that if you have say a 1000x1000 sensor, and take pictures HALF a pixel off, by taking 4 pictures you can make a 2000x2000 image. The move the sensor image stabilization cameras have the hardware to move the sensor half a pixel in a controlled way. Others may need to take enough pictures so that you probably have a picture taken with the right offset. Then, the next problem arises: If your lens is perfect, each pixel takes the average of all the image projected on its square. So if you take the four images at half pixel intervals, you'd still have a 2x2 blur in the resulting 2000x2000 image. A sharpening algorithm is required. This is complicated: Modern cameras however don't have RGB sensors for each pixel, but either red, green OR blue. Then... when say light hits each green sensor pixel, but misses the intervening red or blue pixels, the recover-the-color algorithm would say GREEN! when someone with a black-and-white shirt is at eactly the right (or wrong :-) distance. (it's similar to the wrong tie on the news phenomenon). Anyway, to prevent this, they make the lenses or sensors in such a way that it is impossible to focus light on eactly one pixel. A deliberate defocus. So that makes things even more complicated. Anyway... hugin should be able to position two images over each other at subpixel accuracy. This is essential if you cannot control the sensor at subpixel accuracy. I would give hugin the ORIGINAL images. Then tell the remapper that your output has a high resolution. This will do proper upscaling of the pixels. Enfuse is completely the wrong tool to then combine the results. So you'll have to find something else to use here. Maybe just averaging all the images works. Then a sharpening step is necessary. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20150304165238.GL28613%40bitwizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Grid Stitching Senior Design Project
On Fri, Feb 06, 2015 at 08:21:29AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote: I have already found vertical CP to stitch a zenith image in a spherical panorama using cpfind in a script. I agree with Terry's suggestion to try it. You don't need to generate so many temporary files, unless you want them for something. You can just point to the same file as input and output, like: I personally think that hugin is too liberal in throwing away temprary files. When you're working with easy panoramas you click through the assistant, and voila a wonderfully stitched panorama. But when things get difficult, things like finding the control points need to be done again and again, because the results from earlier times are not kept. But also, if you are incrementally adding pictures and after a certain point decide to no longer optimize the say background, the remapped versions of those images are nice to keep around. (this happens if you take say 6 shots at 18mm to make the overview and then zoom in to 135mm and take another 100 shots to get more details of the interesting part. And trust me: this kind of panorama is not a click doit in the assitant.) In the case at hand, if you get the dependencies right, Make is a good tool to re-do the minimal amount of work. For hugin in general, the problem is a bit that every remapping depends on the PTO file. So you need to extract the remappings of each picture, put them in a separate file, and then use a move-if-changed tool to update the extracted files again. Anyway, I'm a bit supporter of many intermediate files and not throwing them away. Roger. pto_var --opt y,p,r -o output.pto output.pto autooptimiser -n -o output.pto output.pto Cheers, Carlos E G Carvalho (Cartola) http://cartola.org/360 http://www.panoforum.com.br/ 2015-02-03 20:17 GMT-02:00 Derek W djrobotfr...@gmail.com: Hello! I am a senior computer engineering major working on my senior design project in image stitching. For this project I am working with stitching hundreds of rice field images with GPS metadata included. I have decided to give PanoTools a shot for stitching these images, and have made a prototype script for stitching 2 images together. Here you can see the prototype BASH script: pto_gen -o to_stitch.pto -p 0 -f 10 $1 $2 autopano-sift-c output.pto to_stitch.pto pto_var --opt y,p,r -o output2.pto output.pto autooptimiser -n -o output3.pto output2.pto autooptimiser -m -o output4.pto output3.pto pano_modify -o output5.pto --center --straighten --canvas=AUTO --crop=AUTO output4.pto echo optimiser done, see optimised.pto. creating make pto2mk -o output.pto.mk -p output_stuff output5.pto echo done creating make, see final. now making. make -f output.pto.mk Using this script I am able to successfully stitch two rice field images left to right. The problem comes when I rotate each of them 90 degrees. It seems that autopano-sift-c can't find control points vertically. It is my understanding that SIFT algorithm alone should be able to identify control points, but I'm guessing this implementation must have been optimised for panoramas. So my question: Does anyone know a way to get autopano-sift-c to detect keypoints vertically? If not, is there another keypoint finder I should look into? Also if you see anything in this script that looks dumb or unnecessary please let me know. Thanks! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/e23cbeca-13f2-4d58-8418-203283039b9e%40googlegroups.com https://groups.google.com/d/msgid/hugin-ptx/e23cbeca-13f2-4d58-8418-203283039b9e%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CALW1f7gkLDdjfjsiRe8g_C84qU1dqhF8HWbKj4WKVuqd2a4_oA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl
Re: [hugin-ptx] Linear Gigapixel wall pano help required
On Thu, Nov 27, 2014 at 04:35:04PM +0500, Emad ud din Bhatt wrote: Second question is can i stitch individual columns first and use fast view to correct distortion and than combine 1. pto files or 2. stitch output jpeg/tiff columns together? In this case, I'd say that just stitching a column, then outputting as rectilinear and stitching those should work. I don't recommend adjusting inbetween. (not sure what you mean by that). The problem with the incremental stitches is that if you take a gigapixel image, say 20 rows of 20 pictures, then stitching each row may cause a small stitching error, One row might bend up a little like :-) and the other might bend down a little :-( . Those will not easily combine. You here have a similar situation: one colum bending left a bit, the other bending right a bit will not combine nicely. :-( Roger. Regards, Emaad On Thu, Nov 27, 2014 at 4:02 AM, Terry Duell tdu...@iinet.net.au wrote: Hello Emad, On Thu, 27 Nov 2014 08:42:30 +1100, Terry Duell tdu...@iinet.net.au wrote: I'll grab a screen capture of the stitch you posted on-line, to see if it can be pulled into shape. I'll let you know how I get on, and see where we go from there. I'm not having any success with the screenshot of your stitch, probably because it has been manually manipulated post stitch. Others may have better advice, but my thinking is that your best approach is try to stitch the project in hugin. Add vertical lines to selected images if linefind doesn't do that automatically for you (set Detect vertical lines in the Assistant tab of Preferences), and add some horizontal lines to selected images as well. Optimise for y,p,r,X,Y,Z assuming that you moved sideways for each column of your shots. You could optimise for barrel as well if you don't have a lens calibration to apply in hugin, but I would suggest progressively optimising in steps. Cheers, -- Regards, Terry Duell -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ ---You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/hugin-ptx/op.xpyfl2slrs0ygh%40localhost. For more options, visit https://groups.google.com/d/optout. -- *Emaad* www.flickr.com/emaad -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CALj_J36G47OZPmZBwf3Qz1w2X3kPNW6hoh7iAHPSKWsokn%3DUZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20141127120432.GJ7873%40bitwizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Interface comments: The Fast Preview Window
On Mon, Oct 20, 2014 at 08:20:50AM -0700, T. Modes wrote: This is a conflict in two sentences: either there is a close button - the normal red light on Mac OSX or the normal close button on other systems- or there is no close button. I don't see the point of have a dedicated close button when there is the normal close control on the window. I understand the reasoning However some programs manage to create a window that DOES NOT have the normal close button. I have now figured out how to get the window-menu (control-middlemouse in the title bar IIRC -- update: NO, i didn't remember correctly it's control-leftmouse (*) ), and I can close those windows. Apparently those windows are popup questions which on other window managers still do get the close button, so the developers left their own close button out, but on mine they don't because when they were still just a simple question I'd make the window go away by either clicking YES or NO. So. IMHO, something can be said for always including a close/exit/continue button somewhere because you can't be sure that the window manager always provides such a button in a visible manner. Roger. (*) This is to show that it is rare enough that I don't use it often enough to remember how I did it last time Now I'm a heavy computer-user... -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20141021074142.GB7727%40bitwizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Latest Hugin model, transform specification?
On Fri, Oct 03, 2014 at 01:08:33AM -0700, T. Modes wrote: * Optimizing TrZ *and* HFOV for all images with separate lenses is not helpful. Changing TrZ and HFOV have both a very similar effect on the remapped image (both scale the image). So the optimizer can achieve the same result with 2 different values. This makes the optimisation more fragile than needed. more fragile is sort of an understatement. When the size of an image ends up like size = C * TrZ * HFOV, optimizing for both should converge on any solution where TrZ * HFOV comes out to the same value. Then the optimization is in a difficult situation. Each time it has a tentative solution it will figure out if the solution becomes better or worse when increasing or decreasing each variable. Well, the solution will have ALMOST no change when decreasing HFOV as long as you increase TrZ proportionally. But going the other way also has a similar effect. In practise the computer will always find a minimal effect, and end up with one of the variables huge and the other very small. Small computational rounding issues will determine what way things will go. But you'll usually end up with a silly solution, that exagerates any computational roudings. So you'll end up with something like: Oh, you took this picture from the moon, with a very, very good telescope!, but then tilting the telescope just a faction of a degree will make the placement of the picture totally wrong. That sort of stuff. Even more practical, the transformations are probably not identical, but only very close. So slight mis-positioning of a control point (even at fractions of a pixel) will cause the algorithm to go haywire into some silly direction. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20141003093614.GD23689%40bitwizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Hugin operation questions from a mostly-newby
On Tue, Sep 09, 2014 at 12:01:59AM +0100, Bruno Postle wrote: On Mon 08-Sep-2014 at 02:08 -0400, William Sherman wrote: I then ran the 2. Align step. And this took over 6 hours to process. It was not fun waiting for that, and I dread what will happen when I get to my large image collections! I did notice that at times all the CPUs were going, and then other times just a single CPU. Also, I'd be interested to know exactly what Optimizing Variables were being optimized to get a sense for where it is in the process. William, The optimization process cannot optimize a variable at a time: they are all interconnected. The optimization works a bit as follows. Suppose we have a function that we don't know. In fact it's y=x^2, but again, we don't know that. Suppose we want the result to be 10. So we try puttin in 1 and get 1 put in 2 and we get 4. From this we calculate that adding one to x, results in 3 more in the output. We need 6 more output, so we add 6/3 = 2 to the input. 2+2 = 4, so we try 4 next. We get 16, which is way too far. now we have from 2 to 4 on the input the difference in output is 12, and we need to be exactly in the middle. So we probe exactly in the middle: 3. So now we get 9 and need to go a little higher. 16-9 is 7, we need to be 1/7th on the way from 9 to 16, 1/7th of the way from 3 to 4: 3+1/7 = 3.1428. Now we get pretty close, and it gets annoying doing this by hand. But now that we are close, we get closer really, really quickly. Just a few more steps and we'd have our solution to many decimal places. (after these few steps by hand, we have only a 0.6% difference with the mathematical solution). For panoramas there are a whole lot of parameters to adjust. This means that there no longer is a mathematical solution. But the approximation technique still works. So for hugin to optimize the panorama, it calculates how much to change all the parameters at once, then it changes them all and next it will start the process of finding how much to change each one all over again. From my example, you can see that if you start off with a pretty bad estimate, it takes a few iterations to get close enough to get into the gets closer really really quickly region. The number of iterations required to get close enough gets more and more as the number of parameters increases. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20140909081313.GC11757%40bitwizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: ContractViolation: with windows pictures, but not mac pictures?
On Sun, Jun 22, 2014 at 09:22:19AM -0700, Brandan wrote: The same property on the mac says Quick Time 7.6.6 When I stop and think about it I wou I've looked quickly at both files, and both files do NOT look like they are directly from the camera. Apparently on BOTH computers your friend has an APP running that will intercept incoming pictures and does something to them. However, while the workflow is interesting to analyse, it should be possible to run hugin on a file that has experienced either workflow. So on the hugin end, for debuggin purposes we'd like you to create a minimal set that shows the problem. Then others can test if it also happens, say on a different operating system. Possibly a developer will try it on his/her machine and see the problem be able to debug it there-and-then and get it fixed. I have a hunch that somehow, to hugin, a required or expected exif field is missing. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20140625125146.GB21038%40bitwizard.nl. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Panostitch is a port of Hugin, but it is paid and does not provide source code?
On Mon, Feb 03, 2014 at 08:37:05AM -0800, Naked Robot wrote: sorry, i'm not clear about why they'd be allowed to refuse to give the source to one person but not another person. can you please explain the logic? The GPL states that if you give someone a binary you created from GPL software, you are required to provide /that person/ with the sources (or provide a service that allows them to get it). Sure, in the days of the internet it's easier to just post it on the internet and point the persons who legally have the right there. But you don't have to do that. As a distributer of GPL software you are under the obligation to provide source to those who get the binary from you. No obligation to anybody else. The GPL does not require you to provide source to anyone, just to those that have gotten (bought?) the binary from you. Roger. On Monday, February 3, 2014 5:20:59 PM UTC+1, r.e.wolff wrote: On Mon, Feb 03, 2014 at 10:29:21AM +, Bruno Postle wrote: On Feb 3, 2014 9:28 AM, Naked Robot 360c...@gmail.com javascript: wrote: https://play.google.com/store/apps/details?id=com.myboyfriendisageek.panostitch this is a port of hugin, right? No idea. how can they charge money for it? where is the source code? In general people are allowed to charge for distributing GPL software but they also need to supply the sourcecode if requested. They need to provide the source to people who HAVE the binary (from them). i.e. if you, random user aks them for the source, they are allowed to refuse. If someone buys it, asks for the source and then recompiles the bunch he's allowed to distribute it again. Same price, higher price, or free. Whatever he/she wants. This means that the market value of the bought version will drop quickly to nearly or completely free. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/e907fe11-145b-4b5a-9c58-0e93c2309737%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20140204101651.GA11160%40bitwizard.nl. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Panostitch is a port of Hugin, but it is paid and does not provide source code?
On Mon, Feb 03, 2014 at 10:29:21AM +, Bruno Postle wrote: On Feb 3, 2014 9:28 AM, Naked Robot 360cit...@gmail.com wrote: https://play.google.com/store/apps/details?id=com.myboyfriendisageek.panostitch this is a port of hugin, right? No idea. how can they charge money for it? where is the source code? In general people are allowed to charge for distributing GPL software but they also need to supply the sourcecode if requested. They need to provide the source to people who HAVE the binary (from them). i.e. if you, random user aks them for the source, they are allowed to refuse. If someone buys it, asks for the source and then recompiles the bunch he's allowed to distribute it again. Same price, higher price, or free. Whatever he/she wants. This means that the market value of the bought version will drop quickly to nearly or completely free. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20140203162058.GA25068%40bitwizard.nl. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] diy stitch back, overlap %
On Thu, Jan 30, 2014 at 07:54:40AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote: Something around 20 to 30% is usually ok. I'd recommend 50%. If possible: Just over 50%. That would mean that if worst comes to worst, and you lose a picture you can do without one! If say the speed of taking the panorama is important, you could go as low as 30 or 20%. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20140131115429.GA14804%40bitwizard.nl. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Re: Panotools::Script 0.24 released
On Tue, Oct 22, 2013 at 05:13:41PM +0100, Bruno Postle wrote: On 22 October 2013 16:22, Yemi Harris y...@newspin360.com wrote: When you say a good set of photometric parameters, what exactly do you mean? Sorry for my ignorance, i'm kind of new to the game. In theory the 'camera response' parameters will stay the same for all photos from the same camera (though your RAW converter can mess this up), similarly the 'vignetting' parameters will stay if you use the same lens/aperture. So if you get a 'good' panorama stitch once, then there is no need to let Hugin recalculate all these parameters for the next panorama, you can just reuse them. But in practise, you often get slight errors in the determination of these parameters. Thus it is not always certain that something that fit on pano-1 will fit on pano-2. This sometimes has to do with little freedom to determine these parameters. For example, if you just overlay the images left-to-right by 10 or 20 percent, then there is very little vignetting difference between the left and right side of the overlap. So determining the vignetting parameters becomes difficult. So large errors result and the resulting parameter may not fit will on another pano. But if your first pano provided good data, you can surely consider transporting them to the next pano. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20131022162038.GB27402%40bitwizard.nl. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Nothing but green
On Tue, Oct 15, 2013 at 07:51:49PM +0200, Stefan Peter wrote: The next thing I tried was to manually copy over your control points to my pto so I could run the optimization. Much to my horror, a simple optimization for Positions and View (y,p,r,v) resulted in a focal length of 299 mm for the lens. ... simply want to create a wide image composed from 3 24mm images. I'd propose the following: You should optimize v or viewing-angle only if you have a 360 degree pano. When you have a 24mm lens, three pictures won't take you all the way around. If you'd take something like 18 pictures at 24mm and go all the way around, the mathematical viewing angle calculated from the 24mm focal length will differ slightly from the actual viewing angle. This will make the first and last picture not fit. To correct for this you can optimize v as well. However this does not make sense to do when you have only a 90 degree total viewing angle. Of course, the difference will still be there, but it won't influence the actual pano-sphere that much. Just a little scaling around the center. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20131015200859.GC4414%40bitwizard.nl. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] enfuse license
On Mon, Oct 14, 2013 at 10:59:09PM +0200, Stefan Peter wrote: Yes, I agree with the donationware aspect here. However, when taking a look at the site mentioned, I can not help to mention a couple of points: o there is no mentioning of the GPL origin of the various enblend binary variants offered for download The GPL recommends that this is displayed on startup, right? o there are no version informations of these binaries Annoying, but legal. o therfore, it is not possible to download the appropriate source from the official locations, even if those would have been mentioned o there is no link to the sources used for the binaries offered In the modern world, just putting the sources on your website for everybody to download is the easiest thing to do. The GPL however was written when the web didn't quite exist as it does today. So the GPL requires that you provide THOSE who obtain (buy?) the binaries from you with the sources. You can even charge a handling fee for putting the CD in the mail. The GPL /then/ allows the customer to put it, modified or not, on the web. So the business plan of becoming an enfuse reseller will quickly grind to a halt as people find others providing sources (and binaries) for a lower price (zero). I've sold collections of GPL software for big amounts. They wanted me to put things together, have a single responsible person etc etc. And they could've put the whole thing on the web, preventing me from selling the product again (which I did once or twice at big intervals - I had to redo lots of things). Again, IMNAL. But you can't hang this developper because she/he asks for a donation on GPL licence grounds, from my point of view. Ditto! Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20131014230353.GF12912%40bitwizard.nl. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Scrapforge
On Fri, Sep 27, 2013 at 09:26:52PM +0200, Thomas Pryds wrote: Just to make an attempt as reviving this rather old thread about moving Hugin away from Sourceforge, I'll share a discovery I just made: While we're at it. My recent experience with Sourceforge is also quite negative. Site is slow, gives irrelevant error messages, says you're logged in but then asks you to login once you try to do something that requires a login. Apparently I managed to get into a weird state because later things started working as they should. Anyway I tend to try to stay away from such sites because they might eat your source at a whim if they make things one step worse than it already is. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20130928123106.GA27619%40bitwizard.nl. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] multiple image composition for noise reduction
On Thu, Aug 29, 2013 at 09:49:08AM -0300, Carlos Eduardo G. Carvalho (Cartola) wrote: - At the Camera and Lens tab I selected each image separately, starting on the second, and clicked the New Lens buttom. This is important, cause you have moved the camera between shots, so we will have a better result if hugin can be free to set different lens parameters and distortions for each individual image I think this should not be neccessary. He took the shots with ONE lens that has ONE set of distortion parameters. So, my suggestion would be: Try it without this step, and see what happens. Report back your findings. :-) Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20130829130839.GA10190%40bitwizard.nl. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] How to create lens camera data file ( exif )?
On Fri, Aug 09, 2013 at 12:50:54PM -0300, Carlos Eduardo G. Carvalho (Cartola) wrote: 2013/8/8 Incony inc...@incony.org win 7 can only use 3gb of memory even though i have 5 on the pc.. Win 7 64bits can recognize more than 3GB of memory. Are you using the 32bits one? I'm not sure how much is true, but someone who knows more about windows than me (doesn't take much), told me recently that Windows still always has a 32-bit userspace with a 2G max available memory for the application. I argued that windows copied the Linux tactic of doing a 3G/1G split soon after we changed that in Linux. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20130810053113.GC16679%40bitwizard.nl?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Lens calibrating in comparison with JPG-out-of-cam and uncorrected RAW-processing
On Fri, Jul 05, 2013 at 10:51:03AM +0100, Bruno Postle wrote: On 5 Jul 2013 10:43, Gnome Nomad wrote: Maybe new cameras are fancier now, but I'm highly doubtful that any of them can do any correction for lens distortion. Of course, probably someone knows different. Or some camera makers marketing departments are run by lunatics ... My (getting elderly now) lumix lx3 pocket camera does barrel distortion correction in-camera for JPEG files. I've never tried comparing it to RAW output, and clearly this approach wouldn't work for cameras that take generic lenses. The processing in the camera is getting cheaper and cheaper. In the old days you had to buy hardware to get for instance the magnification for the RED, BLUE and GREEN light rays to be the same. Nowadays, you can grab the image, and then just scale the resulting subimages in software on the camera. Much cheaper than expensive lenses. I wouldn't be surprised if barrel correction is also already done in the camera. As is already reported by Bruno as well. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20130705135308.GD15367%40bitwizard.nl. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Can't make a HDR Panoramic for use in Autodesk Maya.
On Thu, Feb 21, 2013 at 10:46:33PM +, Bruno Postle wrote: enblend(2582,0x7fff77508180) malloc: *** error for object 0x7fff773d4570: pointer being freed was not allocated enblend is crashing creating the EXR file, I'm not sure why, maybe someone else using OS X can help? If you ask me that image manipulation library (I forget its name) is STILL having memory problems. Try to blend gigapixel panoramas and you'll hit it on any OS. It might show as black lines, black areas, much-too-dark regions or a crash like above. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- -- 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 --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Thomas please respond (was: [hugin-ptx] Alignment tutorial reworked)
On Mon, Feb 11, 2013 at 11:02:55AM -0800, T. Modes wrote: If you have only one image / image stack the fov can't be correctly fitted. There are not enough information to do it. For different (fixed) fov you can always get the (nearly) same errors. This may work, but it may also create havoc. Normally all images of the stack are shoot with the same fov. So fov should not be fitted. In your special case - which you did not In all cameras that I have adjusting the focus when in macro-mode clearly changes the magnification as well. So in my experience, optimizing v makes sense mentioned in the wiki - you can fit the fov of the second lens. But it may be a good idea to leave the fov of image 0 fixed. ... but as you say you should leave exactly one fov fixed. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- -- 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 --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[hugin-ptx] Re: Is this just a hopeless scene or can adjusting
Hi, I have the impression that the table is the most problematic. i.e. when a bad seam might happen on the floorbords it doesn't matter as much. Maybe it's possible to force hugin to use only one (or a select few) image(s) for the table. I have the impresion that it's using too many different table-shots. Roger. On Wed, Dec 12, 2012 at 10:24:04AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote: You can also post edit with some advanced image editor to correct them but it can take many hours. Some scenes mainly those without many human lines are easier to stitch and less sensible to parallax. The main reason for that is that in fact the parallax errors are there but you cant see them. Nature sky water sand forests and other things can be easily shoot without a tripod head. The shorter distance also increase the problem. Cheers Carlos E G Carvalho (Cartola) http://cartola.org/360 http://www.panoforum.com.br/ 2012/12/12 Matias Tukiainen matias.tukiai...@gmail.com Thanks for the quick response! Since every other scene besides that one seems to have gone just fine without a proper panoramic head, I guess I'll just have to reshoot that scene and maybe move the table a bit closer to the open cupboard or temporarily remove it from the room alltogether. -matias On Wednesday, December 12, 2012 1:33:54 PM UTC+2, markku...@iki.fi wrote: 12.12.2012 13:09, Matias Tukiainen kirjoitti: Here's the scene in question: http://i.imgur.com/nwM8v.jpg It was shot with a Canon 5DMKIII and a 20-35mm lens using the 20mm focal length and just a regular stative head. Is it possible to somehow make the table and the sheets look nice by control point adjustment or should I go and shoot the scene again, perhaps slightly further from the table so lens distortion doesn't affect it so much? -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: enfuse 4.1rc2 random segfaults with openmp compiled
On Sat, Dec 01, 2012 at 11:25:02AM -0800, kevin360 wrote: Chris, Thanks for looking at the log files for me. I've had hardware problems before in other machines, but every time I've ever had those issues then there are multiple programs that will segfault and/or the machine will mysteriously lock-up. Beforfe I posted this thread I ran memtest86 to see if there was something up the memory but it came back ok. Here it's just enfuse 4.1. enfuse 4.0 with openmp compliled in works fine which is why I was thinking it was something in the enfuse code, but maybe it's a change in the code that's working some other lib and exposing a problem there. In the past I've been searching for a bug in enblend. I got mad at the fact that nobody would fix it, so I debugged and fixed it myself. This type of bug, with for instance things like accessing memory outside of the array bounds, or freeing memory just before the last access to that memory is sensitive to the compiler and environment. The one I tracked down happened with one compiler and not with another. But in the end, it was a blatent programming error that simply didn't crash on the other compiler. Anyway, these errors are difficult to track down, as the place where the crash happens is not related to the place where the bug is. It would be too easy if you'd get a crash at: z = x [i]; and found out that i==1000, while the array x runs from 0 to 999. In practise, this namely simply continues with a random value in the z variable. No crash. Then later on, things might turn into a crash, because of the unreasonable value of z (easy), or because the calculated value is placed back into the x array. Now some random memory has been overwritten with a value that doesn't belong there. That might cause a crash much further down the line. Anyway, debugging this remotely with a day or two turnaround is undoable. It takes several tens or hundreds of debugging runs to find such a bug. So a developer with interest in the bug has to have access to a system where it can be reproduced. Roger. I'm running Slackware64 with gcc version 4.7.1. If I download the source code and the build script for the various libraries, compile with -g and link with -g, and then ran enfuse with valgrind, do you think that might help in identifying what library is causing the problem? Kevin On Saturday, December 1, 2012 10:25:11 AM UTC-5, cspiel wrote: Kevin - Am Freitag, 30. November 2012 10:24:16 UTC+1 schrieb kevin360: Also got it to crash using DRD and helgrind, here's the commandline that I used for each: valgrind --tool=drd --read-var-info=yes valgrind --tool=helgrind The log file for each is up at: http://www.bluelavalamp.net/hugin/enfuse-openmp-segfault/ IMHO, the logs only prove that you did not run into a heisenbug. Otherwise, the faults' addresses vary, which again points to trouble outside of Enfuse's code base. As you are the only one who ever reported a problem on Enfuse w/OpenMP and I could not reproduce the error with three different tool chains, I suspect a problem with your setup: compiler - libpthread - lib[g]omp I'd not even dare to exclude your hardware or your OS in conjunction with the three items above. You could change your tools and/or your machine or simply fall back to disabling OpenMP. /Chris -- 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 -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: enfuse 4.1rc2 random segfaults with openmp compiled
On Mon, Nov 26, 2012 at 10:41:33AM -0800, cspiel wrote: to Enfuse in a for-loop at shell level, e.g. for _N in `seq 24`; do enfuse ...; done in your experiments ... and put the output in a distinct logfile each time. add: logfile.$_N at the end of the logfile. Or if you want to see the output in your window as well: | tee logfile.$_N Add 21 somewhere (I'd have to experiment a bit to remember where) to get stderr output to the logfiles as well. Afterwards you can check the logfiles which went bad. On the other hand, programs like enfuse are deterministic. They should yield exactly the same output given the same input. This means that intermittent problems are a hint that your hardware is broken. Read http://www.bitwizard.nl/sig11/ for more info. (I wrote that over a decade ago, but it's still valid.) Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: Hugin: How to build an HDR Panorama from bracketed images?
Guys, when you say 24 bit jpeg almost everybody thinks of this as full color (RGB), 8 bits per channel. What is needed for HDR work, is either a floating point format (about 12 bits per channel, would be sufficient, but 32 bits per channel are normally used in hugin) or a high-bit-count fixed-point format. Something like 16 might get close, but 24 bits per channel. may be more appropriate. JPEG format is not appropriate for non-8-bit-per-channel-data. So Carlos in the workflow that you describe you're truncating a lot of information when you output your intermediate files into the 8-bit jpeg format. So... Carlos, I would suggest that you try saving your intermediate files as tiff, and then find out what options you have to create a 32-bit-per-channel-floating-point intermediate file. Then Hugin can, while stitching, apply proper exposure corrections and things like that. (or are you fixing the exposure bracket for the whole panorama? In that case Hugin's exposure correction should be unneccessary.) Roger. On Mon, Nov 19, 2012 at 08:35:41AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote: Hi, just to clarify, I don't work with 24-bit jpg. I usually shoot in JPG and work with it in 8 bits. But alit_image_stack can deal with tif and you can work with tif all the time. I just put JPG in my example because I use it :) I sometimes have some ghosts in the final result of the enfusion, but I doubt if it would solve using a larger image. I think they happen because of parallax differences. I can clearly see that part of the image is good and another is not, so I think align_image_stack has done it's job. The solution (maybe) would be distort the image before fuse them and maybe hugin does that, I don't know. In fact I have never tried to make the exposure stacks directly into hugin. Maybe I should also give it a try :) And surely the best option of all is to stabilize the camera to shoot, but sometimes it is a little hard to do: http://cartola.org/fotos/_cache/Diversas/Engenhocas/_screen/20111004-mastro.jpg Cheers, Carlos E G Carvalho (Cartola) http://cartola.org/360 http://www.panoforum.com.br/ 2012/11/18 TvE tvoneic...@gmail.com Carlos, thanks for posting your steps. Running align_image_stack from the command line sounds like a nice idea. You could also output the result into the .pto file, I believe. I don't know about pre-fusing each stack into a 24-bit jpg. I would be concerned that you could end up with images that have very different dynamic ranges and that don't blend well into the final pano. E.g. if one stack has sunset-to-dark and the other is all-dark. But maybe enfuse deals with that properly or maybe those scenarios don't fuse well either way... If I have the time I may give the two approaches a spin. Another advantage of not pre-fusing is that align_image_stack sometimes has difficulties, specially when large areas are very dark or blown out in one of the images of the bracket and it's nice to be able to adjust the control points in hugin. Ah. maybe we can collect some more wisdom and then turn this thread into a wiki page. -- 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 -- 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 -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] Turn off cropped images
On Sun, Oct 14, 2012 at 11:19:46PM +0100, Bruno Postle wrote: On Sat 13-Oct-2012 at 02:34 -0700, Frederic Da Vitoria wrote: Basically these Preferences settings only concern the creation of new projects, you change settings for the current project in the Stitcher tab. In this case Stitcher tab - Remapper - Options. I know this thread is 19 months old, but I have a suggestion which seems simple: add a mention in the Preferences/Programs dialog explaining where to change the setting for a pre-existing project. What problems would there be if changing the preferences changed the settings for current project at the same time? I think it's mainly a code neatness question. The preferences are actually new project defaults. Maybe calling it that would already help. I'm guessing that changing the settings for the current project from that panel is not uniform for different settings. So a lot of special code would be needed. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] when to sharpen?
On Tue, Sep 11, 2012 at 09:42:00PM +0100, Bruno Postle wrote: Are these photos sharpened? No, from camera. Not a sony, but a Nikon. You can see this effect by drawing a one pixel line in an image, then remapping it in Hugin, it will become 'fuzzy', but remap it again and it won't get any fuzzier. Real, unsharpened, photos don't have hard edges like this, there is always a transition between two colours - This is nothing to do with the quality of the lens. In theory, when I photograph a vertical divide between a white and a black plane, and the camera is just a few pixels non-horizontal, I should have pixels where the one on the left is entirely focussed on the white plane, and the one on the right is completley focussed on the black plane. In practise, there is lens fuzzyness, but you say that has nothing to do with it. In practise, to combat aliasing, there is a fuzzy-filter in front of the sensor. This makes the bayer pattern work in difficult situations. In this case, it will cause some black to leak to the left pixel and some white to the right pixel. So in this case, TWO pixels end up not being completely white or completely black. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] when to sharpen?
On Tue, Sep 11, 2012 at 04:09:50AM -0400, Bruno Postle wrote: Sharpening doesn't survive remapping very well, so you should apply it to Right! It looks to me that the remapping takes the average of two surrounding pixels, on average. i.e. with an image that COULD map 1 to 1, every source pixel will still be smeared out over two destination pixels minimum. (or the other way around: every destination pixel is the average of two source pixels). If my math intuition is good, the -0.5 2 -0.5 convolution is the inverse of 0,1,1,0. Such a convolution might be possible to build into the remapping operation to keep the images as sharp as the original. The core of the problem is that you want to prevent aliasing effects. It is quite possible that 50 source pixels map to 49 destination pixels. This means that at one point (say at 0 and 49 destination pixels) they line up perfectly. While at another (that would be around 25 pixels) each destination pixel is halfway inbetween two source pixels. If you do it the obvious way, you'd just copy pixels 0, 1, 48, 49 to get a sharp image, but near pixels 24 and 25 you'd have to take the average of 24, 25 to get destination pixel 24, and then average 25,26 to get destination pixel 25. This would probably lead to visible artefacts. So there is some smart stuff in there to take a similar average near the point where just copying would be more obvious. I've described things as if they are one-dimensional. Things get a bit more complicated in two dimensions. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] when to sharpen?
On Tue, Sep 11, 2012 at 10:38:55AM +0100, Bruno Postle wrote: On 11 September 2012 10:03, Rogier Wolff rew-googlegro...@bitwizard.nl wrote: On Tue, Sep 11, 2012 at 04:09:50AM -0400, Bruno Postle wrote: Sharpening doesn't survive remapping very well, so you should apply it to If my math intuition is good, the -0.5 2 -0.5 convolution is the inverse of 0,1,1,0. Such a convolution might be possible to build into the remapping operation to keep the images as sharp as the original. Artificially 'sharpened' images are a special case, you don't find this kind of data in 'normal' photos, these don't really suffer any loss of focus in the standard remapping used by Hugin. IMHO, when I click optimal size it recommends a size where each source pixel maps to at least one remapped pixel. Bluntly said: If I take three portrait 2500x4000 images and align them next to each other, my optimal size will have a height of 4000 pixels (plus whatever is needed because they don't align perfectly). In this situation, I have the impression I can clearly see that the remapped images are softer, fuzzier than the originals. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: Homebrew panohead (novice approach)
On Fri, Jul 20, 2012 at 10:42:52PM +0200, Thomas Pryds wrote: Den 20/07/2012 22.17 skrev Rogier Wolff rew-googlegro...@bitwizard.nl: But my 18-135 lens has the nodal point almost all the way near the camera when it is in the 135 zoom-position. That balances the camera/lens nicely near the axis. Do you shoot 360×180° panos at 135? That must give a lot of images to stitch - and quite nice resolution, if not downsized? Well, I shot something like 360x40 as a test-shot, and then found out that stitching that with hugin is impossible. :-( The automatic control point detection finds lots of matches between images that don't overlap. And I think I got it to only check overlapping images by scripting something that would output only the image pairs that I know have an overlap. Then I'd have to clean up some of the mismatches. Then the optimization step would start throwing the 20% un-attached images around. In the end the just estimate the yaw-per-column and pitch-per-row from the hardware was the best result I got. And then blending... It crashes hard at 2.2Gpixels. It crashes at 1/4th of that. It works at 1/16th of that. That's not why I'm taking 200+ 8 Mpixel photos. So the project has been shelved again... Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: Homebrew panohead (novice approach)
On Thu, Jul 19, 2012 at 10:46:09PM +0200, Thomas Pryds wrote: Den 19/07/2012 12.15 skrev Gnome Nomad gnomeno...@gmail.com: I don't think you want to say your new panoramic head makes your panoramas much more prone to parallax errors ... I think you mean much LESS prone ... Ah yes, that was obviously what I meant to say. Corrected now. Thank you! It all depends if you make your pano-head capable of turning the camera around the nodal point. Otherwise it will ALWAYS introduce parallax errors. The nodal point of lenses can be very surprising. Most lenses have them near the front of the lens. So with your auto-pano-head, you'll have to support the weight of the camera (I have a DSLR) behind the axis. My panohead is not strong enough to do that. But my 18-135 lens has the nodal point almost all the way near the camera when it is in the 135 zoom-position. That balances the camera/lens nicely near the axis. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] Restarting the make file
On Fri, Jul 13, 2012 at 11:03:40PM +0100, Bruno Postle wrote: Note that the 'prerequisites' for any 'target' can include the photos, the .pto project and any intermediate TIFF files. P.S. I have also tried to edit the mk file directly and delete the steps that have already been completed. I presume this can be made to work, but I'm not succeeding at it yet, as the structure isn't trivial to follow :-) The Makefile syntax is fairly straightforward, but these Makefiles have been generated by software, so they are not so easy to follow. As far as I can see, Hugin writes a makefile that more or less guarantees that all steps will be performed. I think it is not too difficult to do the following: - Extract the parameters that nona will need for image1 from the PTO file and put them in image1_params.pto.tmp - compare image1_params.pto.tmp and image1_params.pto and if they are the same delete image1_params.pto.tmp. If they differ, move image1_params.pto.tmp to image1_params.pto . Now, when you tell make that the remapped image of image1 depends on image1_params.pto, make will be able to do what it's good at and rebuild only what is necessary. Yesterday I adjusted ONLY the exposure of two images out of ten, and the stitch again resulted in all images being remapped. Not necessary! Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] multiblend 0.4 released
On Wed, May 09, 2012 at 06:00:54PM +0200, Rogier Wolff wrote: I just started writing that it failed. Somehow, it failed similar to the older version while loading the first image. I then tested just blending two images, and that worked. Next I tested blending 6 images, and that workt too! I noticed in the results that my preparations had not been good, so now my PC is running nona again I don't know what went wrong: I can't reproduce it. Good news, bad news. The bad news: It crashes again. The good news: I know what triggers it. It's the images that wrap around the 0/360 degree mark that cause the troubles. David, would the algorithm in multiblend lend itself to a priority scheme? In my current panorama that I'm stitching, I have take 15 portrait shots for the 360 degree background at 18mm focal length. Clouds, some houses closeby etc etc. But then I shot the interesting parts at 135mm focal length. About 23 more images. So now I have 38 images. Most of the 1.2G pixels are interpolated from the low-res 18mm shots. However, when we get to the tele-lens photos we get interesting parts that should override the lowres images. Currently I manually cut out a mask for the parts that I know I've shot in highres. Apparently I'm not good at this because I still get: WARNING: some images completely overlapped WARNING: some image areas have been arbitrarily assigned So my question: could some priority be given to the highres images? Anyway, after loading all images that do not overlap the 0/360 boundary I still get: And then after blending... I still get: Program received signal SIGSEGV, Segmentation fault. 0x7710ac50 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) where #0 0x7710ac50 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00409a81 in mask_into_output (input=0x63d440, mask=0x5c80410, output=optimized out, first=optimized out) at /usr/include/x86_64-linux-gnu/bits/string3.h:85 #2 0x0040a73d in blend () at blending.cpp:766 #3 0x0040c195 in go (argv=optimized out, input_args=optimized out) at go.cpp:74 #4 0x00401c87 in main (argc=38, argv=0x7fffe038) at multiblend.cpp:184 (gdb) whereas when I give it an image that overlaps 0/360 I get it while loading that image: loading p7837.tif... Program received signal SIGSEGV, Segmentation fault. 0x77b9fe16 in ?? () from /usr/lib/x86_64-linux-gnu/libtiff.so.4 (gdb) where #0 0x77b9fe16 in ?? () from /usr/lib/x86_64-linux-gnu/libtiff.so.4 #1 0x77bae3e9 in TIFFReadEncodedStrip () from /usr/lib/x86_64-linux-gnu/libtiff.so.4 #2 0x00404e3f in load_image (image=0x610960) at loadimages.cpp:964 #3 0x00405237 in load_images (argv=0x7fffe340, argc=1) at loadimages.cpp:1029 #4 0x0040be80 in go (argv=0x7fffe340, input_args=1) at go.cpp:18 #5 0x00401c87 in main (argc=4, argv=0x7fffe328) at multiblend.cpp:184 (gdb) This is not due to out of memory or something like that. Strace shows: mmap(NULL, 363035874, PROT_READ, MAP_SHARED, 4, 0) = 0x7f54fbb1d000 mmap(NULL, 602636288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f54d7c65000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Segmentation fault It mmaps the 300M input file (fd=4), then mallocs (using mmap again), 600Mb of image data. and then crashes. Hmm. Could it be that it's calculating the memory to alloc in an int and then allocing 600M instead of 4G+600M? Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] merge enblend and multiblend code?
Hi, On Thu, Apr 26, 2012 at 08:22:44PM -0700, kevin360 wrote: Has there been any consideration to merging the enblend code and the multiblend code together? This could either be to actually take the code for multiblend and put into enblend and it's selected by a commandline switch, or enblend could have a commandline switch that would cause it to just call multiblend and pass multiblend the commandline arguments enblend was called with. This would make it easy to select between the two, just by passing a commandline switch to enblend. If you want this, you could make a small script that either calls enblend or multiblend based on the presence (or not) of a command-line switch. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: New Leopard and newer, intel only Hugin bundle: hugin-mac-2011.5.0.5758_63173b3a4a4b
On Sat, Apr 21, 2012 at 02:46:32PM +0200, Harry van der Wolf wrote: To be honest: I didn't know about the jpeg (IJG) and old-jpeg, but reading that error it was the first thing I checked. When I started with Hugin on OSX we were at jpeg6b from the IJG group and I'm still using that library, now at version 8d. All binaries and libraries are compiled against the same libtiff (and jpeg and png for that matter), thereby using the same header files from the same include path. I checked that with a.o. otool -L ... and especially checked for files being slipped in from my macports: none at all. My libtiff is compiled with both old-jpeg and jpeg support. If you have more suggestions on what went wrong, please let me know. The big test is, can YOU run with LZW compression? (I expect: yes) If so, that is a strong hint that george is not using the same library binary as you are. This could mean that on your system you are not using the tiff library you just built and include in the package, or the other way around, on george's system the hugin tools are not using the packaged libraries but the system ones. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: New Leopard and newer, intel only Hugin bundle: hugin-mac-2011.5.0.5758_63173b3a4a4b
On Sat, Apr 21, 2012 at 09:00:16AM +0200, Harry van der Wolf wrote: enfuse: error: OJPEG encoding not supported; use new-style JPEG The weird thing is that it mentions that it encounters a wrong jpeg compression in a tiff file. - Tiffs don't use jpeg compression (wrong enfuse error?) Tiff don't use JPG compression? Where did you get that idea??? Tiff is a file format that allows a sequence of tagged blobs (blob= bunch of binary data). Usually one is an Image blob, and the compression mode can be specified. Several compression methods are available, like none, lzw, rle and jpeg. Anyway it isn't complaining about jpeg compression in the tiff file. You get this message when you're running the wrong headers in combination with the wrong library. The program tries to specify COMPRESSION_LZW which was defined as #define COMPRESSION_LZW 4 in one version of the library, but the new version has: #define COMPRESSION_OJPEG 4 in the header. So the library interprets the passed value wrong. (I made up the symbols and values in the above example, but it's something like that.) Anyway, the program is /using/ a different TIFF library from the headers it was compiled against. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] morph-to-fit and Hugin with ptomorph
On Thu, Apr 19, 2012 at 09:36:18PM +0100, Bruno Postle wrote: doesn't work on Windows. I'd like to hear some feedback, do you think something like this would be useful in Hugin? Is there a better approach than forcing _all_ the control points to fit? Yes, I think this is useful. The drawback of forcing ALL points to fit is that you force all control points to be perfect: If there happens to be a rogue control point in there, this will have a huge influence on the result. Also there might be unfixable parallax errors. One photo might have much more between two images. Consider 1 a b c d 2 3e4 The 1, 2, 3 and 4 are control points. 1-3 are a vertical line. 2-4 too. And 1-a-b-c-d-2 are evenly spaced, as are 3-e-4 on a different picture. On the other hand, you seem to be getting pretty good results in practise. I guess practise trumps theoretical drawbacks.. :-) Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: Linefind doesn't work on 16-bit TIFF?
On Tue, Mar 06, 2012 at 09:33:36AM -0800, T. Modes wrote: Should be fixed in rev. 882a596cd691 @Roger Linefind does as first step find straight lines (like calibrate_lens_gui). Then it selects (depending on roll value) all lines with small deviation from the vertical. From these lines it selects the best n lines weighting errors and length. I have a gigapan setup. Part of the construction should've been a bit more sturdy, so it is a bit flexible. Most of the camera leans out to the right side. One of the stepper motors in on the right side of theconstruction. So my setup has more weight on the right side and ls a bit too flexible. The result is that the camera leans 1 to 2 degrees to the right. What is small deviation? Does that include the 1-2 degrees? In my test image, it found none of the real vertical lines, but only the leaning pipes and sticks. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: Linefind doesn't work on 16-bit TIFF?
On Tue, Feb 28, 2012 at 11:12:36AM -0800, T. Modes wrote: On 27 Feb., 07:06, Gnome Nomad gnomeno...@gmail.com wrote: Using most recent Hugin found in Debian Sid. If I give linefind 16-bit TIFF, it finds no lines. Give it the same images in JPG format and it finds lines. I did a short test and can't reproduce it. I tested a 16 bit TIFF and 8 bit jpeg. For both image linefind found 5 vertical lines (I tested only one image). Could you provide such a sample image? Can I take the opportunity to ask how linefind works? I took an indoor pano. In view was a cubbord with vertical features. None of these were detected as vertical lines. In view was a pile of straight stuff. Rods of wood, plastic and metal, bunched together none of them vertical, but most of them straight. Those did get detected and classified as vertical. As they were leaning against the wall they might be straight, but not vertical, so I had to remove those control points. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] FOV calculation.
I now have a gigapan setup. I KNOW my camera rotates 7.2 degrees between shots. It might occasionally vary between 7.1 and 7.3, but not much more. Each column overlaps for almost 50% with the previous column. This means that my FOV would be about 14 degrees. However, from the exif info, hugin 2011.4 deduces about 10.2 degrees. I've taken the shots at 135mm, so my rule-of-thumb calculation (divide 1800 by the focal length (*)), comes to 13.3 degrees FOV. That might be about right, but 10.2 is way too small. The relevant Exif info is: ExifTool Version Number : 8.60 File Name : DSC_6025.JPG Camera Model Name : NIKON D80 Focal Length: 135.0 mm Lens: 18-135mm f/3.5-5.6 Focus Distance : 0.47 m Min Focal Length: 18.3 mm Max Focal Length: 134.5 mm Lens ID : AF-S DX Zoom-Nikkor 18-135mm f/3.5-5.6G IF-ED Lens: 18-135mm f/3.5-5.6 G Scale Factor To 35 mm Equivalent: 1.5 Field Of View : 7.3 deg (0.06 m) Focal Length: 135.0 mm (35 mm equivalent: 202.0 mm) Is there a possibility that the exif - FOV calculation is not accurate? (or is the camera misbehaving?) (the FOV in the exif could be the vertical FOV, making the horizontal FOV 4/3*7.3 = 9.7 Hmm. it's not using that!). Roger. (*) That is for Nikon DX sensors. The magic number is 2400 for full frame. Hmm. That can't be right. There should be a factor of 1.5 between the two numbers. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] Telling CPFIND where to look.
Hi, I have a homebuilt gigapan setup... The hugin builtin cpfind is pretty good at finding controlpoints between successive images. However it does not do a good job to find matches between adjacent columns. When I allow it to search for those, it also finds matches between unrelated images and that ends up spoiling the panorama a lot. Deleting bad controlpoints is not directly the way to go because some good controlpoints have a bad distance as well, and some bad controlpoints have very good distance scores. My small test-pano of 4x50 images would also take way too much CPUtime to fully test all 200x200/2 = 2 image pairs. I'll be moving up to 500 images (10x50) today if the weather becomes a bit better. (at about 1 second per pair-to-check that would take half a week) I've added the option to load the pairs-to-check from a file. This works great! I immediately got a nice layout when I used just the controlpoints from the cpfind run that was given the list of matches to try. In my testrun with 34 images that list was 57 pairs long. The list would be 350 pairs long with the 4x50 test-pano that I shot. This is much better than the 2 pairs to check for full-matching and I have the impression that matrixmode tries more pairs than 350 too. Anyway. I've filed the patch in the bug tracking system. https://bugs.launchpad.net/hugin/+bug/936090 The patch needs to be rewritten by someone who is more fluent in C++ than I am. I haven't yet started removing the other algorithms for determining which image pairs to check. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] Telling cpfind where to look.
Hi, I'm making test-shots with my home-made gigapan unit. I have to clean up the control points manually because cpfind sometimes finds matches that are not there, but also because it sometimes doesn't find matches that ARE there. Because I know the shooting order of my pano, I know which images overlap with which others. Just like multiblend now allows you to specify the seamlines in an external program, I would like to be able to load the list-of-images-to-try-to-match into cpfind. Simple ones it should be able to do all by itself. - All pairs - 0-1, 1-2, 2-3, 3-4 ... (n-1 - n). But apparently the multirow option that is already available does not do a really good (enough) job. So, how about we allow cpfind to read a list of potential matches? The advantage is that we separate the what matches to try from the control point finding. This means that in the future for example, after an initial layout optmization, we might find overlaps where there are no controlpoints. So then the hugin gui might be able to fire off a second cpfind run that runs on the found-to-be-overlapping images Or maybe this is already implemented and I should just go and RTFM? Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: iterations of cpfind gives back different number of points (matches)
On Fri, Feb 10, 2012 at 09:04:22AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote: If any of the people affected by the 'bug' have compile capability, they can try and simply seed the rng with, say, 23 and see if the problem persists I'd say: Don't seed the RNG at all. That way, to the program the random number generator will still produce random results, but the random numbers will be the same sequence every time the program is run. (Seeding with 23 works just as well, don't worry). For testing/debugging, it might be useful to add an option that controls the seeding: default: --seed=0 (seed with the value zero or don't seed. These are probably the same). you can seed with a specific value like this: --seed=value or you can seed with the time: --seed=time or with /dev/random: --seed=random Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] Horizontal lines in large panoramas
On Mon, Jan 30, 2012 at 06:21:53PM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote: Is it possible to increase the system swap area (virtual memory) and tell enblend to use more memory? This way you will use your disk managed by the system and enblend will think he has plenty of memory. This trick will work, but it will run out of address space at around 3G of memory required for the process. So even if you have an PAE enabled 32-bit system with 16G RAM and 32G swap, you'll only be able to use 32-bit addressing, which gives you max 3G of adressing space in your userspace process. You could implement userspace swapping to circumvent this problem. That's what the imagecache is and does, but it has a bug or two. If you exceed the bug-limit by a little, you'll get a few artefacts in your image. Mostly black horizontal stripes. If you exceed the bug-limit by a lot you'll crash enblend all the way... I'm guessing there is a dangling pointer in there somewhere. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] Horizontal lines in large panoramas
On Tue, Jan 31, 2012 at 11:05:25AM +0100, Thomas Pryds wrote: I have downloaded and compiled multiblend without problems. I've not yet reached the stage of command-line-stitching, though, but I guess I'll give it a try sometime. I tried changing the enblend executable path in hugin into my path to multiblend, but it seems it's not as easy as that ;-) Tick the checkbox for exposure corrected, LDR under remapped images in the stitcher tab. (deselect exposure corrected, LDR under panorama outputs if you want to avoid the time-consuming enblend step.) Then you'll get images like: mypano1.tif when you hit stitch!. Now type multiblend -o mypano.tif mypano0*.tif simple as that. (this will work as long as you don't have more than 999 images :-) ) Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] Horizontal lines in large panoramas
On Sun, Jan 29, 2012 at 12:23:28PM +0100, Thomas Pryds wrote: Hi When I do large panoramas, I get thin horizontal lines all the way through the panorama. I found this old topic from 2009 which seems to describe the same problem as I experience: http://goo.gl/aNwgB Here's the result of a test stitch I did (don't mind that it's completely unfinished, with holes, bad fittings, etc.): http://goo.gl/LpJZq (app. 15 mb jpg file) For display here, the file was resized to 50% width and height, so it was originally a 24388×12194 TIFF file. As you can see, there is a thin line about half way down; one more nearly two thirds down, and a bunch more about three fourths down. Was a solution to the above problem never found? Or am I doing something wrong? Hi, The problem as far as I can tell is in the imagecache part of enblend. - Disable imagecache (but on 32 bit: limits maximum image size - Switch to 64-bit OS?) - use multiblend. As multiblend seems a lot faster and easier to use and more mathematically correct, more testers of this part are very welcome. Maybe multiblend will become the default in the future. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: multiblend on FreeBSD
On Thu, Jan 05, 2012 at 01:35:50PM +0100, Rogier Wolff wrote: Status update. inwidth=14917 inwidth=14917 inwidth=7459 readmore=1, p=21, readsofar = 22383 inwidth=7459 Even when I abort the loop at p==21, it crashes eventually. OK. Further update It seems that the squish_line function is fine. It is the input to that function that is screwed up. I'm now running with smaller input files, so below is the first iteration with inwidth=2533, while it has iterated a few times before with about double that amount. --- o0-output 2012-01-08 16:44:09.0 +0100 +++ o3-output 2012-01-08 16:43:48.0 +0100 @@ -5047,10109 +5047,10109 @@ 988x1.00 4077x0.00 988x1.00 4077x0.00 988x1.00 4077x0.00 -1161x1.00 0.75 1371x0.00 +1161x-nan 0.937500 0.75 1371x-nan inwidth=2533 As you can see the input masks were neat: 988x1.00 4077x0.00 and suddenly turn ugly: 1161x-nan 0.937500 0.75 1371x-nan (instead of 1161x1.00 0.75 1371x0.00 ) This means that it is the input of the squish_line function that causes squish_line to crash. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: multiblend - a faster alternative to Enblend (Windows only)
On Fri, Jan 06, 2012 at 09:52:29AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote: I have already thought of editing seams graphically, I think I would appreciate such possibility and I think it would be a little better than masks, cause when you do masks there will still be a seam decision after that and you can't preview where it's going to be. Sometimes when I do masks I have to redo them after blending to adjust an unexpected result. Thanks to multiblend it is much faster now :) I personally think that the seam-selection process should be separate from the blender. So... A way to represent the seams has to be found, and multiblend should be able to use a provided seam. As it works now, multiblend can continue to do the seam-selection itself it none is provided. Then a commandline interface for the seams may be defined. So pro-users can define a seam themselves. For mortals a gui-seam-editor may be provided. A commandline option on multiblend should allow it to export the seams it would make. So a gui-seam-editor can ask multiblend for the default seams, present them to the user and then allow the user to change them. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: multiblend on FreeBSD
On Thu, Jan 05, 2012 at 11:15:29PM +0100, Harry van der Wolf wrote: I did some test with a very long panorama of 65500x4950. This caused multiblend to swap out on my 4GB machine (with some other few things in memory). It was still faster than enblend but I think that enblend will be faster then. Simply because it won't swap out. Enblend doesn't get swapped out. That is because enblend does some memory managing itself. It has a memory limit, and when it reaches that limit, it will try to put parts of the images it doesn't need on disk. So Enblend implements the swapping in userspace. You don't have any control over that with your OS tools, and you won't see it with the OS tools that report swapping. Multiblend simply allocates the memory and allows the OS to do the swapping. It's already implemented. Why implement it again? Now, it can be said that the OS does things badly. This can usually be improved by improving your datastructures. As an example When I had my first Linux machine, I made a scan of an image that was 70 Megapixels (7k x 10k). This was a lot back then. The image had to be rotated 90 degrees. pnmrotate -r90 infile.ppm outfile.ppm This started swapping. The main thing that was wrong with this implementation is that to rotate the image it was accessing one of the images (source or destination) in perfect order: line by line. However the other image was accessed one pixel of every line. This results in for every pixel accessed 4096 times more memory being swapped in from disk. I wrote my own rotate 90 degrees program: The image was stored in blocks of 100x100 pixels. so 10k bytes of memory per block (my case was grayscale). Now to rotate the image, a row of the source and a column of blocks of the destination was swapped in. 70 blocks one way 100 blocks the other. So after swapping in 170 blocks of 10k (= 1.7Mb) we could rotate an entire set of 100 lines with the 1.7M working set! With 16Mb in my machine that didn't stop the swapping, but it speeded up the progress by a factor of 100 or something like that. Many large image manipulation programs would benefit from this same trick. With current memory sizes we should use blocks of something like 128x128 or even 256x256. Then we have 64k pixels per block, at 48 bits per pixel that comes to 384kbytes per block. (I'm suggesting 256 as the array-index-split, as that might allow compilers to use byte-instructions to manipulate the index calculations) So an image would be a 4 dimensional array: Pixel_t image [max_x/256][max_y/256][256][256]; and accessing a pixel is done as: image [x/256][y/256][x%256][y%256]; This may seem like a lot of spurious index-calculations, but it pays off once the image doesn't fit into memory anymore. I think the OS swapping can be trusted to swap an image stored this way in a reasonable way. If you're working on the seam on the left, a reasonable amount of memory will be swapped in, and things not touched will be swapped out. If you think the OS swapping cannot be trusted, this datastructure also is good for doing user-level-image-swapping (like enblend). We modify the definition to: typedef Pixel_t [256][256] image_block; typedef **image_block image; Accessing a pixel is still the same, but before each pixel you'll have to ensure_block_is_in_ram (x/256, y/256); If we foresee this last step, we can #define the ensure_block_is_in_ram to nothing and just use the code for the first option. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: multiblend on FreeBSD
Hi,
Status update.
On Wed, Jan 04, 2012 at 05:29:35PM +0100, Harry van der Wolf wrote:
On my (main) Mac OS X 64bit machine a straightforward compilation
with g++ 4.2.1 and optimisation -O3, delivering a 64bit binary,
works fine as well.
I have tried it on ubuntu Natty (gcc-4.4), and found that I can get it
to crash at -O3 level on my test data.
I have confirmation from Carlos that it crashes on his system in
the same function as on mine.
It is around line 100 of maskpyramids.cpp
pixel=input[p++];
by the time it crashes p has the value 120thousand. In a normal run I
normally see p run up to 7 or 8, but never higher. I haven't checked
this, just by hand. OK. checked: It does occasionally go above 10, but
never over 20.
So apparently the loop isn't terminating when it should
Code inspection has learned that (the line before the crash):
while (readmore0) {
could just as well read:
while (1) {
because readmore can never be assigned a value other than 1, 2 or
three.
The exit from the loop will be caused by a break statement in the
loop.
(To be sure: The problem can be inside this function, (compilation or
the code, but it could just as well be somewhere else and that this
crashes because it gets wrong data. )
My debugging code shows it goes weird on the first call with inwidth
!= 14917.
inwidth=14917
inwidth=14917
inwidth=7459
readmore=1, p=21, readsofar = 22383
inwidth=7459
Even when I abort the loop at p==21, it crashes eventually.
Roger.
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
--
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] multiblend on FreeBSD
On Tue, Jan 03, 2012 at 08:09:24PM +0100, Harry van der Wolf wrote: 2012/1/3 Carlos Eduardo G. Carvalho (Cartola) cartol...@gmail.com g++ -D__APPLE__=YES -L/usr/local/lib -I/usr/local/include -msse2 -O2 multiblend.cpp -ltiff -o multiblend crashes ... Try to compile with -O instead of -O2. When cross compiling on OSX I notice that -O2 is too much and I need -O. Either this is a bug in multiblend that happens to show itself only after optimizing, or it is a bug in the optimization step of the compiler. If it is a bug in the compiler, it needs to be eradicated urgently as it might bite us in another project in a less obvious way So: What version of gcc are you both using??? Can you run it under the debugger and provide a backtrace? Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] multiblend on FreeBSD
Hi Harry, On Wed, Jan 04, 2012 at 01:16:57PM +0100, Harry van der Wolf wrote: 2012/1/4 Carlos Eduardo G. Carvalho (Cartola) cartol...@gmail.com gcc version 4.2.1 20070719 [FreeBSD] I don't think it has to do with the compiler but with the data declarations in the program. I'm sorry. I forgot a sentence in my post Either it is something with the compiler, OR there is something wrong in the program. Either the program does something that could crash always (*), but because of compiler-details sometimes works just fine. And in this case the compiler details happen to be -O versus -O2. (*) I.e. according to the language standard the behaviour is undefined. An example is: int *p; p = malloc (sizeof (int)); *p = something (); free (p); y = *p; // Undefined. In practise this piece of code will almost always set a value for y. Depending on implementation details, the value of y might even be the value returned by the something () function. However the behaviour is undefined: The program could segfault. For example, the free function could determine that the page where *p resides is no longer used at all and return it to the operating system. (*) I.e. according to the language standard the behaviour is undefined. For what it's worth. When doing a straight compilation on MacOSX (snow leopard 10.6.8): g++ 4.2 is used and -O2 works fine. So, this will ceate a x86_64 64bit binary which works fine. When crosscompiling, using a massive set of all kind of settings, the x86_64 version is compiled with g++ 4.2 as well. However, as it needs to run on Leopard, Snow Leopard and Lion I use that set of extra settings. For this version when using -O2 it segfaults. -O works. The i386 binary is compiled with g++ 4.0 otherwise it wouldn't run on on Tiger. These segfault also with -O2 and work fine with -O. (note: other binaries which I cross-compile for triple universal x86_64/i386/ppc, the ppc part is also compiled with gcc/g++ 4.0 for the same reason). I've tried to put things in a table http://gaia.bitwizard.nl/wiki/index.php/Multiblend_segfault_problem Is this about correct? Next to that: Versions of enblend before version 4.0 were unstable when cross-compiling with -O3 but worked fine with -O2. Version 4.0 and some development versions before that, worked fine with -O3. Somewhere during the development I tried switching to -O3 and it suddenly worked. I don't have a clue which changeset(s) made this possible. Enblend has always made mistakes that sometimes result in black bands across the result or segfaults. This usually didn't happen on small images but only on larger ones. Again this COULD be a compiler issue, but a coding problem in enblend is more likely. As to your -O3 problems, it could be that the compiler optimizes something that cannot be optimized or it could be an undefined behaviour that exhibits itself only with -O3. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] multiblend on FreeBSD
On Wed, Jan 04, 2012 at 02:31:02PM +0100, Harry van der Wolf wrote: Hi Rogier, 2012/1/4 Rogier Wolff rew-googlegro...@bitwizard.nl I've tried to put things in a table http://gaia.bitwizard.nl/wiki/index.php/Multiblend_segfault_problem Is this about correct? Yes, that's correct. The question marks can be removed from the last table row. You call the target ia32 in the last row, but Apple calls it i386 (and sometimes for compatibility with linux/bsd i686). OK. I've just tested with gcc 4.6.1 and -O2, and I can blend things just fine on x86_64 with it. I will Email you the object file compiled with gcc-4.6 and I'd find it interesting to see if you can finish the compilation from there and wheter it works or not. :-) Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: multiblend on FreeBSD
Hi, On Tue, Jan 03, 2012 at 11:45:21AM -0800, Monkey wrote: -O3 causes a segfault on Linux in the same place - I wonder if it has Not here. I'm using gcc 4.6.1-9ubuntu3. What gcc are you using? You might add your results to: http://gaia.bitwizard.nl/wiki/index.php/Multiblend_segfault_problem Roger. getafix:~/multiblend/multiblend g++ -msse2 -O3 multiblend.cpp -ltiff -o multiblend getafix:~/multiblend/multiblend ./multiblend -o multiblendtest2.tif DSC04288-DSC04295000?.tif multiblend v0.1a (c) 2011 David Horman -- loading DSC04288-DSC04295.tif... loading DSC04288-DSC042950001.tif... loading DSC04288-DSC042950002.tif... loading DSC04288-DSC042950003.tif... loading DSC04288-DSC042950004.tif... loading DSC04288-DSC042950005.tif... loading DSC04288-DSC042950006.tif... loading DSC04288-DSC042950007.tif... 14917x5350, 8bpp, 11 levels seaming... masks... blending... writing... getafix:~/multiblend/multiblend -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: multiblend - a faster alternative to Enblend (Windows only)
On Sat, Dec 31, 2011 at 03:42:35PM +0100, Harry van der Wolf wrote:
I have now also compiled multiblend for i386 and x86_64 for OSX. I don't
think ppc will succeed as sse2 is not supported on ppc.
The code just uses some optimizations that can easily be written out
for other processors.
For example:
__m128i _mm_add_epi16 (__m128i a, __m128i b);
would be something like:
typedef short[8] __m128i;
__m128i add_epi16 (__m128i a, __m128i b)
{
int i;
__m128i t;
for (i=0;i8;i++)
t[i] = a[i] + b[i];
return t;
}
The question is: does the compiler support passing 128bit variables
around like that.
The thing is that sse speeds this kind of operation up a lot. :-)
Hopefully a library that provides these compatibility functions
already exists.
Roger.
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
--
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: Hugin Experience
Bruno, It cannot possibly be the case that I'm right and you're wrong. You know much more about this than I do. So please tell me where my understanding is wrong. On Mon, Nov 21, 2011 at 10:59:46PM +, Bruno Postle wrote: On Mon 21-Nov-2011 at 13:56 -0800, JohnPW wrote: Please clarify this for me as I want to make sure I understand (and it may be helpful to other newer Panorama makers like myself.) These are my assumptions: 1.) Only the actual horizon should be assigned as a horizontal line (unless you just want some line, or the average of some lines, to be straight and at the horizontal center (equator) of the panorama) because the horizon line is the only latitudinal line that lies upon a great circle line (the equator.) Yes, for spherical panoramas. Horizontal lines can also be useful for removing perspective from façades of buildings, but only when you are using rectilinear projection for the output. In that case, they should be called horizon-lines instead of horizontal lines. I thought that horizontal and vertical control points matter to the optimization step. Normally, I thought the control points are all transformed into the spherical coordinates, and for each pair both the longitude and lattitude are compared. In fact the distance is calculated and optimized. I thought that for a horizontal controlpoint pair, the lattitude simply doesn't count. So all that the optimization step cares about is the that they line up horizontally. Similarly for the vertical control lines. There the horizontal position, or longitude is not taken into account. I thought that all this was independent of the projection being used for the final result. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: Hugin Experience
On Tue, Nov 22, 2011 at 11:46:01AM +, Bruno Postle wrote: On 22 Nov 2011 08:15, Rogier Wolff rew-googlegro...@bitwizard.nl wrote: I thought that for a horizontal controlpoint pair, the lattitude simply doesn't count. So all that the optimization step cares about is the that they line up horizontally. Similarly for the vertical control lines. There the horizontal position, or longitude is not taken into account. This is effectively true with equirectangular, or any of the other cylindrical output projections. I thought that all this was independent of the projection being used for the final result. Nope, the horizontal and vertical points are evaluated in the output canvas, so the output projection is critical. This is much simpler conceptually, as far as the optimiser is concerned they are the same thing. Do you mean that the control point matching happens in ouput projection space? i.e. a controlpoint in Image1 at X1, Y1, and in Image 2 at X2,Y2 is transformed using the parameters for Image1 (i.e. roll1, pitch1) to a roll/pitch coordinate pair in the pano-sphere and then onto the output canvas using the output transformation? The same is then done for the X2, Y2, and the difference is optimized. This would mean that for instance a mercator projection that has a distortion near the poles will favor the lattitude of controlpoints near the pole being perfect sacrificing all other overlaps. It would also mean that after changing the output projection, you need to optimize again. A friend shoots all around panoramas. As output projection she needs a projection onto a cube around the pano-sphere. So if I understand things correctly, she will set the output projection to equirectangular, stitch an output image, rotate the viewpoint by 90 degrees and stitch another face of the cube until all 6 faces are done. Now optimization is probably done with the output projection set to one of the faces. Now all control points that lie outside the face of the cube are distorted and optimized in weird ways that do not reflect their role in the final output. Of course something can be said for doing it this way: if there is a minute difference in the projection of the layout of two images near the center of the output image, and the same minute difference in degrees on the panosphere expands to several tens of pixels near the edge of the output image, it might be good to fix that controlpoint near the edge, and tolerate a slightly larger error on the one in the middle. But I would prefer to optimize in panosphere coordinates. Doing it the other way introduces errors based on the assumption that all controlpoints are perfect. They are not. And the lens parameters are not perfect. I think we'd get a much better fit (in a mathematical sense, on the panosphere) if we'd just use the panoshpere coordinates Once we have that, we're ready to optimize lens parameters etc etc, to get the final errors out. And then a list the controlpoints starting with the largest error allows you to find the controlpoints that really have errors in placement. But again... It's entirely possible that I'm misunderstanding how hugin actually works. (I'm reading cooking for geeks and the book has explained one simple thing to me and something I didn't manage before (again and again) worked first time, simply because now I understand the underlying chemistry. Similarly I want to know how hugin works to be able to better control it.) Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] FORK HUGIN
On Mon, Nov 21, 2011 at 04:44:40PM +0100, Harry van der Wolf wrote: 2011/11/21 Robert Krawitz r...@alum.mit.edu On 21/11/11 14:14, mark skama wrote: the program most be freeware but source closed write in c++ and wxwidgets the budget start from 100 € There's another little problem with a closed source fork: the program is licensed under the GPL. To make this a bit more explicit. As Robert mentions: Hugin is GPL which means that all source code parts of Hugin to be used must remain open source. You can only develop a completely closed source package if your truly write your own code which means that reverse engineering is not allowed either (but that's never allowed). A consequence of the GPL part is that you can build your own tool using parts of Hugin, but when requested you are obliged by law to deliver the open source code parts to the requester. You don't need to deliver your own closed source parts to a requester. It goes a bit further than that. If you expand on hugin and link parts of hugin's source code into your program, you are said to make a derivative work. Such a derivative work then completely falls under GPL: you will have to give the WHOLE source code to anybody you've sold (or given) the program to. On the other hand, if you create a separate program that uses (part of) hugin as (a) building block(s), then you might argue that you have not created a derivative work of hugin, and therefore do not have to give your source code to those that ask. A good example is Android. If I buy a Samsung Android phone, I can ask Samsung for the source code. They are obliged to give me the source code to the Linux kernel that they used. Complete with all changes that they made for my specific phone. However they also wrote applications for the phone. Things like calendar. Those are completely separate and if they want they can keep them closed-source. Then they don't have to give me the source code to their calendar program. Roger. (I'm not a lawyer, but I did win in court today :-) ) -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] directions inside the source code needed.
Hi, I need directions finding something inside the source code. I've been grepping and searching for hours I find it annoying that when I cancel the optimization step I cannot apply the currently best results. [update: I might have been testing this in an older version. The problem seems seems fixed now, but I would still like to be able to find things in the source code ] For big panos the optimization step can take minutes to hours, and when you want to see a preliminary layout you don't need those last few micro-optimizations, a general reasonable layout is just fine. So I'm looking for the code that actually does the optimization, I think this is: pano.updateVariables in src/hugin_base/panotools/PanoToolsOptimizerWrapper.cpp (which is called from PTtools::optimize () which is called from void OptimizePanel::runOptimizer(const UIntSet imgs) in src/hugin1/hugin/OptimizePanel.cpp ) Things that normally work is that I grep for strings that are printed during an operation. So for example when the optimizer run finishes normally it asks Apply the changes?, which is a string that comes from OptimizePanel.cpp. However searching for strings that appear in the optimizing progress window (the one that shows cancel) doesn't give me any results. So even tough the problem I was trying to fix is already solved, I'd like to learn how you guys find these things in the source, or in this case specifically where is the code that generates the optimizing progress window? Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: Hugin's website rework (long term project)
On Sat, Sep 03, 2011 at 05:56:24PM -0400, Yuval Levy wrote: On September 1, 2011 04:00:36 AM cri wrote: On Aug 28, 8:58 pm, Yuval Levy goo...@levy.ch wrote: What would it take for Hugin to adopt transifex? It's really simple from a translator's point of view. You just need to create an account and start translating via a web interface. [1] I looked quickly at transifex. It defines itself [3] as designed from the ground up for *dynamic*, *frequently-published* content. This is not a description of the Hugin website. Even with 2-3 releases per year and maybe the addition of 2-3 tutorials per year, Hugin is fairly static. Sometimes a tool that is built to handle more volume than it gets to handle in a situation is perfectly suited for the job. This varies from a insert expensive pro-brand here hand-drill, which is used in a low-volume hobby environment. Works just fine. Similarly the Apache web server is built for high-volume webservers, but works just fine for a small one as well. On the other hand, some tools are NOT suited in the smaller setting. For instance the cadence electronics design suite has such a steep learning curve that it is unusable except for in a professional 40hrs a week setting. So the declaration of the manufacturer that it is able to handle high (change-) volumes does not count as a negative sign in my book. It could mean that it's easy to use, even when lots of changes are involved. So a low time-investment for each single change. This is good for an open source project. It could also mean that for a professional working with it 40hrs a week after some training it becomes low-time-investment for each change. Not useable for our open-source project. In short: Nothing can be deduced from such a simple vendor-declaration. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] CRITICAL: join us to nuke the pesky bug that is plaguing the fast preview
On Tue, Jul 26, 2011 at 12:27:19PM -0400, Yuval Levy wrote: 2) as Hugin has evolved, threads have become more widely used and conflicts more likely. Revision 4524 (2010-11-04 18:31:15) is as far back as I went in my investigations so far looking for the use of threads. This is when the ImageCache was transferred to a separate thread, making the application more responsive. In it alone not a problem, but maybe the introduction of later threaded features introduced the conflicts that are becoming apparent now. There have been longstanding bugs that I suspect come from ImageCache. Crashes, image corruption etc. etc. These are very likely to change character when you move the ImageCache part to a separate thread. They might suddenly happen all the time when before they happened only sometimes. Or the other way around. Or a crash might turn in a corruption, etc etc. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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] 4 GoPro camera street view need help
On Mon, May 23, 2011 at 11:07:14PM -0400, Yuval Levy wrote: On May 23, 2011 04:30:27 PM Bruno Postle wrote: I've often thought that the way to do a camera-on-a-car panorama rig is to space the cameras out in a line instead of trying (and failing) to put them all in the same place. Then when you are driving around you shoot a panorama by firing the shutters in sequence such that each photo is taken from exactly the same location. if you have not done it yet, you should patent this idea ;-) Too late. Publication before patent means no patent. :-) although in practical term it is a challenge to measure speed and synchronize time to trigger each camera's shutter precisely at the right moment. Speed doesn't change too much over short periods. So once you have a speed reading. you can calculate the inter-shutter-times. Then you trigger the cameras at precisely the right moment. Some cameras, especially the ones supporting liveview might have 60 fps framerate, so once you press the shutter, the camera might take the next frame at say 1-17ms after your trigger (i.e. 1 ms constant delay and 0-16ms wait-for-start-of-frame). Humans won't notice the difference, but when driving along at 15m/s, will give a 0.25m spread in triggerspots. I think nikon DSLRs are good at having a deterministic time between trigger and image taken. Swiss (and Russian?) banknotes have small holes in them. (Hold the bill against the light to see them). Making those holes works the same way: the speed is measured, which sets the trigger-speed for each of the holes The result would be zero parallax errors, but there would be new errors with peoples and moving objects. There is enough space to fit six cameras (rather than four) on the roof of a car, which should give enough leeway to generate sufficient overlap to cover for most moving objects. Then the problem is determining the optimal seam lines... You would need some way to synchronise the shutters and the speed of the car, but there are no doubt plenty of ways of doing this. maybe not a timer / spedomeeter then. if a helper vehicle could stand still for the time that the 4-6 cameras pass through the NPP, it could beam a synchronizing laser that would trigger each camera when it is on the right spot. So this helper vehicle would move forward to beam the laser for the next shooting position, stop, wait for all cameras on the camera vehicle to cross the beam, then move on to the next position and repeat. Much too complicated. Google manage do do streetview just because they /only/ had to drive through all streets. Nothing more complicated than that. Sure, there are lots and lots of streets, but if you can just drive through them at 50km/h that's much simpler than stopping and starting for each shot every few meters. If you're prepared to stop for each pano-shoot, you can save yourself 3 or 5 cameras and rotate one camera around for each pano-shot. (with 135-170 degrees FOV, wouldn't 3 cameras suffice?) Just have a sensor on one of the rear wheels. From the time one revolution takes, you know the speed, then you calculate the trigger times and trigger the cameras. Really easy. If you do this just after the sensor triggers, the speed reading will be as fresh as possible. With gopro cameras being 10cm, you can place 4 of them in about 30cm of space along the car. This would mean all four cameras trigger inside a 20ms window at 50km/h. Not much movement is going to happen inside that time. You'll do MUCH MUCH better than streetview with this trick. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: Finding control points for many images
On Thu, May 19, 2011 at 07:26:59PM -0400, Yuval Levy wrote: I don't have a strong preference either way but I do have a slight preference for no automatic matching attempt by default. If there is a switch to activate the extra feature, we can also add a preference to toggle it on by default for those who do not do 360 and do not need this feature activated. Even one false positive is one too many. The cost of computation I don't mind. The cost of user time to undo the false positive I do mind. In some applications a false positive is more troublesome than a false negative. How about: I think that that's Bin Laden, shoot him!. Or an identification system saying: Your biometrics match with Obama, welcome mr president to the military compound. The parameters of such an accesscontrol system can be tuned to make false positives say 100x less likely than false negatives. But in this case false negatives are maybe just as bad. And the user forgetting to tick the box: 360 degree shot would imho result in a false negative. Defaults are meant to be set for the majority of use cases and preferences are the way to satisfy alternatives, not blind brute force (extra computation). Hugin IS a program that invests brute computational force for conveniece. It is a convenience that we find control points, and it is a convenience that hugin optimizes the position of the images based on the control points. So IHMO we should by default check for the wraparound in the images. A configurable option might have a few settings. For example, never, always, ask, based on FOV. Or how about a popup (I hate popups) that says: it seems you've shot a 360 degree pano, correct when a match is detected between the first and last shots. Then ONLY when a false negative is detected does it require user intervention: a response to a popup question. And that FOV setting can be useful too. When a match is found we have a linear transformation that allows us to predict the next point, right? So how about we extrapolate to calculate the left side of the right image, and compute the overlap. Add all FOVs together, subtract the overlaps, and if this comes to say 330 degrees, do the wraparound match... Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: Need some help | Hugin Speed test tab for automated hardware evaluation
On Tue, Apr 19, 2011 at 12:05:46PM -0700, Bart van Andel wrote: On Tuesday, April 19, 2011 6:19:27 PM UTC+2, rew wrote: On Tue, Apr 19, 2011 at 04:49:54AM -0700, Bart van Andel wrote: always makes sense, it does not need a speed test. Tuning algorithms (especially memory intensive ones, where not all data will fit in RAM) for optimal performance and memory usage is a nice aim, but I don't think that's what you propose to do yourself. At least your proposal doesn't mention it. The does not need a speed test part is something I strongly disagree with. Way too many people optimize what they percieve as being a bottleneck and end up optimizing the wrong thing. Sure, I'm not questioning that. You have to find out what can be optimized. Benchmarking may be a tool for that (I'm not saying it's useless), but a thorough understanding of the procedures and algorithms in use is probably even more important. A benchmark can show that part of the program is fast enough or insignificant compared to the rest, then understanding the algorithms of that step is useless. No need to bother. Now specific for hugin. What performance bottlenecks do we expect? == Finding control points. == Finding control points is usually a two-step process. First distinitive points are searched. Next these are matched against the distinctive points in all the other images. Recent updates to Hugin have already helped optimizing this by allowing the user to specify other search strategies (e.g. only adjacent pairs A-B, B-C etc), but I guess you already knew that. Yes. I know. I still think better results can be achieved by following an iterative approach. If I take an 18-position 3-exposure 360-degree HDR pano, images 1-4-7... will have similar exposures and it will be easier to find matches between those. 1-2-3, 4-5-6 ... will be overlapping a lot, but have different exposures. Checking each image just against the next will offer great CPU-time benefits but matching different exposed images is difficult. Especially the 3-4, 6-7 ... matching will be difficult. I would prefer Hugin to figure out this geometry by itself instead of having to specify: I shot left-to-right with three different exposures and 23.5% overlap. - Memory bottleneck? This is a process that requires each image (or even a scaled-down version of the image) in memory to find distinctive points. After that there are just a few (in computer terms) points that need attention, so very little memory requirements afer the images are processed. It requires every image to be processed to find feature points (defined by a descriptor like SIFT, SURF, or what our own cpfind produces). This can be done for each image separately. The second step does the actual matching, keeping only points which are found in (at least) one image pair. The old generatekeys/autopano combo did exactly this. More recent approaches combine this into 1 program, but as far as I know, none of them require all the images to be present in memory at the same time. Note that total memory used != (size of program) + (size of image) + (keypoint datastructure). While processing the image, multiple copies of the same image, at different resolutions (image pyramid), using a few different image processing operators (e.g. derivative, DOG etc) may be required, depending on the feature point extraction algorithm. Yes. But especially when different resolutions are involved, the smaller resolutions are usually not significant. Suppose we scale down a 10Mp image, 2x in each dimension. the result requires only 1/4th of the storage: 2.5Mp. The total for all smaller sizes in a binary scaling sequence is only 33.3% of the storage requirement for the original image. But yes, sometimes 3 or 4 copies of an image are required in memory. With 1Gb memory the minimum nowadays the size of a single image won't cause a machine to run out of memory. It is when things are done badly when memory becomes significant. So on the surface when I say only a single image needs to be in memory at one point in time, you could say that for a 10Mp image this would mean 40Mb. But in reality if you need different resolutions and 3 copies, you might need 160Mb of memory. Still something that a normal computer can handle easily. Things go bad when you try to keep 100 images at full resolution in memory at the same time. - CPU bottleneck? Possible. The old finding matches step was horribly slow for larger stitches. A factor of 10 performance increase can be achieved by searching for matches between adjacent images first, then optimizing the layout and then recheck the matches between images that are now seen to (almost) overlap. As I said before we already have that. May be a candidate for even more optimization, but I think it does quite a nice job already, at least when some information is available, e.g. images are pre-aligned, or the user
Re: [hugin-ptx] Re: Need some help | Hugin Speed test tab for automated hardware evaluation
On Tue, Apr 19, 2011 at 04:49:54AM -0700, Bart van Andel wrote: always makes sense, it does not need a speed test. Tuning algorithms (especially memory intensive ones, where not all data will fit in RAM) for optimal performance and memory usage is a nice aim, but I don't think that's what you propose to do yourself. At least your proposal doesn't mention it. The does not need a speed test part is something I strongly disagree with. Way too many people optimize what they percieve as being a bottleneck and end up optimizing the wrong thing. Example one: DOS 3.11 sort.exe They (apparently) optimized reading the data. They should have optimized the sorting. I rewrote the program with my algorithms text book on my desk. I implemented the text-book qsort algorithm. No optimization. I achieved 10x slower reading of the data, but 10x faster sorting. End result? My version was 5x faster. Example two: Real time medical image processing. It's real-time, so it needs to be fast. Assembly language is the fastest option, so we'll write everything in assembly. Wrong. Nine out of ten steps of the algorithm handle only small amounts of data and execute in less than 10% of the available real-time when implemented in C. The last step of the algorithm uses 400% of real-time when implemented in C. A speedup of 10x was possible by reimplementing in assembly, reducing it to 40% of available time. Putting things together, we had 90% of the algorithm in C and only 10% of the algorithm in assembly. And safe margins to achieve real-time performance in all cases. So... Whereas we can explain the observed results after performing measurements, that doesn't mean we should forget about doing performance analysis altogether. Now specific for hugin. What performance bottlenecks do we expect? == Finding control points. == Finding control points is usually a two-step process. First distinitive points are searched. Next these are matched against the distinctive points in all the other images. - Memory bottleneck? This is a process that requires each image (or even a scaled-down version of the image) in memory to find distinctive points. After that there are just a few (in computer terms) points that need attention, so very little memory requirements afer the images are processed. - CPU bottleneck? Possible. The old finding matches step was horribly slow for larger stitches. A factor of 10 performance increase can be achieved by searching for matches between adjacent images first, then optimizing the layout and then recheck the matches between images that are now seen to (almost) overlap. == optimizing the layout == This is currently implemented as a multi-dimensional upgrade of newton-raphson (it has a name, which I've forgotten). This is very efficient at converging on a solution. Performing benchmarks should show that this is not worth the trouble of optimizing: it already takes little memory and little CPU time. As the algorithm is already much better than simple strategies like hill-climbing, there is probably little to be gained by optimizing this step. == displaying intermediate results == For a user to see what the result is going to look like and if the results are usable, a quick preview of the resulting panorama is neccesary. - memory In theory numimages * numpixels_per_image of pixels are involved. This can be a large number. In practice the display is only on the order of 2 Mpixels. This is a very small number for a computer. A modern computer can easily handle 120Mpixels per second. (60 fps at 2Mpixel). If each of my images is going to show as a 100x100pixel image (10kpixels), it is wasteful to process the 10Mpixel camera image each time. In practise I see huge amounts of memory being used. In theory - CPU In practice hugin is slow in this step. Benchmarks are needed to see where the time goes. I suspect the JPEG decoding, but... Benchmarks needed to verify. Thought needs to be put into these things. If the jpeg decoding ends up being the slow part, we shouldn't simply try to optimize the jpeg routines, but we should also consider not doing the jpg decoding over and over again. That's going to pay out much more! But I'm getting ahead of where I think the benchmarks will lead us. I could be wrong. Facts from benchmarks overrule my guesses. == remapping == Nona. - Memory Input is 10Mpixels. Output is 5-20 mpixels. It should be possible to do with just around (10+20)*4 = 120Mbytes. In reality I suspect much bigger memory use. Benchmark needed. - CPU Input and output refer to around 30 Mpixels total. A througput of 120Mpixels per second was achievable we said before. I think there is room for improvement. (I suspect we see less than 10% of that number) Benchmark needed. == blending == Blending works on the complete output image, which can be several gigapixels. On the other hand it is quite a local operation. - memory Enblend works by loading the images in
Re: [hugin-ptx] Re: Hugin 2010.4.0.854952d82c8f message about not supporting OJPEG?
On Tue, Mar 08, 2011 at 02:36:30PM +0100, Stefan Peter wrote: Am 08.03.2011 10:36, schrieb Gnome Nomad: kfj wrote: On 8 Mrz., 09:54, Henk Tijdink h.tijd...@gmail.com wrote: The same happens on my system (Windows XP) with 2010.4 and 2011 beta 2. Noticed it when fusing a pano, saving it in JPEG. The problem is not in Hugin, but Enblend. Enblend gives that error message, but still works. I see it as a warning from enblend. Enblend doesn't crash. I never save or read JPEG, only TIFF. But I guess TIFF is using some JPEG tech as well? JPEG is a compression method that TIFF can use, but I have mine set to use LZW. I use JPEG for my input photos, I've always used that format. But when enblend is running, it's taking the TIFF files generated by nona and outputting a TIFF file. Bizarre. Nona does issue these messages, too. At least when used under Ubuntu 10.10 as in nona -z LZW -r ldr -m TIFF_m -o test21 -i 15 /tmp/huginpto_yiPXtQ you will get the OJPEGSetupEncode: OJPEG encoding not supported; use new-style JPEG compression instead. I read the situation as follows. OJPEG stands for oldjpeg. When nona specifies TIFF_OPTION_COMPRESS_LZW the library understands TIFF_OPTION_COMPRESS_OJPEG and does TIFF_OPTION_COMPRESS_NONE because some dork changed the header file that defined #define TIFF_OPTION_COMPRESS_LZW 2 #define TIFF_OPTION_COMPRESS_JPG 3 into #define TIFF_OPTION_COMPRESS_OJPG 2 #define TIFF_OPTION_COMPRESS_LZW 3 #define TIFF_OPTION_COMPRESS_JPG 4 or something like that. So that when compiled against the first header file, the library will think the second case... It is a mismatch of the compile-time header that differs from the compile time header that the library used This will work on the developer's workstation because there the versions will match. Library developers should take care not to make such incompatible changes Apparently someone screwed up. Roger. The message seems to stem from recent libtiff versions. See http://trac.imagemagick.org/browser/tiff/trunk/libtiff/tif_ojpeg.c?rev=1 for further information. The source files where jpeg, but I don't think that this matters. It may be more interesting that tiffinfo reported Compression Scheme: None on the resulting tiff output files, although LZW was requested according to the command line. Even the exif information states Uncompressed for the Compression tag. This was further confirmed by using tiffcp -c lzw on the file from above. The resulting output significantly smaller than the source. With kind regards Stefan Peter -- In theory there is no difference between theory and practice. In practice there is. -- 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 -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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] Broken Layout
On Sat, Feb 26, 2011 at 09:04:53AM -0500, Yuval Levy wrote: 1. 800x480 minimum screen size I'd go one bigger (1024x600). We can demand that users have a reasonable screen when working with a graphical application. It should work smoothly at 1024x600, and be usable (i.e. no buttons permanently out of view) at even lower resolutions. (e.g. having to work with a window larger than the screensize and moving the window around counts as unusable) Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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] Broken Layout
On Mon, Feb 28, 2011 at 07:56:19AM -0500, Yuval Levy wrote: We can demand that users have a reasonable screen when working with a graphical application. We can demand plenty of things but we can support more. This is not pixel detailed photo editing. This is not for your gigapixel panoramas. This is stitching. I want a traveler to be able to point a Galaxy S cell phone around a couple of times and stitch a few pics on the spot to share right away via flickr. The more complex work can be saved for later, at home, on dual screen workstations. OK. Different usage model/mode. Agreed, you've got me convinced. It should work smoothly at 1024x600, and be usable (i.e. no buttons permanently out of view) at even lower resolutions. (e.g. having to work with a window larger than the screensize and moving the window around counts as unusable) now you are absolutely inconsistent with your previous statement. Either it works at lower resolutions or it does not. And indeed you are right that moving the window around counts as unusable. Back in 2000 when I had my website designed, I emphasized that it should work on 640x480, but that it should work smoothly on 800x600 and up. That was a workable solution: Some (unimportant) data falls off the side at 640x480, everything is in view at 800x600, and all screen-realestate is used at higher resolutions. That's (IMHO) the proper way to have things. So... If seldomn used options are not visible by default, but reachable by scrolling that makes the application usable, but maybe not smoothly. For the lowest resolutions (at or below the minimum) that's acceptable. So, with your current suggestion that we have a vertically scrolling window if it doesn't fit on the screen: great. But possibly some tabs need just over 800 pixels horizontally. So although the gui design guideline says that it should be frowned upon, we might have a horizontal scrollbar just for the lowest (or below the lowest) resolution. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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] Big list of suggestions
On Sat, Feb 26, 2011 at 07:35:50PM -0500, Yuval Levy wrote: - I would like to be able to move/resize the overall view under the Preview and Layout tabs with the mouse (ie. not with the sliders). Why, if I may ask? And how would you like the mouse to behave? When examining a preview, you would like to have a quick overview look. Then you notice a detail, zoom in on the detail, zoom back out. repeat. You want to be able to leave you hand on the mouse while you look here, there. All this would be preferred if it can be done with big gestures instead of having to exactly click on scrollbars etc. That's the why. Now the how. :-) Most programs have a click-to-drag and a scroll-to-zoom configuration. That'd be nice. One program I often use has middle click to drag and another uses leftclick to drag. Annoying. But both these are easy to find if you leave your hand on your mouse, and can be operated with the eyes on the image instead of on the mousepointer... - I don't know how to adjust the scale of the images in the overview window (they seem too big in my project). There should not be a need to scale the images in the overview window. That's their size, shape, position in relation to the panosphere. If they seem to big, the project is not properly aligned / optimized. I think he's looking for the pano-fov parameters. Try fit or adjust the fov parameters on the stitch tab. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: Fwd: Google Summer of Code 2011 Announced
On Tue, Feb 08, 2011 at 05:58:06PM -0500, Yuval Levy wrote: On February 8, 2011 05:37:06 pm Roger Howard wrote: I was under the impression - maybe just guessing - that PSB support was added without the official Adobe specification. I know ImageMagick added it without - there's no reason IM, Hugin, or GIMP can't add support through a cleanroom implementation - Adobe only controls their spec documents, there's nothing illegal about implementing it without the NDA, you just won't get the docs. Whether by reverse engineering (is that what you mean with cleanroom?) or by following the specs to the letter, one important ingredient is lacking: motivation. Official cleanroom protocol is that one set of engineers looks at the files and draw up a specification. Another set of engineers gets only that specification and implements it. In practise especially in open source there will be one engineer who looks at the files to be imported/exported and tries to mimick that. It helps a lot if he has software available to generate test cases (for import) or to test-load the generated output files (for the export function). Now, when you are in certain jurisdictions, the end user license agreement may be valid when it says: You have the right to have this program on your computer as long as you agree not to reverse engineer any part of it. Without looking I'm confident that Adobe didn't forget that clause. In the EU, such clauses are forbidden by law. Every EU citizen is allowed to reverse engineer or de-compile as long as it is to make a product that provides interoperability. (reverse engineering for example the smoothing algorithm to make the gimp smooth function as nice as in photoshop is still illegal (as in, the EULA can legally ask you to refrain from such activity). There is no interoperability involved here!) Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: Fwd: Google Summer of Code 2011 Announced
On Mon, Jan 31, 2011 at 12:30:28PM -0800, T. Modes wrote: -http://wiki.panotools.org/SoC_2009_idea#hugin_RAW_support Here I don't know. I don't think that hugin should move to support raw formats. On the input side, users should convert images to the appropriate bit-depth tiff files, and use those. On the output side, a camera has a business writing DNG files. It has a sensor with a bayer pattern a specific ADC bit depth etc etc. Hugin can just write TIFF and that should be it. As I understand DNG, hugin would have to come up with a lot of default and controversial data to conform to DNG. Suppose someone didn't fix the camera settings. So the shots were taken with f 5.6 - 11 F-value, and 1/320th to 1/640th shutter time. I'm assuming that those fields are mandatory in DNG. Makes sense for a camera to fill those in. But for Hugin? On the other hand, Hugin might be expanded to allow input-plugins. If we specify that an input-plugin should accept the filename as the first argument and should provide PPM output on its standard out, users can specify say pngtopnm as the input plugin for the PNG format. Simple shell scripts can become wrappers around programs that don't conform to the hugin-input-plugin-api. Input plugins can have a companion application that provides metainfo. Consider using exiftool as the interface spec. (of course 16bit PPM should be supported, as formats may have such bit depths) And on the output side, hugin might be expanded to use EXIF in jpg output formats, and DNG-like-metainfo in TIFF output to specify things that ARE relevant and obviously deducable. For example the time the picture was taken is not completely defined but it can be taken to be the time of the first shot, the last shot, an average over all shots or maybe the median. But it is useful information that should be carried over one way or another from the source images to the destination images. Is BigTiff (tiff 4Gbytes) support - already implemented? - already on the list? - not on the list? - too easy for a SOC project? Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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] JPEG quality preference
On Sun, Jan 30, 2011 at 12:48:30AM -0500, Yuval Levy wrote: Hi all, I just committed code to keep persistent preference of output format, including JPEG quality. For now, the default JPEG quality is 100 - is this OK? or what does the majority of users use? Something can be said to keep the default at 100. I use 95 for my projects although tools like GIMP use a default of 80. 95 already gives a significant amount of saving compared to 100, but I don't see the difference. The same goes for the 95-80 step, but I like to keep some detail even if my eyes are not able to see the difference at default magnification Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: clustered hugin
On Sun, Jan 23, 2011 at 07:29:28AM +0100, Pablo d'Angelo wrote: Am 22.01.2011 12:20, schrieb michael.grant: Unless you do something like this, I can't see how hugin is going to be able to create a pano any greater than the available swap space. How difficult would it be to rework emblend to do something like the above? Enblend can use temporary files (if compiled without OpenMP), and then can process very large images. I'm not entirely sure that the imagecache code is bugfree. There were a lot of bugs reported with crashing and/or image corruption when the image cache code was enabled. IIRC I only got my last large project stitched by having a shitload of RAM and disabling the imagecache Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: New hugin-mac-2010.5.0-4854_d29b1d6da0e0 incl. Thoby projection, new cpfind and gsoc 2010 panorama projection
On Wed, Jan 19, 2011 at 06:46:54PM +0100, Stefan Peter wrote:
This error message has been emitted by gnu make. Now, the error message
itself seems to originate from echo, a small utility you find as
/bin/echo in most unix systems.
Or as a builtin in most shells. As make calls the shell for shell
expansions, it's likely that actually the shell interprets and
executes it (if your /bin/sh is advanced enough to have the echo
command builtin. It's an optional performance enhancement, as
/bin/echo works just as well!)
The error is explained in the write system call manual page:
EBADF fd is not a valid file descriptor or is not open for writing.
So standard output apparently isn't connected anywhere. (but as the
error message DOES come through, the stderr IS!!!)
Inspecting the panoname.pto.mk generated by hugin shows that echo is
used to provide feedback concerning the progress and eventual errors.
When using the Stitch now button in hugin, a window is opened that
will be used to display these messages.
The sole purpose of this echo utility is to display text in a console.
Could it be possible that, probably only this one special version from
mac os 10.5.4 has a problem emitting text not to a physical console, but
a wx console widget (or whatever it is called)?
Some tests may clarify this
o Try to send your project to the batch processor (I hope this
does exist in the mac version of hugin, too). Make sure
you have disabled the Verbose output option
o Open a shell, change to the project directory, and use
make -f projectname.pto.mk
to start the stitching
These are sensible tests. When that works, it is increasingly likely
that the hugin gui program is doing something wrong with setting up
the environment for executing make. I've just spent ten minutes trying
to search for where this happens, but couldn't find it. I expect that
a pipe or dup call is failing. UPDATE: Ok found it by searching
for the pipe call...
It seems to be:
src/hugin_base/makefilelib/test_util.cpp
(which is unlogical because it isn't in any test-code anymore, and I
think this is the actual code used, because I can't find any other
pipe calls.
Anyway, on first inspection I'd say that the code looks good. On
the other hand, code like:
if(dup2(fdmakein[0], 0) == -1 || dup2(fdmakeout[1], 1) == -1 ||
dup2(fdmakeerr[1], 2) == -1) {
std::cerr Failed to switch std stream std::endl;
exit(-1);
}
should be rewritten as:
stdinfd = dup2 (fdmakein[0], 0);
if (stdinfd != 0) {
// can't dup2 stdinfd...
}
...
so that we'll find where things go wrong. On the other hand, the hint
is that nothing DOES go wrong, because already in the original code
the obvious errors should be caught.
Adding some debug code in this file will also help finding the
culprit
(the echo command per-se will probably not be the culprit. The
echo command is something as simple as:
int main (int argc, char **argv)
{
int i;
for (i=0;iargc;i++)
printf (%s%s, i? :, argv[i]);
exit (0);
}
Not much can go wrong there... The echo command is reporting that
there is something wrong with its stdout (1) file descriptor. Possibly
the reader on the pipe has been closed or something. (not likely the
error code should be EPIPE and not EBADF)... )
Roger.
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
--
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: idea for CP deletion
On Sun, Jan 09, 2011 at 09:21:14AM -0500, Yuval Levy wrote: - w: weight (0.0 to 100.0) - default 1.0 I still say: Don't mention an upper limit. Weight: floating point, default 1.0. We currently don't expect negative weights to be useful, but who knows. You can add a remark: currently Yuval thinks values between about 0 and 100 make sense and outside are not really useful, but who knows what may become useful in the future. Do not write unneccesary things into the spec. From your spec someone might implement a parser that reads 1 or two digits, a period followed by one more digit. Or special case 100.0. Now weight 1 is invalid. Should be 1.0 for that parser. We can't specify 1.05. 0.1 and 0.2 are a factor of two apart, and whereas we have a 1/1000 resolution in specifying high weights we only have 0/10 resolution of specifying lower weights. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: 2010.5.0 should be 2011.1.0
On Fri, Jan 07, 2011 at 10:10:38AM -0800, T. Modes wrote: Hi Harry, On 7 Jan., 18:31, Harry van der Wolf hvdw...@gmail.com wrote: Hi, I wanted to build the new Hugin with the thoby projection but did see that we are still at 2010.5. I assume this should be 2011.1.0 or is there a specific reason to keep it on 2010.5.0? I'm not sure. If we bump default branch to 2011.1, then the first release in this year will be 2011.2. Last years first release was 2010.0 Which is bad for consistency, but many people avoid .0 releases because they think it was a major feature-upgrade which still hasn't had all the bugs sorted out. So calling the first release in a year .2 sounds like a good idea to me. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: radial correction
On Thu, Jan 06, 2011 at 04:45:26AM -0800, Bart van Andel wrote: On Thursday, January 6, 2011 5:09:06 AM UTC+1, Tom Sharpless wrote: It has been pointed out that the polynomial should only consist of even numbered powers, both for speed and for mathematical soundness. I'm not convinced there is anything wrong with odd powers in a radial correction function; since R is always = 0 the odd symmetry is never manifested. Isn't there? There is a sharp discontinuity in (the derivative of) any odd-powered polynomial, when mirrored around the Y-axis. Since R can only have positive values, this discontinuity will happen at the image center which is used to compute R from. Therefore, it makes sense to avoid odd powers. Ok. So the function y = x has exponent 1, and is not suitable. There is a sharp corner at x=0, which mathematically manefests itself as a discontinuity of the derivative: dy/dx = 1 where x 0 and = -1 where x 0 (and undefined for x=0) Now the derivative of y = x ^3 is y = 3 x^2 which after mirroring in x=0 becomes dy/dx = 3 x^2 where x 0 and = 3 (-x)^2 where x 0 which simplifies to dy/dx = 3 x^2 for all x. Even if we're talking about even powers, where the simplification doesn't work, the value of the derivative is always zero at x=0, so the derivative won't be discontinuous. So I understand why the first power is bad, but why the third and fifth? (I'm thinking that this is for correcting lens distortions of the form where pixels belonging at r,theta end up at r',theta on the sensor, with r' = f (r), and f (x) = x + and we're talking about the part Correct?) Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: script to scale up pto files
On Sun, Jan 02, 2011 at 09:37:02AM -0500, Yuval Levy wrote:
On December 29, 2010 05:02:30 am kfj wrote:
On 28 Dez., 23:57, Bruno Postle br...@postle.net wrote:
Rogier, whom I asked for his personal script in the initial post,
isn't sharing it and Bruno doesn't scale by arbitrary factors, which
is what I'd like to see.
Sorry. More lack of time to look for it. As you can see it's less
elaborate than the other scripts around.
Roger.
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
--
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
#!/bin/sh
# p f2 w20280 h4506 v108 nTIFF c:NONE
# i w2000 h3008 f0 K0a1 K0b0 K1a1 K1b0 K2a1 K2b0 Va0 Vb0 Vc0 Vd0 Vx0 Vy0 a0
b0.0140421 c0 d0 e0 g0 p3.53802 r-0.586013 t0 v10.4726 y47.5455 u10
ndsc_6109.jpg
# c n0 N1 x145.602 y400.045 X833.379 Y408.262 t0
sed \
-e '/^p / s/ h/ /' -e '/^p / s/ w/ /' \
-e '/^i / s/ h/ /' -e '/^i / s/ w/ /' \
-e '/^c / s/ x/ /ig' -e '/^c / s/ y/ /ig' \
$1 | \
awk '{ h=0;} \
/^p / { print $1, $2, w 2*$3 , h 2*$4 , $5, $6, $7; h=1 } \
/^i / { print $1, w 2*$2, h 2*$3, $4, $5, $6, $7, $8, $9, $10, $11,
$12, $13, $14, $15, $16, $17, $18, $19, $20, $21, $22, $23, $24, $25, $26, $27,
$28, $29; h=1 } \
/^c / { print $1, $2, $3, x 2*$4, y 2*$5, X 2*$6, Y 2*$7, $8;
h=1 } \
{ if (!h) print $0}'
#!/bin/sh
# p f2 w20280 h4506 v108 nTIFF c:NONE
# i w2000 h3008 f0 K0a1 K0b0 K1a1 K1b0 K2a1 K2b0 Va0 Vb0 Vc0 Vd0 Vx0 Vy0 a0
b0.0140421 c0 d0 e0 g0 p3.53802 r-0.586013 t0 v10.4726 y47.5455 u10
ndsc_6109.jpg
# c n0 N1 x145.602 y400.045 X833.379 Y408.262 t0
sed \
-e '/^p / s/ h/ /' -e '/^p / s/ w/ /' \
-e '/^i / s/ h/ /' -e '/^i / s/ w/ /' \
-e '/^c / s/ x/ /ig' -e '/^c / s/ y/ /ig' \
$1 | \
awk '{ h=0;} \
/^p / { print $1, $2, w $3/2 , h 2*$4 , $5, $6, $7; h=1 } \
/^i / { print $1, w $2/2, h $3/2, $4, $5, $6, $7, $8, $9, $10, $11,
$12, $13, $14, $15, $16, $17, $18, $19, $20, $21, $22, $23, $24, $25, $26, $27,
$28, $29, $30, $31, $32, $33; h=1 } \
/^c / { print $1, $2, $3, x $4/2, y $5/2, X $6/2, Y $7/2, $8;
h=1 } \
{ if (!h) print $0}'
Re: [hugin-ptx] Re: idea for CP deletion
On Sun, Jan 02, 2011 at 09:37:00AM -0500, Yuval Levy wrote: More room for scripting experiments. Let me just finish with a remark I've made over and over: if your lens is well calibrated, you really don't need that many CPs. Either you use a set with a great number of CPs to calibrate your lens, or you have a well-calibrated lens and only need the CPs to nudge your images in place. It shouldn't be necessary at all to optimize lens parameters with every pano to 'bend' the images to fit, and if you don't, what do you need so many CPs for? EXACTLY! Every time I see users coming back with thousands of CPs I wonder if this is another meaningless attempt to assemble the largest quantity of boring pixels or if it is an exercise in global warming by CPU strain. Theory is that three strategically placed CPs per image pair are enough when the lens is already calibrated. I work with five CPs per image pair, and for small projects (e.g. full sphericals with six fisheye shots) repeating the left-click-right-click dance on the CP tab is equally fast and yield better results than any CP generator I've tried before. A CP generator becomes useful only when dealing with a large number of input images. But do you find this fulfilling work? Setting aside the fact that you've become convinced that the algorithms of today generate worse results than you, Wouldn't you prefer to have the computer do this boring work for you? You apparently do the pano-with-six-fisheye-images dance regularly. Calibrating the lens and then just using that is much easier. I have a zoomlens. Focal lenght:18-135mm F-stop: f/2.0- f/32 focus: 1.5m - inf So worst case I have to have a 3D matrix of lens calibration settings for two analog and one digital parameter. (one of which doesn't go into the exif data). I think that calibrating the lens on the current project is a reasonable compromise. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: idea for CP deletion
On Sun, Jan 02, 2011 at 09:47:48PM -0500, Yuval Levy wrote: #-hugin cpWeight s0 a0 w100 Hey, do you see a need for an active-weight-zero control point? Do you see a need for an inactive weight-not-zero control point? If you set the weight to zero for control points that are not active, the optimizer just has to add cp-weight * to the line that says toterr += this_distance; How about: negative weights are inactive? Then my suggestion already doesn't work. Maybe then it would even be better from a software engineering standpoint to just do it your way. Why do you thing weight is an integer? When you start algorithmically assigning weights, it would make sense to allow fractional weights. What about setting the weight to 1 by default? Then you can lower the weight by usign values 0-0.99 and increase it by using values above 1. So if you manually tag a controlpoint as being very valid, you can increase it outside the normal range. There are two cases where above-default weights are useful. In the first case, you simply have a very well defined control point. Say a perfectly black 90 degree angle on a white background. That will match up very well with another photo. So you have more confidence in this point than the noisy controlpoints that cpfind found in a perfectly blue sky. A weight of say 2 or 3 may be appropriate here. In the second case, you have some feature that ends up looking crooked(sp?) even if just a few pixels off. So you want that control point to carry more weight than the others. It should be able to pivot around that point, but land the parameters such that it aligns almost perfectly. A weight of 100 might be appropriate here (with my default-is-1.0 scheme). Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: Product Vision (was:An idea to expand HDR)
On Fri, Dec 31, 2010 at 05:20:22PM +, Bruno Postle wrote: I think there is a case for having an expert mode, or rather having a central place where XYZ mosaic and HDR/bracketing/fusion is enabled per project. The confusion where the assistant is placed by the GUI at the same level as the the other tabs has been noted before. A solution suggested by Pablo would be to move the assistant to the preview window, make the preview the 'main' application window and make the everything else secondary - to the extent that only the preview is visible during a normal workflow. This approach is now practical since we got background loading of photos, the question is, do we want it? I think this is very good idea. It makes the application more widely usable for a wider audience, while at the same time allowing deeper access for the more advanced users. It fits in my vision for Hugin, so I'm all for it. But does it fit in yours? Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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] Product Vision (was:An idea to expand HDR)
Hi Yuv, It seems we're pretty much fully in disagreement on this issue... Here is what I would want Hugin to be: WHAT IS HUGIN IN MY OPINION Hugin is a user-friendly open-source solution allowing stitching of multiple photo images into a single output image. From stitching three six-megapixel images together into a wide-FOV panorama to multi-gigapixel HDR panos. Because of a good software engineering design, hugin allows several steps of the workflow to be dispatched to subprograms that can easily be replaced, compared, extended and researched. As a side note: Maybe Hugin has too many controls for the first-time user. But because of reasonable GUI design with an assistant a first time user can achieve results. By watching what the assistant does, and exploring the program, users gain familiarity and understanding allowing them deeper interaction with the program and its features, all the time while still giving positive feedback to the user by allowing him/her to produce goodlooking results. This is completely different from GIMP where i had to spend days studying tutorials before I could change my first pixels... (I think gimp has improved on this front since I struggled with it years ago). Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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] Product Vision (was:An idea to expand HDR)
On Thu, Dec 30, 2010 at 09:37:30AM -0500, Yuval Levy wrote: Hi Rogier, On December 30, 2010 05:12:26 am Rogier Wolff wrote: It seems we're pretty much fully in disagreement on this issue... ... and it is not a problem at all for us to keep working together and collaborating on Hugin. Indeed, no problem. :-) Hugin is a user-friendly open-source solution allowing stitching of multiple photo images into a single output image. From stitching three six-megapixel images together into a wide-FOV panorama to multi-gigapixel HDR panos. Nothing prevents you from branching out any time in the project history and transform Hugin into what you believe fits the above vision. Indeed. well, nothing? The thing that is preventing me from branching is my lack-of-time. Won't happen anytime soon. Because of a good software engineering design, hugin allows several steps of the workflow to be dispatched to subprograms that can easily be replaced, compared, extended and researched. And nothing prevents people interesting in adding features to Hugin to do this. In fact, what you are writing above has just been improved with the new Makefile lib. :-) Good. As a side note: Maybe Hugin has too many controls for the first-time user. But because of reasonable GUI design with an assistant a first time user can achieve results. This is actually inconsistent with the feedback we're getting. Users (and what is even more worrying: not only first-time users) run into optimization problems of all sorts. That's not reasonable GUI design. A reasonable GUI design would prevent that. OK. But consider this. I think the gui is reasonable in that it pops up the assistant and nudges the user to click 1: load images, and this will result in a pano a few clicks further down the road. But among the hundreds or thousands of people for whom it just works, there will always be a few who happen to have the corner-cases that triggers the problems with optimization. Those file bug reports. The people who just stitch their project won't file bug reports. As an example, A friend of mine has a view over the mess here in Delft because they are putting the train underground. http://www.gigapan.org/profiles/25060/ He told me something like: stitching is difficult and I said: no it's not, look! and I showed him. But since then he's managed to shoot and stitch two more panos that I didn't know about until recently! No complaints! Just a silent happy user. Another friend. Also Hugin-user: http://www.iolar.nl/index.php?id=panorama no complaints. She's probably closer to cutting-edge. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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] An idea to expand HDR capabilities in Hugin
On Sun, Dec 26, 2010 at 11:09:00PM +, Bruno Postle wrote: On 26 December 2010 22:51, Rogier Wolff rew-googlegro...@bitwizard.nl wrote: The current integration of cpfind boasted the marketing talk about how good it was to integrate such a program because now it had access to all internal variables of hugin. I think this is a step backwards for hugin. This isn't how it is at all, rather it has gone the other way. cpfind is run as an external process, and this control point generation step is now managed by the same Makefile system as has been used for stitching previously. The interface for communication with cpfind is a temporary .pto file, both for input and output, there is no shared memory going on. Good, good! I value the correctness of hugin over my personal blunder of thinking it was not correct (*). I missed this EMail a few days back. Email overload. Sorry. Roger. (*) Or whatever you'd call that in a software-engineering sort of way. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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: idea for CP deletion
On Wed, Dec 29, 2010 at 07:42:12AM -0500, Yuval Levy wrote: On December 28, 2010 06:29:17 pm Rogier Wolff wrote: Throwing [control points] away (well ok, commenting them out) isn't going to help the pano. there should be a better way to enable/disable CPs selectively... You know what I'd like to do? I'd like to assign weights to the control points. ... and weighting would help in this and many other cases. For example in the past the wish has been expressed to discern between user-generated CPs and computer-generated CPs. Indeed. And a user-preference can set the default weight for both of them. Some users trust themselves, others trust the computer better. :-) instead of commenting out CPs, you would set them to a weight of 0. Right. Or at least very low. Still: I don't think CPs are the ultimate tool for the image alignment process. They are historically grown, because humans would pin down printed photos to each other before digital stitching came along; and when digital stitching came along it was the human user interface to it mimicking the pre- digital interaction and pinning down images to each other by the use of CPs. What I think should be possible is that you optimize the cross correlation of say a 10x10 area of the image with another image. This is computationally expensive. This would only be feasable to do for example for a 5 pixel radius of a point 20 pixels north of a controlpoint. I can't think of how to get an initial point to start working from besides asking the user or doing the feature detection thingy But this is WAY beyond addition of an extra field in the controlpoint structure. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ -- 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
