Re: [hugin-ptx] CRITICAL: join us to nuke the pesky bug that is plaguing the fast preview
Hullo Tommaso, On Tue, 09 Aug 2011 03:05:24 +1000, Tommaso Massimi wrote: [snip] I think it is better to wait for Lukas' help. I think you are right. Thanks for your comments. Cheers, -- Regards, Terry Duell -- 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 Fri, Aug 5, 2011 at 1:18 AM, Terry Duell wrote: > Hullo Tommaso, [...] > Do you understand the valgrind output well enough to be more specific about > where in the hugin code these problems are occurring? > Being able to home in one where the fixes are needed would help, if that's > possible. Hi Terry, if what we can see in the first part of the valgrind output is not a false positive, there is a probelm at design level, i.e. gtk+ is used in more not synchronized threads This could require a deep revision of the code; as I have never seen the hugin code, I can't help here. In the second part of the valgrind output there are a couple of backtraces probably caused by some other thread issue, as Lukas said. you could see more running hugin with the debugger gdb hugin and at crash time you should see the same backtrace valgrind reports and also memory and variables value at crash time. Then digging a bit, you could see where the problem is, but if you are not a developer, find out the problem following this way could be an hard job. I think it is better to wait for Lukas' help. -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: how many man-years to reboot Hugin?
On 8 Aug., 15:50, Frederic Da Vitoria wrote: > Python can be compiled. Actually, cross platform dependency handling > is so tricky that a Hugin written in Python would have to be compiled > IMO. So the performance won't be noticeably different. How would you compile Python? And why? You may suffer from a misconception here. It is possible to package a python program, a python interpreter and all modules it uses into a bundle which can be distributed, installed and executed like any other program, since it's all FOSS and noone asks you for license fees for the interpreter etc. - but you can't compile python code. Python is, at a basic, technical level a particular style of using C. There is no difference. You can write stuff in C which you compile and use that from python, making it execute faster than writing the same stuff in python. Every bit of python code is compiled into a byte-code (not machine language), which is then executed, but this compilation step is left to the actual machine the code is running on, precisely to keep the python code unencumbered by platform specificity. When it comes to dependencies from other libraries: they either exist as python modules for all platforms hugin supports - then we can use them - or they don't, in which case we can either look for something else or wrap the C/C++ libraries with SWIG, just as I have wrapped most of hugin. I shan't comment further on the 'user's point of view'. If any of you have followed the discussion you know that my proposition is not to modify hugin but cleanly rewrite a new incarnation in a parallel project, code name munin. Once it's there, the users can choose which they prefer. And if it's a Linux geek thing that doesn't run on MacOS maybe it's allure will be so great that someone comes and ports it to the Mac. If not, the geeks have a tool they themselves can use happily, never mind the 'users' who can just as happily ignore it and hope that some of the techies still find it interesting to maintain 'their' program. Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: how many man-years to reboot Hugin?
Hello
I am not a Hugin developer either, nor am I a Python developer, but I
feel another user's point of view wouldn't be too much here :-) Just
as Harry did, I will only answer to those items which I have something
to say about.
2011/8/8, Harry van der Wolf :
> = Going to a (in memory) database format:
> - Even though it seems a good step to make, it will create another
> dependency on all platforms. I don't like that.
I agree in general, but if my informations are correct, sqlite is not
much of a dependency, at
least not in the Windows world. Just copy an executable file and
sqlite is ready to work.
> - Do we implement our own sqlite3 "engine" into the package or make it a
> system dependency which will certainly hinder a lot of end users.
See above.
> = (wx)Python:
> - Kay suggest to move to (wx)Python for logic and gui. Currently python is
> an issue on both windows and OSX. That doesn't mean that it can't have a
> glorious future but we are certainly not there yet. C(++) is a well defined
> standard. Python should definitely fully backward compatible to at least
> 2.6.
I feel using or not WxPython is a decision where end-users are not
much concerned. Even if the developers decide to indeed switch to
Python for a part of the development, the end-users would still get
pre-compiled complete versions. Switching to Python will indeed
trigger a few problems, but those problems will only bother the people
who will create the end-user setups. I know a few applications which
rely on Python. I mean: I (Windows user) know a few apps (written on
Linux) which rely on Python. In those applications, the decision to
change to something else (or rather not to) has always been a
developer decision ("Python's paradigm does not suit me", or "some
things are much easier with this other tool" or so on), I never saw a
user complain "please leave Python, it sucks".
> - When moving to (wx)Python: what will it do to performance? A compiled
> binary is AFAIK much faster than any interpreted program. If we leave the
> tools in C(++) for performance and only build a wxPython shell around it,
> why not stay entirely on C(++) for the gui and logic.
Python can be compiled. Actually, cross platform dependency handling
is so tricky that a Hugin written in Python would have to be compiled
IMO. So the performance won't be noticeably different.
> - To me the python extension (note my wording) is very good functionality to
> be able to build new functionality (by the experts) to be later on built
> (using C++) into Hugin for the greater, lesser skilled community (also
> related to end user friendliness).
I agree. But if the plugins written in python are good enough, then
there should be no need to rewrite them in C(+/- ++). Which means the
ability to improve those plugins would in the hands of the users.
That's one of the points in the plugin architecture: let the end users
adapt the application to their needs, thus relieving the code
developers of the burden of doing it for them. Or said in a more
positive way: the users stop asking and start doing :-)
Plugins would need to be incorporated into the C core only when they
would do calculation-intensive work.
--
Frederic Da Vitoria
(davitof)
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
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: how many man-years to reboot Hugin?
Instead of copying large portions of other mails I would like to go directly into some of the points mentioned with my end user point of view mixed in: = User friendliness (not mentioned before, but my point of view): - All solutions offered so far come from the "techies" and relate to the code base, and off course they are the driving force behind the hugin community, but the techies are only 5% (maximum!) of the end-user base where both the windows end users (by far the biggest amount) and OSX end-users are (almost by definition) not the most technical users. All solutions should aim for more user friendliness. By now the python integration is certainly a help for new functionality but it's not user friendly. Also remember our discussions about how Hugin should look like. I'm not a coder of course but I don't think the code base is that bad, like mentioned by Tom Sharpless and the article mention by Habi. When looking at first at the code, even if you are experienced in other languages (php for me or maybe python for others), it is always tricky to find your way. - Again: the techies know their way in the program as they are experienced, some with many, many years of experience. It still strikes me that so many users experience issues on "simple user-friendly" functionality (note: simple and user-friendly to the experienced users). = Going to a (in memory) database format: - Even though it seems a good step to make, it will create another dependency on all platforms. I don't like that. - Do we implement our own sqlite3 "engine" into the package or make it a system dependency which will certainly hinder a lot of end users. - What about the translations? It seems very logical to me to put them as well (or even as first) in a database. But then: what about the translators: Do they need to setup a development environment with e.g. sqlite to be able to do their translation work? I'm afraid that won't work. So in that case: Do we still use the .po files and "someone" writes a C(++) or (wx)Python tool to import them into the database? = (wx)Python: - Kay suggest to move to (wx)Python for logic and gui. Currently python is an issue on both windows and OSX. That doesn't mean that it can't have a glorious future but we are certainly not there yet. C(++) is a well defined standard. Python should definitely fully backward compatible to at least 2.6. - When moving to (wx)Python: what will it do to performance? A compiled binary is AFAIK much faster than any interpreted program. If we leave the tools in C(++) for performance and only build a wxPython shell around it, why not stay entirely on C(++) for the gui and logic. - To me the python extension (note my wording) is very good functionality to be able to build new functionality (by the experts) to be later on built (using C++) into Hugin for the greater, lesser skilled community (also related to end user friendliness). - We have some C(++) programmers on board. How many (wx)Python programmers do we have? This is a neccessity for continuity. = how? or why? - In previous mails we were already discussing "how to plan/structure/execute". To me this is how many projects (also within my own company) go off the rails. The first questions are: Why do we want to do it? And actually who want's it: 95% end users struggling for the year to come or leaving, or 5% techies? What's the "business case"? Is it worth it? This is not some GSOC minor project (I don't mean this derogatory, not at all) which can be integrated at some point. It will make hugin shake (or break) at it's foundation. I don't give much answers or solutions. Merely things to consider when doing such a major step which could break hugin easily for at least a year (or worse). my 2 cents. 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 hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: Workflow for manual 16 bit blending of Hugin panoramas using 8 bit gimp
Yes I have visited that web page before, when I was searching for HDR workflows in Linux :-). Which workflows that work depends a bit on what one's goal is. To me, it is important that there are no visible artifacts even at close inspection, ghosting, seams, etc, and I most often strive for a natural look. So when I do HDR it is rarely to achieve a cool "HDR look", but to increase the dynamic range in problematic light, so it is often only about merging 2-3 exposures where the brightly lit parts is from the shorter exposures, and I blend in that manually. I usually keep some light overexposure on the brighter parts since it often looks more natural (provides some glow to it). For this type of goal the automatic tools can rarely produce as good results. However, if one want to achieve a cool HDR look with exaggerated texture and cartoon-like tone mapping real HDR tools are required. In some cases it may be useful to combine both automatic tools and manual blending. But one can also have the view that some minor artifacts are ok, and it is more important with a quick workflow. Often manual blending is quicker than one may think though. The toughest cases is where it must be a sharp transition between the various exposures, the seam may then be more or less a pixel-by-pixel work, but often one can get away with a few feathered selections and gradients. If working with free tools, it is kind of good to prefer the more manual approaches, since I don't see free software being near as good as say photomatix when it comes to automatic HDR. On Aug 7, 1:21 pm, "Carlos Eduardo G. Carvalho (Cartola)" wrote: > Hi, have you already seen this kind of workflow? > > http://photoblog.edu-perez.com/2009/02/hdr-and-linux.html > > I guess I have already posted it here, but anyway... > > I don't think it is good for every situation, but have already used some > times with good results. Note: I did it without RAW, working directly with > JPGs. > > [ ]s, > > Carlos E G Carvalho (Cartola)http://cartola.org/360 > > 2011/8/6 torger > > > > > On 6 Aug, 22:18, Yuval Levy wrote: > > > The clouds are blue in both processed images. Is this intended? Or are > > the > > > images above just one layer that you use to produce the final image? > > > Well, I intentionally wen't over the top with the image to stress the > > jpeg a little bit more, so I have put in both more saturation and > > contrast than I would do normally. The clouds are very pale blue in > > the raw file so the blue color comes just from heavily increased > > saturation, so yes it is intended. In a saner version I would still do > > the same things, but not pull the sliders so far... :-) > > > > > My intention of the creative composition was to enhance the sunlight > > > > and make it as saturated as experienced at sight, and increase > > > > generally the contrast in the clouds. > > > > So the next step would be to mask out the other parts of the image and > > use > > > another process for them? > > > > Thank you for sharing so much interesting information about your > > workflow. > > > I already did that kind of process here. I used rawtherapee, and it > > does not (yet) support layers/versions so it is a bit cumbersome, but > > I did four renditions, one for the foreground, one for the water, one > > for the sunlight and one for the clouds with different settings > > (differences in curves, saturation, exposure, and detail settings). > > The foreground has moderately increased saturation, sunlight a lot, > > and clouds somewhere inbetween. Clouds has a lot increased contrast, > > while foreground is not so much so etc. I used more aggressive > > sharpening in the foreground than on the clouds. Then I loaded them as > > layers and masked them together in Gimp. > > > Normally this image would probably not need this multistep workflow, > > why I need to split in sections is because of the extreme settings, > > I'm for example using an insane amount of local contrast on the clouds > > which would break everything else in the picture. However, even for > > "simple" pictures, when I want to make a "print quality" version for I > > often re-process then and give them this kind of treatment to do more > > subtle improvements, afterall I think postprocessing is kind of fun > > too. In landscapes scenes there are typically 2 - 4 sections that I > > treat with separate parameters and then blend together. I also do > > dodge-and-burn this way (like to have layer masks for everything, has > > a non-destructive feel to it). So for a hugin stitched panorama, this > > treatment takes place after stitching is complete - thus important to > > have it in 16 bit tiff so continued processing maintains quality. > > > -- > > 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] Re: how many man-years to reboot Hugin?
On 8 Aug., 09:18, kfj <_...@yahoo.com> wrote: > In a way, I can't see why we couldn't simply use plain python look at this hsi script (try save it as xx.py and execute it with 'python xx.py' - you'll have to use your own imges, of course): from hsi import * p = Panorama() i0 = SrcPanoImage ( 'P197.JPG' ) i1 = SrcPanoImage ( 'P198.JPG' ) i0.setYaw ( -10 ) i1.setYaw ( 10 ) p.addImage ( i0 ) p.addImage ( i1 ) ofs = ofstream ( 'xx.pto' ) p.writeData ( ofs ) This makes a panorama from the two images, sets yaw values for the images and writes the resulting panorama out as a pto file. I think even a non-programmer can figure it out. So in fact, we already have the capability to use python to create the data structured hugin uses. No fuss. It's just that these data structures are a bit arcane and undocumented. See what I mean? Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: how many man-years to reboot Hugin?
On 8 Aug., 01:48, Yuval Levy wrote: > On August 7, 2011 03:25:31 am kfj wrote: > > - plus an import/export facility to make human-readable output > > ... > > all of these points strongly toward XML... > do you really think XML is human-readable? And think of the bloat if you want something like 5 control points! PTO is a bit like CSV, without the semicolons. Lacking identifiers, explicit delimiters and structuring elements (brackets, braces), it can only be used for very simple things. The problem with the current pto is more it's carelessly and organically grown format. With a clean design for a language to encompass hugin's needs writing a parser is easy. I've already written one for pto with all it's idiosyncrasies and it wasn't hard, so it could only get better. Feeding the internal representation of the parse into a database isn't magic, either. I'd recommend keeping a script language for the project files, though - a mere data dump would be just as annoying as pto, and too verbose. In a way, I can't see why we couldn't simply use plain python - we already have a python interpreter built into hugin. We could have a module containing the data types, and the project file would simply import that and then proceed by defining the data in ordinary python syntax. Just a quick shot, but maybe feasible? It would have the nice effect that the whole thing would become infinitely flexible to do more than merely defining data (think of calculated values, import libraries for other languages, grouping, looping, conditions...) - whereas the syntax would be that of an increasingly common, well- designed language, instead of something arcane you have to learn anew and is only good for the one purpose. >From hugin's point of view, things would become very easy indeed: parsing a pto file would consist in executing the python file - with all the comforts that brings, like to-the-line error messages, exception handling - plus whatever the python modules describing the hugin data types come up with (like, logging, consistency checks, adaptation to external conditions etc. etc.). A parser for pto already exists and could be used for backward compatibility. With appropriate python modules, the whole data content of the project file could be presented to hugin as an already-constructed, ready-to-use data structure - preferably one provided by a database-like engine. Once things evolve, the next step after executing the project file would be to execute the (wxPython) GUI do manipulate the data... I've used the same approach in a project of mine for handling audio data. In it's first incarnations, I designed a language for it. I did a right proper job: meta-specification of the data types, awk and shell scripts generating a lexical analyzer and a grammar, plus the C and C++ objects of the internal representation from the meta-spec - you name it, I had it. I gloried in the feeling of designing THE audio language. It became very complex - after a while I had structures, procedures... and eventually I asked myself: why am I doing this? How different is my anticipated language from any other procedural language? It turned out the differences were minute. Modern languages are so flexible, that they can be put to almost any use with the syntax they have. And one of the most flexible is python, since it's multi-paradigm and interpreted - yet capable of directly calling C code where performance matters. The next incarnation of my project consisted of a bunch of python modules, some in C for heavy-duty DSP stuff, as befits an audio program, some in pure python to deliver the logic and the interface to actually make stuff happen. It was much simpler. Much less code. The resulting scripts, by using python's clear and well-thought-out syntax, were much easier to grasp than my own language. And anyone knowing python could instantly have dealt with it, after a quick acquaintance with the data types and logic. Even the structuring into low-level C modules and higher-level python code wasn't a hindrance but a help, because it forced me to separate the two, which turned out beneficial. Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
