http://blog.gmane.org/gmane.comp.misc.ptx hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.misc.ptx/33214 <pre> There is no feature to do this in Hugin. You could maybe try something like setting all photos to roll, pitch and yaw = 0, optimising, then the unconnected photos will still have these 0 values so they can be identified and deleted. If you need to do this lots of times, then it would be possible with Panotools::Script. You would need to write a perl script that identifies the connected groups with the ConnectedGroups() method, sorts the list to find the biggest group, then creates a new .pto project of just the photos in this group using the Subset() method. </pre> Bruno Postle 2013-05-19T20:56:50 http://permalink.gmane.org/gmane.comp.misc.ptx/33213 <pre> On Sunday, May 19, 2013 8:57:47 AM UTC+2, smib wrote: be something different in the mechanics between py3k and py2.x. The stack trace would really help... mind you the uses of float() in woa are few and far between and I suppose the problem is still somewhere in get_tiff_offset() (there are for float() calls just right in it) and it may well be something non-trivial. I never liked that routine - wrote it because I couldn't find a better way to obtain the cropped TIFF's crop data. Sadly just now I can't investigate, I'm busy packing up and going away for a few weeks soon - will be offline, too. Does the rest? If it's a python 3 problem, then the solution for now is obviously just to run woa under python2. Kay </pre> kfj 2013-05-19T15:02:38 http://permalink.gmane.org/gmane.comp.misc.ptx/33212 <pre>Getting a little further. Message is now basically: The suggetsed mod works with Python2.7 Brian On Friday, 17 May 2013 20:10:49 UTC+10, kfj wrote: </pre> smib 2013-05-19T06:57:47 http://permalink.gmane.org/gmane.comp.misc.ptx/33211 <pre>Hello Thomas, On Sat, 18 May 2013 22:18:05 +1000, Thomas Pryds &lt;thomas&lt; at &gt;pryds.eu&gt; wrote: Thanks for educating me, I didn't know that. Is the missing pto_gen now fixed? Cheers, </pre> Terry Duell 2013-05-18T23:13:59 http://permalink.gmane.org/gmane.comp.misc.ptx/33210 <pre>Kai-Uwe - Am Samstag, 18. Mai 2013 12:40:40 UTC+2 schrieb beku: In fact, I can't. My assumptions of the blending process are ridiculously naive: p' = t * p0 + (1 - t) * p1, 0 &lt;= t &lt;= 1. where the ps are some relevant characteristics of pixels 0 and 1 to be blended, e.g. some luminance measure. Obviously, this equation can return values for p' that are outside a color space for a specific profile or even for an entire color space; think of p0 and p1 being very close to the shell. The Enblend/Enfuse code in question juggles with three: RGB, JCh, and Lab. And suddenly you're not in Kansas anymore. In version 2.x LCMS introduced the "Unbounded CMM" (see, e.g. http://www.littlecms.com/CIC18_UnboundedCMM.pdf), where the library itself does not take care anymore to keep all values inside the color spaces, but instead lets the user decide what to do with "outsiders". Enblend/Enfuse has picked up that idea and both programs work on unbounded values as long as possible. That way, the users get most out of their input images (I'm talking about CIECAM mode only). Finally, we have to catch all renegades and find a representation for them _inside_ the RGB-cube defined by the input profile (per definitionem our output profile). Here we go to great lengths to pick a projection that minimizes the deltaE of the unbounded renegade and the final in-cube image (see e.g. "fixmath.h", method ConvertJCHPyramidToVectorFunctor::operator()). During the process we evaluate the color space conversion formulas outside of a regular color space (for the renegades) and barely inside for the final pixel values. I presume that not all formulas of LCMS are numerically stable or even defined -- think of the notorious pow(3) -- for all these values. Furthermore, I can imagine that the code of the formulas changes from time to time, "Unbounded CMM" being a relatively new feature. Maybe it returns exactly the same results for inside-color-space pixels, but not necessarily for outside pixels and we get hosed from time to time. Just my thoughts, could be wrong, nothing ex cathedra. I have never called LittleCMS's behavior a "bug", as neither I am aware of a mandatory specification, nor am I sure that Enblend/Enfuse don't go over the top and LCMS simply gives. Cheers, Chris </pre> cspiel 2013-05-18T14:46:06 http://permalink.gmane.org/gmane.comp.misc.ptx/33209 <pre>Den 18/05/2013 01.53 skrev "Terry Duell" &lt;tduell&lt; at &gt;iinet.net.au&gt;: A must-have for Hugin users running Ubuntu (if they don't want to build themselves): https://launchpad.net/~hugin There's a ppa with releases, one with upcoming releases (e.g. release candidates), and one with nightly builds. From the Hugin download page there's a link to the wiki where enabeling the ppa in your system is explained. Thomas </pre> Thomas Pryds 2013-05-18T12:18:05 http://permalink.gmane.org/gmane.comp.misc.ptx/33208 <pre>Am Samstag, 18. Mai 2013 08:58:58 UTC+2 schrieb cspiel: Can you describe more specifically what you expected and what changed in which version of lcms. So it might be more easy to fill a bug report and get proper attention? kind regards Kai-Uwe </pre> beku 2013-05-18T10:40:40 http://permalink.gmane.org/gmane.comp.misc.ptx/33207 <pre>Mark - Several ideas come into my mind. (1) Utilize Enfuse's CIECAM-mode either by forcing it with option `--ciecam' on input images w/o ICC profiles or, much better, feed images into Enfuse that all have the same ICC profile. 16-bit per channel in conjunction with the ProPhoto RGB space are promising. However, CIECAM-mode is broken with newer versions of the LittleCMS library. Preliminary fixes have been applied to the development branch ("compressor road"), but not yet to the stable branch. (2) Play with the `--exposure-cutoff' option, which was designed to tame extreme over- or underexposure. Usually one can leave this option's gray projectors alone. (3) The current development version of Enfuse offers user-defined exposure weighting functions. So, either given enough C++-programming proficiency or a grumpy, greasy, growling hacker near you, almost any exposure weight is possible. These are more or less expected artifacts from non-CIECAM blending, which in fact is RGB-cube blending without any sensible limiting. Working inside the RGB cube is fast and good enough for most Enfuse users most of the time, though. Because of changes in the LCMS library, we depend on in CIECAM mode, brightly colored pixel artifacts sometimes show up there too, where they should not. About half a dozen patches went into the current development branch of Enblend and Enfuse to fix this problem. Still, neither am I sure that the artifacts are gone, nor can I guarantee that the next change to LCMS does not cause new trouble. Panta rhei. terminate called after throwing an instance of 'std::runtime_error' what(): Minimizer1D::set_bracket: minimum not bracketed Abort trap: 6 Gee, that sucks! This exception is also related to changes to LCMS; you ran into a "never reached" branch. I have completely revamped this part of Enblend/Enfuse in a way that this problem never occurs again. Instead a more general (but slower) optimizer will take over. HTH, Chris </pre> cspiel 2013-05-18T06:58:58 http://permalink.gmane.org/gmane.comp.misc.ptx/33206 <pre>Hello Max, On Fri, 17 May 2013 17:13:08 +1000, Max Killer &lt;hal.from.2001&lt; at &gt;gmail.com&gt; wrote: [snip] I wasn't aware that the hugin project builds a nightly binary. I have just built the latest default branch source (for Fedora) and pto_gen is included. I suspect there is an error in the way the ppa is being built. Probably best to see if you can contact those responsible for the build. From where do you get your ppa ? Cheers, </pre> Terry Duell 2013-05-17T23:49:52 http://permalink.gmane.org/gmane.comp.misc.ptx/33205 <pre> On Wednesday, May 15, 2013 12:39:15 PM UTC+2, smib wrote: matching pair (1, 2) failed with TypeError: "can't use a string Okay. Figured it out. The key is this last message, can't use a string... The problem is due to the use of python 3. I hadn't tested woa under python 3, and obviously noone else has, either. So an error could stay undetected: to analyze tiffdump's output, the output is matched with regular expressions to filter out the bits which interest us. There, the re search patterns are given as string literals. This is fine in python 2.x, but python 3.x expects byte literals. Now this is easy to fix and doesn't break it for python 2.X either, because the relevant literal modifier, a prefixed 'b', is simply ignored in python 2.x. I'd ask you to midify woa.py in lines 237 and 238. The current version is fieldname = re.match ( r'[^\(]+' , t ) . group(0) . strip() fieldcontent = re.match ( r'([^&lt;]+&lt;)([^&gt;]+)' , t ) please insert the additional 'b' so that the lines read fieldname = re.match ( br'[^\(]+' , t ) . group(0) . strip() fieldcontent = re.match ( br'([^&lt;]+&lt;)([^&gt;]+)' , t ) this should fix the problem. If it does, please let me know so that I can send in a patch. If it doesn't , well..., let me know too, but I hope this is it ;-) Kay </pre> kfj 2013-05-17T10:10:49 http://permalink.gmane.org/gmane.comp.misc.ptx/33204 <pre>Hello all, I hope this is the right list, please excuse if not. I am working with darktable as an RAW image manipulation program and the latest addition was Lua scripting for darktable. With this I am trying to automate the pano (and HDR--&gt; LDR) generation out of darktable. I had a complete script up and running, but now I have the problem that either the hugin tools crash (fov &lt;0, from the next versions ppa), or pto_gen is missing (in the nightly ppa). Are there good reasons not to include pto_gen in the nightlies? If pto_gen cannot be included in the nightlies, is it included in the source so I can build it myself? I know that theoretically, I could construct a pto file just with Lua, but it seems like a lot of work. Maybe I am just overlooking an easy way to build a pto without pto_gen. Any help appreciated. Max </pre> Max Killer 2013-05-17T07:13:08 http://permalink.gmane.org/gmane.comp.misc.ptx/33203 <pre>Hi Rick, On 13 Mai, 14:28, RueiKe &lt;ruei...&lt; at &gt;yahoo.com&gt; wrote: thanks for update. I committed the changes to repository. Thomas </pre> T. Modes 2013-05-17T06:14:32 http://permalink.gmane.org/gmane.comp.misc.ptx/33202 <pre>Hello Matthew, On Fri, 17 May 2013 15:55:57 +1000, Matthew Petroff &lt;matthew&lt; at &gt;mpetroff.net&gt; wrote: Thanks. We should now be back in business. Cheers, </pre> Terry Duell 2013-05-17T05:55:56 http://permalink.gmane.org/gmane.comp.misc.ptx/33201 <pre>I just pushed the repository using a fast university connection. -Matthew On Thursday, May 16, 2013 7:10:24 PM UTC-4, Bruno Postle wrote: </pre> Matthew Petroff 2013-05-17T05:55:57 http://permalink.gmane.org/gmane.comp.misc.ptx/33200 <pre> OK, thanks Bruno. It will probably time out for me too, pretty slow speed here. Cheers, </pre> Terry Duell 2013-05-16T23:24:22 http://permalink.gmane.org/gmane.comp.misc.ptx/33199 <pre> I migrated all of the Mercurial repositories, except for hugin itself - which keeps timing out during the push. I'll try one more time, then somebody else with better bandwidth needs to give it a go. </pre> Bruno Postle 2013-05-16T23:10:24 http://permalink.gmane.org/gmane.comp.misc.ptx/33198 <pre>Hello Bruno, On Fri, 17 May 2013 05:57:36 +1000, Bruno Postle &lt;bruno&lt; at &gt;postle.net&gt; wrote: Cory Johns responded to my [forge:site-support] contact... "It appears the Hg repository didn't migrate when the project was upgraded. I can restore it for you, or, if you prefer, you can add a Mercurial tool on the [Tools Admin page](https://sourceforge.net/p/hugin/admin/tools/) and then push your copy of the repo to it." and I responded, asking if they could restore it, thinking they were probably less likely to stuff it up. Cheers, </pre> Terry Duell 2013-05-16T22:28:24 http://permalink.gmane.org/gmane.comp.misc.ptx/33197 <pre> They 'upgraded' us, but only migrated the unused SVN repository. The old Mercurial repository is still there, read-only I think: http://hugin.hg.sourceforge.net/hgweb/hugin/ I'll migrate the Mercurial repositories and post again when it is all working. </pre> Bruno Postle 2013-05-16T19:57:36 http://permalink.gmane.org/gmane.comp.misc.ptx/33196 <pre>Hi Gnome Nomad On 16.05.2013 08:32, Gnome Nomad wrote: Most probably an old tiff library was used for this compilation, one that still had the LZW disabled. IIRC, we are talking about a self compiled windows binary, and keeping up to date with all the dependencies of hugin and their versions and variants is not easy. Regards Stefan Peter </pre> Stefan Peter 2013-05-16T07:54:43 http://permalink.gmane.org/gmane.comp.misc.ptx/33195 <pre>Hi, I'll try your build (I was using your builds of 2012) but I want to access I am not sure I understand your question; if you want to access the command line tools, you just have to open the dmg and in the terminal you specify the path to the tools (for example "/Volumes/Hugin\ 2013.0.0.6321\:4a43fef669c1\ Release/HuginTools/cpfind -o ...") (note that anything relying on Python won't work in this case) If I am answering the wrong question, do not hesitate to tell me, Cheers, Matthieu </pre> ___matthieu___ 2013-05-16T07:14:26 http://permalink.gmane.org/gmane.comp.misc.ptx/33194 <pre> Bizarre ... https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch#Patents </pre> Gnome Nomad 2013-05-16T06:32:28 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.misc.ptx