[hugin-ptx] Newbie trying Hugin on PC
Maybe help is impossible but I want to try: Trying to use Hugin for the Enfuse option. Just want to take a few bracketed images and combine like Photomatix but hopefully with superior final image. Can someone give me or direct me to a brief tutorial on how to 'invoke' (I've seen this term used) the Enfuse option that DOES NOT involve trying to create a panorama? I've looked high and low to no avail. Thanks much, Bob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] better OpenGL 1.x support in pvQt
Hi All, The recent 0.2.34 alpha release of pvQt contains several errors that make it work badly or not at all on systems with limited texture map resources. Please discard it and use the current 0.2.36 release instead. 0.2.36 works fine on my OpenGL version 1.4 machine, which only supports power-of-two texture dimensions; 0.2.34 could not display anything on that system. So I hope it will work on all OGL 1.4+ systems. OGL version 1.4 is the first that has cubic texture mapping as a standard component. It was present as an extension in some version 1.2 and 1.3 implementations, and pvQt could probably show QTVRs on such systems, however at present it aborts if it finds the OGL version less than 1.4. If you are able to build pvQt, please feel free to experiment with removing that limit and let me know what happens. My apologies for publishing a "not-quite-release". There will now be a pause while I work on 0.3, which will have mouse controlled panning and a more robust qtvr parser. Cheers, Tom --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Panorama in flash, which tool?
Hi Guys, is there a chance of building panoramas in flash with a tool like the very good Panotools-Script to get a qtvr? i'm running linux and that's why i would like to use flash. Cheers, Can --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Black (and white) lines in regular (non-HDR) files
I sometimes get horizontal lines in non-HDR files. Sometimes just a single line, sometimes a region with alternating black and 'normal' pixels, looking rather like TV scan lines. The latest image I've seen them in is a big one: I'm doing a 360° panorama, so have 37 16-bit TIFF images as my source images. I manually set the exposure and kept it constant, so there are no exposure differences between adjacent images. It took Hugin (and enblend) nearly ten hours to process them! I'll upload a snapshot of the final output file at "actual pixel" resolution in Photoshop. There were no error message in the scrolling window of messages (at least, none I noticed, just the usual stuff about collapsing pyramids). Any idea what the problem is, or what the workaround 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: newbie introduction - hugin usability
I have to agree with 'newbee' and Dale Beams. Hugin is a great program, and I'm quite used to programs which aren't that user friendly, so for me, it's no problem to use it. However, from a usability perspective, certain things definitely should be changed. I think any program which is intended to be used by a large group of people (like Hugin) should be as intuitive as possible. The comments 'newbee' has given, are really worth investigating. In fact, I think he/she tackles the problem quite well. Unfortunately I don't have the time nor the skills (in terms of C++) at the moment (yet) to implement it, but it might really help putting Hugin on the map a lot better. Maybe it doesn't have the highest priority, but in the end, it should be dealt with anyway, so I think we should really welcome such helpful comments on how the Hugin process works. Best, Bart --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: newbie introduction - hugin usability
Hello, "Newbie" is a good friend who has an interest to see how making panoramic images works. We had an hour in the evening, and so I just wanted to show the workflow with one hands-on example. Regarding hugin, there was a consensus that a feature freeze is needed to get 0.7.0 released without more delays. Aspects of GUI and usability have been discussed before, as were further features, but deliberately put on hold in the last few months. Now that 0.7.0 is out, one may resume there. Of course implementation of SOC 2008 work is already underway, so these things may come first. But I expect usability and GUI discussions to start again. And as I consider myself a reasonably expert hugin user, it is interesting to observe someone with no prior experience and using a completely fresh installation. Cheers Klaus --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin-0.7.0 released
Harry, Sorry I am even later spotting your reply than you were in replying to my original message. I am just back from a trip and doing a check on here for things that might have been posted while I was away and I noticed it. Yes. The as the pop-up with the error message is not selectable/Copy- paste-able I (mis-)typed it in. So I guess that should have been "Hugin" and NOT "Hiugin" and "Autopano-SIFT" NOT "Autopano=SIFT" I was going to suggest that making the text of all pop-ups with errors "selectable" would make debugging easier! all the best George On Oct 13, 5:51 pm, "Harry van der Wolf" <[EMAIL PROTECTED]> wrote: > Hi George, > > Sorry for replying this late. I hoped Ippei would pick it up and than I > forgot about it. > > This final error you mention is most probably a "non-fatal" error by > Exiftool. > I reported on 6 October: > *"I just built the final 0.7.0 but I receive a "non-fatal" exiftool error in > the end (maker notes not recognised) for some sets of images. for other sets > it works OK even though none of the sets do contain maker notes (beats me). > I will investigate that one before release. As it is a "non-fatal" error > (exif-info for generated image not updated) I might still release it if I > can't solve it (which I probably can't)"* > > I suppose that if you look at the error a bit more in detail (the window > stays open anyway), that it might be the same or one alike for Exiftool. > > I have been experimenting with sips lately (for my ImageFuser). sips is the > comand line version of "Image Events" on Apple. It can do 90% of what > Exiftool can and is standard available on every Mac (>10.2). > > Just like Tom Sharpless mentions: it might be wise to get rid of Exiftool, > even though as such it is a great cross-platform tool. > > Getting back to your Autpano-sift-C issue: > The command line mentions: /.../Application Support/Hiugin/Autopano=SIFT-C > 2.5.huginAutoCP/Contents/macOS/autopano-sift-c --maxmatches 3 > > It says: "port/Hiugin/Auto" <-- Hiugin??? > It also says: "ano=SIFT" <-- Did you copy&paste this or did you type it > over? > and also says: "--maxmatches 3" <-- maxmatches is not given to the plugin, > so it should stick to the default which is 25. This is another weird issue. > > I can't find the "Hiugin" in my source code. > (This is also why I hoped Ippei would react). > > Harry > > 2008/10/8 grow <[EMAIL PROTECTED]> > > > > > PS having generated control points with an earlier version of Hugin I > > was able to save the project file and then open it in the current, > > released version. It then performed a stitch as expected producing a > > resulting file that I was happy with.However ... it ended the > > stitching process with a pop-up that said: > > > Error during Stitching > >Error during Stitching > > Please report the complere text to the bug tracker on > >http://sf.net/projects/hugin. > > > all the best > > > George > > > On Oct 8, 3:06 pm, grow <[EMAIL PROTECTED]> wrote: > > > Ippei, Harry, > > > > I have just tried Ippei's new release. > > > > I installed it on my PowerMac G5 machine. > > > I also installed your new Autopano-SIFT-C plug-in replacing the > > > previous one in "Application Support" > > > > I opened a recent project and tried using Autopano-SIFT-C to generate > > > a few control points ... the plugin selection dialogue was as expected > > > and then the running commentary seemed to go as usual but at the end > > > a pop-up appeared saying: > > > weExecute Error > > > Could not execute command /.../Application Support/Hiugin/ > > > Autopano=SIFT-C 2.5.huginAutoCP/Contents/macOS/autopano-sift-c -- > > > maxmatches 3 /private/var/tmp/folders.501/TemporaryItems/ap_resJOqSkP / > > > private/var/tmp/folders.501/TemporaryItems/ap_inprojrLDkvr > > > > I tried the same task in the same project using an older version > > > (SVN-3390) and - even with the new Autopano-SIFT plug-in still in > > > place - it ran normally and generated the control points as > > > requested. > > > > I am not sure whether this tells you anything you didn't already know. > > > > all the best > > > > George > > > > On Oct 7, 3:22 am, Ippei UKAI <[EMAIL PROTECTED]> wrote: > > > > > On 2008-10-06, at 23:42, Harry van der Wolf wrote: > > > > > > Ippei, > > > > > > for the RC6 George Row mentioned: > > > > > > >However each time there has been an error message at the end saying > > > > > >that "There has been a stitching error - please report the whole > > > > > >text" (at least I THINK that is what it said I have sent it away > > now. > > > > > > >I have the text in case it is needed ... but I suspect that there > > has > > > > > >NOT been an error really and that the pop-up is a false alarm. > > > > > > I got the non-fatal error for the exif-tool as mentioned in this > > > > > thread. I think George got the same error. Shouldn't we investigate > > > > > that one before putting a binary up? One day more or less doesn't > > > > > matter and I prefer to put
[hugin-ptx] Re: newbie introduction - hugin usability
I agree with "newbie" or commonly known as "usablity" testing. Suse had made great inroads in this area with some strong usablity testing procedures. Suse even went so far as to video tape all types of users on Linux to understand user expectations. Gimp's crop window iirc, was a result of some "usablity" adjustments, and is by far one of the best "cropping" tools out there. I often find programmers or "experts" looking in disdain on users sometimes. It is the "users that make or break a program in the software world sometimes. MS did not make it as far as they did simply on advertising. They used to make and still work toward making an effort to solve usability issues. I was glad to see this post, and disheartened to see RTFM posts. Usability suggestions don't hurt they help, and I hate to hear "RTFM" all the time. I myself have considered usability suggestions but have been at the wrath of a group of programmers or experts on more than one occasion that I've quit giving usability suggestions. Recently I was in some of the local large mart stores and noticed how affordable software has become. When faced with "free" OSS and a program that is 35.00 it becomes real clear after using a OSS program with usability issues where one's time and money is better spent. IMHO, OSS isn't loosing out because of patent wars, or FUD, or any other conspiracy. In the end it looses out because of usability issues that programmers don't care to fix, even though sometimes those changes are very simple. I enjoy Hugin, and it is my primary photo stitching application. I'll continue to use it as I do believe that by doing so I'm promoting OSS in my area and hopefully usability suggestions by members will improve the application. > Date: Mon, 27 Oct 2008 02:37:20 -0700 > Subject: [hugin-ptx] newbie introduction - hugin usability > From: [EMAIL PROTECTED] > To: hugin-ptx@googlegroups.com > > > Hello, > > Yesterday evening: newbie introduction to hugin and panorama > stitching. Some remarks on usabililty while watching and tutoring a > first three-image stitch. > > Downloading from hugin.sf.net works ok. Installing hugin on XP with > the exe file works ok, but then there are suddenly lots of aliases on > the desktop. Newbie is somewhat confused. > > Open Images tab. Drag and drop images into white area. Tell newbie to > click on an image name to ascertain that image is loaded indeed. > Methinks that the last image(s) dropped into the window could be > highlighted by default and displayed in the preview. > > Then skipping a couple of tabs going to Control Points. Concept is > easily explained to newbie. Explicit hint needed to set right image to > number 1, as current default is to display image 0 twice. Newbie > roughly clicks on the image, zoom in happens and the desired spot is > obscured by the magnified square. Also newbie tries to click into that > square to adjust positioning. Need to tell to manipulate the faintly > visible crosshair. Mesays that the doughnuts would have been more > intuitive, but thinking about a click and hold (real magifying glass > pops up), drag (fine positioning), release (place CP) workflow. > > Usually only one magified square is visible, hence no hint whether > placement was ok. Methinks two squares should be visible, one may > disappear when cursor is moved. > > Optimising is fine for a start. But need to point out the drop-down > menu with the different optimisation strategies. Maybe that could be > done less hidden. Mesays that I usually optimise several times, adding > more parameters at each step. > > Preview is accessible from the menu. The icons are not yet intuitive > to the newbie. The preview window comes up rather small at the start, > of course a once-only problem. Irritating is also pressing the align > buttons and nothing happens. Of course the default is that the > automatic preview redrawing is switched of by default. If that new > fast preview were not in the pipeline, methinks change would be > needed. > > One CP was placed badly, numbered 8 in the F3 window. Where is number > 8 in the CP tab? There it is numbered 3. > > The F3 control points window is much too small at the start. > Maximising, then much too large. Awkwardly floating at the top. > Methinks F3 should toggle it. If you want to have it in front, press > F3 twice. > > Changing back from the preview window to the main window is not > smooth. Recommendation to newbie was to close the preview window. > > Exposure tab works ok. Popup window is slighly irritating. > > Mecomments on Optimisation and Exposure: maybe we should be doing away > with the popup windows (displaying the values in the main window), and > if one does not like the latest optimisation result, rely on ^Z or > "undo" in the menu for the step back. > > Vertical control points not yet introduced to newbie. > > Slider control and clicking in preview window briefl
[hugin-ptx] Re: pvQt version 0.2 released
Hi Tom, w.r.t. the Makefile not being created: On OSX when I do a qmake --help, it says the following: Mode: -project Put qmake into project file generation mode In this mode qmake interprets files as files to be built, defaults to *.c; *.ui; *.y; *.l; *.ts; *.xlf; *.qrc; *.h; *.hpp; *.hh; *.hxx; *.H;*.cpp; *.cc; *.cxx; *.C -makefile Put qmake into makefile generation mode (default) In this mode qmake interprets files as project files to be processed, if skipped qmake will try to find a project file in your current working directory Options: * You can place any variable assignment in options and it will be * * processed as if it was in [files]. These assignments will be parsed * * before [files]. * -o fileWrite output to file -unix Run in unix mode -win32 Run in win32 mode -macx Run in Mac OS X mode However, also when using "qmake -makefile -macx pvQT.pro" or "qmake -makefile -unix pvQT.pro" I don't get a Makefile. I suppose it is a bug in qmake 4.4.1 (?). (Even though the --help says it defaults to makefile, bit sloppy in their cross-platform texts) So OSX developers/builders need to use the Xcode project (something for in your pvQt-build.txt), which is not a problem at all, but deviates from the standard makefile. For the time being I wait for your new 0.2.35 version. Harry 2008/10/27 Tom Sharpless <[EMAIL PROTECTED]> > > PS the proper typename is "GLint" for singed, "GLuint" for unsigned, > not "glInt" > > On Oct 27, 10:38 am, Tom Sharpless <[EMAIL PROTECTED]> wrote: > > Hi Harry > > > > Yes, this is a confusing bit. In fact if you just run the qmake > > command again, it works, because the first run creates the build > > directory -- but not until after the lines that failed. So an even > > easier fix is to move those lines to the bottom of the .pro file. > > > > On Oct 27, 7:28 am, "Harry van der Wolf" <[EMAIL PROTECTED]> wrote: > > > > > Hi Tom, > > > > > w.r.t. the error when I run the "qmake pvQt.pro": > > > > > build/pvQtVersion.h: No such file or directory > > > > > It does that when I have a "fresh" pvQt-0.2.34-src directory and when I > run > > > it for the first time. The first time the directory does not contain a > build > > > directory. Therefore the script can't copy the pvQtVersion.h into this > build > > > directory. I made a quick patch for the pvQT.pro file, but only for the > non > > > windows side of it (does it work on windows?). > > > You can find the diff attached. > > > > > Harry > > > > > 2008/10/26 Harry van der Wolf <[EMAIL PROTECTED]> > > > > > > Hi Tom, > > > > > > > It does not fail on the pvQtVersion.h. It does this in the second > build > > > >> when > > > >> > I "clean" my target before building. It also removes the > pvQtVersion.h. > > > >> This > > > >> > is my fault. > > > > > >> pvQtVersion.h is not removed by "clean" on my Windows and ubuntu > > > >> system. > > > > > > Sorry I was not specific enough. I said "when I "clean" my ..". If I > do it > > > > via the Xcode IDE it remains where it is. Most of the times when > things are > > > > not working as expected I just remove the entire build directory (rm > -rf > > > > build). > > > > > >> > If I compile in Xcode on Leopard 10.5 with "default universal" > settings > > > >> it > > > >> > compiles fine. > > > > > >> > On the other hand: when compiling in Xcode (on Leopard 10.5) with > > > >> deployment > > > >> > target 10.4 (Tiger) it does say: > > > >> > /Users/Shared/development/pvqt/src/pvQtView.cpp:609: error: > invalid > > > >> > conversion from 'int*' to 'GLint*' > > > >> > /Users/Shared/development/pvqt/src/pvQtView.cpp:609: error: > > > >> initializing > > > >> > argument 4 of 'void glGetTexLevelParameteriv(GLenum, GLint, > GLenum, > > > >> GLint*)' > > > > > >> I guess GLint is not identical to int on your OpenGL -- please add > > > >> casts and try again. > > > > > > It has to do with the OpenGl version it has to be compiled against: > on > > > > Tiger (10.4.x) it is 1.4.x. On Leopard (10.5.x) it is 1.5.x. When I > compile > > > > the default way, e.g. OpenGl 1.5 on Leopard, it works. When I > cross-compile > > > > downward compatible, e.g. for OSX 10.4 (and up) on 10.5 I do get the > error. > > > > I attached the gl.h from Tiger and Leopard to the mail. On Tiger > Glint is a > > > > long, on Leopard it is an int. > > > > > > I connected my USB drive with Tiger to my macbook and rebooted and > tried to > > > > build it. The error on Tiger is exactly the same as on Leopard when > > > > compiling for Tiger and up (which is obvious but better safe than > sorry). > > > > > > You mention "please add casts and try again." I googled a bit but I'm > still > > > > lost. > > > > So: Tell me how master, and your obedient servant will try ;-) > > > > > > (Another option might be to test for the MacOSX version. > > >
[hugin-ptx] exiv2 / olympus
Here are the details of what exiv2 "sees" on the images from the Olympus C-765UZ. Can any of the developers shed some light on what tag is hugin keying off? Yuv Robin Mills wrote: > Delighted to hear that Hugin links with exiv2-0.18pre. Very good > news. > > I ran your image on exiv2 (same result on 0.17.1 and 0.18pre). (Full > result from 0.18pre on Windows below) > > 588 /Users/rmills/Documents> exiv2 -V > exiv2 0.17.1 > > 589 /Users/rmills/Documents> exiv2 -pt Olympus.jpg | grep -i focal > Exif.Photo.FocalLength Rational1 6.8 mm > Exif.Olympus.FocalPlaneDiagonal Rational1 7162/1000 > > Are you keying off 'Exiv.Photo.FocalLength' ? - or a different tag? > > I ran the image on exiftool (Perl) > 590 /Users/rmills/Documents> exiftool Olympus.jpg | grep -i focal > Focal Length: 6.8mm > Focal Plane Diagonal: 7.162 mm > Focal Length: 6.8mm (35mm equivalent: 41.1mm) > Hyperfocal Distance : 2.32 m > 591 /Users/rmills/Documents> > > Curious how it reports focal length. Andreas will probably want to > comment further. > > Robin > > > Exif.Image.ImageDescription Ascii 32 OLYMPUS > DIGITAL CAMERA > Exif.Image.Make Ascii 20 OLYMPUS > CORPORATION > Exif.Image.Model Ascii 7 C765UZ > Exif.Image.Orientation Short 1 top, left > Exif.Image.XResolution Rational1 72 > Exif.Image.YResolution Rational1 72 > Exif.Image.ResolutionUnitShort 1 inch > Exif.Image.Software Ascii 8 v777-79 > Exif.Image.DateTime Ascii 20 2008:09:28 > 14:31:41 > Exif.Image.YCbCrPositioning Short 1 Co-sited > Exif.Image.ExifTag Long1 550 > Exif.Photo.ExposureTime Rational1 1/250 s > Exif.Photo.FNumber Rational1 F4 > Exif.Photo.ExposureProgram Short 1 Auto > Exif.Photo.ISOSpeedRatings Short 1 64 > Exif.Photo.ExifVersion Undefined 4 2.20 > Exif.Photo.DateTimeOriginal Ascii 20 2008:09:28 > 14:31:41 > Exif.Photo.DateTimeDigitized Ascii 20 2008:09:28 > 14:31:41 > Exif.Photo.ComponentsConfiguration Undefined 4 YCbCr > Exif.Photo.CompressedBitsPerPixelRational1 2 > Exif.Photo.ExposureBiasValue SRational 1 0 > Exif.Photo.MaxApertureValue Rational1 F2.8 > Exif.Photo.MeteringMode Short 1 Multi-segment > Exif.Photo.LightSource Short 1 Unknown > Exif.Photo.Flash Short 1 No, compulsory > Exif.Photo.FocalLength Rational1 6.8 mm > Exif.Photo.MakerNote Undefined 840 (Binary > value suppressed) > Exif.MakerNote.OffsetLong1 1298 > Exif.MakerNote.ByteOrder Ascii 3 II > Exif.Olympus.SpecialMode Long3 Normal > Exif.Olympus.Quality Short 1 Standard > Quality (SQ) > Exif.Olympus.Macro Short 1 Off > Exif.Olympus.BWMode Short 1 Off > Exif.Olympus.DigitalZoom Rational1 None > Exif.Olympus.FocalPlaneDiagonal Rational1 7162/1000 > Exif.Olympus.LensDistortionParamsSShort 6 -187 -361 > -410 -139 -188 -150 > Exif.Olympus.FirmwareVersion Ascii 8 SX777 > Exif.Olympus.PictureInfo Ascii 52 > [pictureInfo] Resolution=1 [Camera Info] Type=SX777 > Exif.Olympus.CameraIDUndefined 32 79 76 89 77 > 80 85 83 32 68 73 71 73 84 65 76 32 67 65 77 69 82 65 0 255 255 255 255 > 255 255 255 255 255 > Exif.Olympus.PreCaptureFramesShort 1 0 > Exif.Olympus.0x0301 Short 1 0 > Exif.Olympus.OneTouchWB Short 1 Off > Exif.Olympus.0x0303 Short 1 0 > Exif.Olympus.0x0304 Short 1 0 > Exif.Olympus.DataDump1 Undefined 494 (Binary > value suppressed) > Exif.Photo.UserComment Undefined 125 (Binary > value suppressed) > Exif.Photo.FlashpixVersion Undefined 4 1.00 > Exif.Photo.ColorSpaceShort 1 sRGB > Exif.Photo.PixelXDimension Long1 2288 > Exif.Photo.PixelYDimension Long1 1520 > Exif.Photo.Inte
[hugin-ptx] Re: pvQt version 0.2 released
PS the proper typename is "GLint" for singed, "GLuint" for unsigned, not "glInt" On Oct 27, 10:38 am, Tom Sharpless <[EMAIL PROTECTED]> wrote: > Hi Harry > > Yes, this is a confusing bit. In fact if you just run the qmake > command again, it works, because the first run creates the build > directory -- but not until after the lines that failed. So an even > easier fix is to move those lines to the bottom of the .pro file. > > On Oct 27, 7:28 am, "Harry van der Wolf" <[EMAIL PROTECTED]> wrote: > > > Hi Tom, > > > w.r.t. the error when I run the "qmake pvQt.pro": > > > build/pvQtVersion.h: No such file or directory > > > It does that when I have a "fresh" pvQt-0.2.34-src directory and when I run > > it for the first time. The first time the directory does not contain a build > > directory. Therefore the script can't copy the pvQtVersion.h into this build > > directory. I made a quick patch for the pvQT.pro file, but only for the non > > windows side of it (does it work on windows?). > > You can find the diff attached. > > > Harry > > > 2008/10/26 Harry van der Wolf <[EMAIL PROTECTED]> > > > > Hi Tom, > > > > > It does not fail on the pvQtVersion.h. It does this in the second build > > >> when > > >> > I "clean" my target before building. It also removes the pvQtVersion.h. > > >> This > > >> > is my fault. > > > >> pvQtVersion.h is not removed by "clean" on my Windows and ubuntu > > >> system. > > > > Sorry I was not specific enough. I said "when I "clean" my ..". If I do it > > > via the Xcode IDE it remains where it is. Most of the times when things > > > are > > > not working as expected I just remove the entire build directory (rm -rf > > > build). > > > >> > If I compile in Xcode on Leopard 10.5 with "default universal" > > >> > settings > > >> it > > >> > compiles fine. > > > >> > On the other hand: when compiling in Xcode (on Leopard 10.5) with > > >> deployment > > >> > target 10.4 (Tiger) it does say: > > >> > /Users/Shared/development/pvqt/src/pvQtView.cpp:609: error: invalid > > >> > conversion from 'int*' to 'GLint*' > > >> > /Users/Shared/development/pvqt/src/pvQtView.cpp:609: error: > > >> initializing > > >> > argument 4 of 'void glGetTexLevelParameteriv(GLenum, GLint, GLenum, > > >> GLint*)' > > > >> I guess GLint is not identical to int on your OpenGL -- please add > > >> casts and try again. > > > > It has to do with the OpenGl version it has to be compiled against: on > > > Tiger (10.4.x) it is 1.4.x. On Leopard (10.5.x) it is 1.5.x. When I > > > compile > > > the default way, e.g. OpenGl 1.5 on Leopard, it works. When I > > > cross-compile > > > downward compatible, e.g. for OSX 10.4 (and up) on 10.5 I do get the > > > error. > > > I attached the gl.h from Tiger and Leopard to the mail. On Tiger Glint is > > > a > > > long, on Leopard it is an int. > > > > I connected my USB drive with Tiger to my macbook and rebooted and tried > > > to > > > build it. The error on Tiger is exactly the same as on Leopard when > > > compiling for Tiger and up (which is obvious but better safe than sorry). > > > > You mention "please add casts and try again." I googled a bit but I'm > > > still > > > lost. > > > So: Tell me how master, and your obedient servant will try ;-) > > > > (Another option might be to test for the MacOSX version. > > > on Tiger "uname -sr" gives "Darwin 8.11.1" > > > on Leopard it gives "Darwin 9.5.0") > > > > Harry > > > pvQt.pro.diff > > < 1KViewDownload --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Exiv2-0.18pre1 / Olympus JPEGs / RAW stitching
Hi all, I've been working in the past couple of weeks to help Robin Mills with the Windows build of the latest Exiv2-0.18pre1. In the short term, I hoped this would solve the issue with the EXIF data from the Olympus JPEG. Unfortunately it does not. The focal length is read correctly, but the focal length multiplier is missing, both in Windows and Ubuntu. The issue is now placed with Andreas Huggel and Robin Mills and if it is an Exiv2 issue, it will be solved sooner or later. In the long term, as Exiv2 moves forward, there are very interesting features for us. Forewarded message from Andreas Huggel: > RAW images may contain several (I've seen up to three) preview images > in addition to the main image in different sizes and usually in JPEG > or TIFF format. > > Applications can use these to very quickly display a thumbnail or > lower resolution preview of the actual picture (which is typically > large and may require decoding before it can be displayed). > > For the 0.18 release, Vladimir Nadvornik has contributed new Exiv2 > functionality to easily access a list of available preview images as > well as the actual preview images from the metadata of the image > (Exif, IPTC or XMP). It works roughly like this: > > Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open(filename); > image->readMetadata(); > > Exiv2::PreviewManager loader(*image); > Exiv2::PreviewPropertiesList list = loader.getPreviewProperties(); > // The list is sorted by the size (in pixels) of the previews, > // starting with the smallest preview. > > // Choose one of the previews from the list ... > Exiv2::PreviewImage preview = loader.getPreviewImage(*pos); > > // PreviewImage has methods to access the preview image data > > The feature is in the SVN trunk (preview.hpp) and works well enough > that you can try it out and let us know what you think of it now. I suspect that the preview JPEGs are more than enough for CP detection, hence it would be possible to extract them from the RAW files and set up the stitching project without going through the slower RAW conversion. RAW conversion would be postponed to the rendering process, which could be batched. Just add a Makefile rule for dcraw or whatever raw converter is used. It is not RAW stitching yet, but maybe an initial step into it? the separation of the project setup process from the rendering process. A fast (ideally real time), human / GUI driven project setup process, followed by a batched (and thus geared toward accuracy and quality, not speed) rendering process. thoughts? Yuv --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: pvQt version 0.2 released
Hi Harry Yes, this is a confusing bit. In fact if you just run the qmake command again, it works, because the first run creates the build directory -- but not until after the lines that failed. So an even easier fix is to move those lines to the bottom of the .pro file. On Oct 27, 7:28 am, "Harry van der Wolf" <[EMAIL PROTECTED]> wrote: > Hi Tom, > > w.r.t. the error when I run the "qmake pvQt.pro": > > build/pvQtVersion.h: No such file or directory > > It does that when I have a "fresh" pvQt-0.2.34-src directory and when I run > it for the first time. The first time the directory does not contain a build > directory. Therefore the script can't copy the pvQtVersion.h into this build > directory. I made a quick patch for the pvQT.pro file, but only for the non > windows side of it (does it work on windows?). > You can find the diff attached. > > Harry > > 2008/10/26 Harry van der Wolf <[EMAIL PROTECTED]> > > > Hi Tom, > > > > It does not fail on the pvQtVersion.h. It does this in the second build > >> when > >> > I "clean" my target before building. It also removes the pvQtVersion.h. > >> This > >> > is my fault. > > >> pvQtVersion.h is not removed by "clean" on my Windows and ubuntu > >> system. > > > Sorry I was not specific enough. I said "when I "clean" my ..". If I do it > > via the Xcode IDE it remains where it is. Most of the times when things are > > not working as expected I just remove the entire build directory (rm -rf > > build). > > >> > If I compile in Xcode on Leopard 10.5 with "default universal" settings > >> it > >> > compiles fine. > > >> > On the other hand: when compiling in Xcode (on Leopard 10.5) with > >> deployment > >> > target 10.4 (Tiger) it does say: > >> > /Users/Shared/development/pvqt/src/pvQtView.cpp:609: error: invalid > >> > conversion from 'int*' to 'GLint*' > >> > /Users/Shared/development/pvqt/src/pvQtView.cpp:609: error: > >> initializing > >> > argument 4 of 'void glGetTexLevelParameteriv(GLenum, GLint, GLenum, > >> GLint*)' > > >> I guess GLint is not identical to int on your OpenGL -- please add > >> casts and try again. > > > It has to do with the OpenGl version it has to be compiled against: on > > Tiger (10.4.x) it is 1.4.x. On Leopard (10.5.x) it is 1.5.x. When I compile > > the default way, e.g. OpenGl 1.5 on Leopard, it works. When I cross-compile > > downward compatible, e.g. for OSX 10.4 (and up) on 10.5 I do get the error. > > I attached the gl.h from Tiger and Leopard to the mail. On Tiger Glint is a > > long, on Leopard it is an int. > > > I connected my USB drive with Tiger to my macbook and rebooted and tried to > > build it. The error on Tiger is exactly the same as on Leopard when > > compiling for Tiger and up (which is obvious but better safe than sorry). > > > You mention "please add casts and try again." I googled a bit but I'm still > > lost. > > So: Tell me how master, and your obedient servant will try ;-) > > > (Another option might be to test for the MacOSX version. > > on Tiger "uname -sr" gives "Darwin 8.11.1" > > on Leopard it gives "Darwin 9.5.0") > > > Harry > > > > pvQt.pro.diff > < 1KViewDownload --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: pvQt version 0.2 released
Hi Harry, Thanks for all your work on this. I do hope we can release a Mac version built by you very soon, as people have been asking for one. When I said "add casts" I meant things like "(glInt) x" that ask the compiler to give x the type glInt, if it can ( in C++ equivalently "glInt(x)" which I like better because it looks like the type- conversion function that it really is). However, on reconsideration, I realized that those variables should be declared as glInt in the first place. I've tried to do that in the source I'm about to upload. The main improvement, though, is that the latest version does show images on OpenGL 1.4, while the one I just released (0.2.34) does not. I also fixed a couple of bad spots in the UI, and the build directory problem. So please take a look soon for SVN version 35 and build from it. Regards, Tom On Oct 26, 3:04 pm, "Harry van der Wolf" <[EMAIL PROTECTED]> wrote: > Hi Tom, > > > It does not fail on the pvQtVersion.h. It does this in the second build > > when > > > I "clean" my target before building. It also removes the pvQtVersion.h. > > This > > > is my fault. > > > pvQtVersion.h is not removed by "clean" on my Windows and ubuntu > > system. > > Sorry I was not specific enough. I said "when I "clean" my ..". If I do it > via the Xcode IDE it remains where it is. Most of the times when things are > not working as expected I just remove the entire build directory (rm -rf > build). > > > > > > > > If I compile in Xcode on Leopard 10.5 with "default universal" settings > > it > > > compiles fine. > > > > On the other hand: when compiling in Xcode (on Leopard 10.5) with > > deployment > > > target 10.4 (Tiger) it does say: > > > /Users/Shared/development/pvqt/src/pvQtView.cpp:609: error: invalid > > > conversion from 'int*' to 'GLint*' > > > /Users/Shared/development/pvqt/src/pvQtView.cpp:609: error: > > initializing > > > argument 4 of 'void glGetTexLevelParameteriv(GLenum, GLint, GLenum, > > GLint*)' > > > I guess GLint is not identical to int on your OpenGL -- please add > > casts and try again. > > It has to do with the OpenGl version it has to be compiled against: on > Tiger (10.4.x) it is 1.4.x. On Leopard (10.5.x) it is 1.5.x. When I compile > the default way, e.g. OpenGl 1.5 on Leopard, it works. When I cross-compile > downward compatible, e.g. for OSX 10.4 (and up) on 10.5 I do get the error. > I attached the gl.h from Tiger and Leopard to the mail. On Tiger Glint is a > long, on Leopard it is an int. > > I connected my USB drive with Tiger to my macbook and rebooted and tried to > build it. The error on Tiger is exactly the same as on Leopard when > compiling for Tiger and up (which is obvious but better safe than sorry). > > You mention "please add casts and try again." I googled a bit but I'm still > lost. > So: Tell me how master, and your obedient servant will try ;-) > > (Another option might be to test for the MacOSX version. > on Tiger "uname -sr" gives "Darwin 8.11.1" > on Leopard it gives "Darwin 9.5.0") > > Harry > > > > > > gl.h.Tiger > 200KViewDownload > > gl.h.leopard > 203KViewDownload --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin-0.7.0 released
Ok... I expected something just like this, thank you! So I'll just try to install all packages necessary, first this "libc6- dev", and then try to figure out the rest. Trying to carry on, thanks a lot! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: newbie introduction - hugin usability
On 27 Oct, 10:12, dishio <[EMAIL PROTECTED]> wrote: > On Oct 27, 10:37 am, Klaus <[EMAIL PROTECTED]> wrote: > > > Hello, > > Regarding hugin, > > newbie needs an initial tutorial to guide him through the workflow. > > Did newbie go to hugin home > page?http://hugin.sourceforge.net/tutorials/index.shtml Newbie did not read any documentation yet, but with me looking over his shoulder was guided on how to proceed. Some programmes are self-explaining, and without RTFM one can explore the capabilities in looking at menu bars, click into windows etc. and observe what happens. Maybe one can nudge hugin further into that direction. Cheers Klaus --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: pvQt version 0.2 released
Hi Tom, w.r.t. the error when I run the "qmake pvQt.pro": build/pvQtVersion.h: No such file or directory It does that when I have a "fresh" pvQt-0.2.34-src directory and when I run it for the first time. The first time the directory does not contain a build directory. Therefore the script can't copy the pvQtVersion.h into this build directory. I made a quick patch for the pvQT.pro file, but only for the non windows side of it (does it work on windows?). You can find the diff attached. Harry 2008/10/26 Harry van der Wolf <[EMAIL PROTECTED]> > Hi Tom, > > > It does not fail on the pvQtVersion.h. It does this in the second build >> when >> > I "clean" my target before building. It also removes the pvQtVersion.h. >> This >> > is my fault. >> > >> pvQtVersion.h is not removed by "clean" on my Windows and ubuntu >> system. >> > > Sorry I was not specific enough. I said "when I "clean" my ..". If I do it > via the Xcode IDE it remains where it is. Most of the times when things are > not working as expected I just remove the entire build directory (rm -rf > build). > > >> >> > If I compile in Xcode on Leopard 10.5 with "default universal" settings >> it >> > compiles fine. >> > >> > On the other hand: when compiling in Xcode (on Leopard 10.5) with >> deployment >> > target 10.4 (Tiger) it does say: >> > /Users/Shared/development/pvqt/src/pvQtView.cpp:609: error: invalid >> > conversion from 'int*' to 'GLint*' >> > /Users/Shared/development/pvqt/src/pvQtView.cpp:609: error: >> initializing >> > argument 4 of 'void glGetTexLevelParameteriv(GLenum, GLint, GLenum, >> GLint*)' >> > >> I guess GLint is not identical to int on your OpenGL -- please add >> casts and try again. >> > > It has to do with the OpenGl version it has to be compiled against: on > Tiger (10.4.x) it is 1.4.x. On Leopard (10.5.x) it is 1.5.x. When I compile > the default way, e.g. OpenGl 1.5 on Leopard, it works. When I cross-compile > downward compatible, e.g. for OSX 10.4 (and up) on 10.5 I do get the error. > I attached the gl.h from Tiger and Leopard to the mail. On Tiger Glint is a > long, on Leopard it is an int. > > I connected my USB drive with Tiger to my macbook and rebooted and tried to > build it. The error on Tiger is exactly the same as on Leopard when > compiling for Tiger and up (which is obvious but better safe than sorry). > > You mention "please add casts and try again." I googled a bit but I'm still > lost. > So: Tell me how master, and your obedient servant will try ;-) > > (Another option might be to test for the MacOSX version. > on Tiger "uname -sr" gives "Darwin 8.11.1" > on Leopard it gives "Darwin 9.5.0") > > Harry > > >> >> --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~--- pvQt.pro.diff Description: Binary data
[hugin-ptx] Re: newbie introduction - hugin usability
On Oct 27, 10:37 am, Klaus <[EMAIL PROTECTED]> wrote: > Hello, > Regarding hugin, > newbie needs an initial tutorial to guide him through the workflow. Did newbie go to hugin home page? http://hugin.sourceforge.net/tutorials/index.shtml --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] newbie introduction - hugin usability
Hello, Yesterday evening: newbie introduction to hugin and panorama stitching. Some remarks on usabililty while watching and tutoring a first three-image stitch. Downloading from hugin.sf.net works ok. Installing hugin on XP with the exe file works ok, but then there are suddenly lots of aliases on the desktop. Newbie is somewhat confused. Open Images tab. Drag and drop images into white area. Tell newbie to click on an image name to ascertain that image is loaded indeed. Methinks that the last image(s) dropped into the window could be highlighted by default and displayed in the preview. Then skipping a couple of tabs going to Control Points. Concept is easily explained to newbie. Explicit hint needed to set right image to number 1, as current default is to display image 0 twice. Newbie roughly clicks on the image, zoom in happens and the desired spot is obscured by the magnified square. Also newbie tries to click into that square to adjust positioning. Need to tell to manipulate the faintly visible crosshair. Mesays that the doughnuts would have been more intuitive, but thinking about a click and hold (real magifying glass pops up), drag (fine positioning), release (place CP) workflow. Usually only one magified square is visible, hence no hint whether placement was ok. Methinks two squares should be visible, one may disappear when cursor is moved. Optimising is fine for a start. But need to point out the drop-down menu with the different optimisation strategies. Maybe that could be done less hidden. Mesays that I usually optimise several times, adding more parameters at each step. Preview is accessible from the menu. The icons are not yet intuitive to the newbie. The preview window comes up rather small at the start, of course a once-only problem. Irritating is also pressing the align buttons and nothing happens. Of course the default is that the automatic preview redrawing is switched of by default. If that new fast preview were not in the pipeline, methinks change would be needed. One CP was placed badly, numbered 8 in the F3 window. Where is number 8 in the CP tab? There it is numbered 3. The F3 control points window is much too small at the start. Maximising, then much too large. Awkwardly floating at the top. Methinks F3 should toggle it. If you want to have it in front, press F3 twice. Changing back from the preview window to the main window is not smooth. Recommendation to newbie was to close the preview window. Exposure tab works ok. Popup window is slighly irritating. Mecomments on Optimisation and Exposure: maybe we should be doing away with the popup windows (displaying the values in the main window), and if one does not like the latest optimisation result, rely on ^Z or "undo" in the menu for the step back. Vertical control points not yet introduced to newbie. Slider control and clicking in preview window briefly shown. In Stitcher tab optimised image size, both angles and pixels, but did not use crop values. Did not change the projection type. Methinks maybe put it into a menu bar submenu. Saved the panorama using the default output to TIFF. Output filename contained an Umlaut, text terminal output was corrupt ( did not display after umlaut) but processed fine. After enblend had finished, doing the thingy with the EXIF information took an irritatingly long time, almost felt like hugin frozen. Methinks that invoking exiftool should be opt-in for experts. In the end there was a nice panoramic image. TIFF file. Irfanview used for subsequent cropping and JPEG conversion did not resize display window to image size - nothing to blame on hugin. Regarding hugin, newbie needs an initial tutorial to guide him through the workflow. Regards Klaus --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
