[hugin-ptx] Re: what is hugin doing to the exposure?

[dkloi]

On 9 Oct, 14:24, don  wrote:
> Thanks for the advice. I tried fiddling with the settings in EXPOSURES
> tab, but that didn't give me any good result. The source photos are
> JPEGs, straight from camera, both shot at 1/160 f11 @ ISO 100. To me
> it seems like Hugin is doing some kind of exposure optimisation which
> is not really necessary, hence the strange result. Perhaps it's worth
> mentioning that I'm using the stitch assistent - I choose the two
> photos from my hard drive, press ALIGN and when Hugin shows me
> Panorama preview, it already looks strange (http://don.vn.cz/temp/repo/
> hugin/huginpreview.jpg)

What exactly did you fiddle with in the exposure tab? Try selecting
Low Dynamic Range, or Low Dynamic Range with Variable White balance,
and then optimise. Preview the stitch, the images should overlap
pretty well even without blending.

Example Pre-Exposure Optimisation 
http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/AlignImages.jpg
Example Post-Exposure Optimisation, no blending
http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/NotBlended.jpg

You camera could be doing some processing to the image prior to
writing out the JPEG which could be the source of your problem. Make
sure the EV numbers are the same for both images in the Camera and
Lens tab. Hugin uses the EV numbers to calculate the relative
brightness of the images.

Cheers,
Daniel.
--~--~-~--~~~---~--~~
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: possible memory leak in enblend & enfuse?

[Robert Krawitz]

   Date: Fri, 9 Oct 2009 17:33:53 -0700 (PDT)
   From: grow 

   Stefan,
   Thanks for your analysis of this.

   You asked about memory and responsiveness.

   My Mac has 5.5Gb of RAM ... when I have a large stitch to do I
   sometime restart the machine and re-open the Hugin project with only
   the Stitch tab open and no preview or anything else taking up
   memory ... that way I have about 4Gb of free memory at the start of
   the stitch.

   I have a box on the shelf with 2GB more RAM that I will install
   "soon"  - probably this weekend - but I said that last weekend also.
   That will take the RAM to 7Gb (as I will have to take out 2x256Mb in
   order to fit the the 2x1Gb  new cards).  I will of course try my
   problematic Hugin projects after the upgrade to check whether it makes
   a difference.

   On responsiveness ... I haven't been systematic in measuring and
   plotting the times.  These are all ROUGH NUMBERS FROM MEMORY - this is
   NOT the result of a carefully controlled and systematically logged
   analysis.

   But with that disclaimer out of the way it goes something like
   this ...
   If I launch a Hugin-stitch of one of the problematic projects at say
   2,000 x 1,000 it will take a few minutes (typically I will set a tiny-
   test-stitch running ... switch windows to check email and the like ...
   and by the time I check back on Hugin it has finished)
   at 5,000 x 2,500 it might take perhaps 30 minutes  ... (I go
   downstairs and watch an episode of The SImpsons ... when I get back to
   my desk the stitch is finishing up)
   at 8,000 x 4,000 it will run for about 2 hours (I go and cook and
   serve dinner)
   when it gets to 12,000 x 6,000 (I set it running before I go to bed
   and check before breakfast in the morning  - either we have a good
   final image or an error report) when I check the file creation times
   it will have run for 6 or 7 hours!

That's more than linear, but not by much -- N*sqrt(N).

 5000x2500   =   12.5 MP, 0.5 hr  = 25 MP/hr
 8000x4000   =   32.0 MP, 2.0 hr  = 16 MP/hr
12000x6000   =   72.0 MP, 6.0 hr  =  8 MP/hr

Or, based on the time for 12.5 MP, you'd expect the 8Kx4K to take 1.3
hours and the 72 MP to take about 3 hours if it were linear.  If it
were N^2, you'd expect 32 MP to take about 3~3.5 hours and 72 MP to
take about 15 hours.  If it were N*sqrt(N), the 32 MP should take
about 2.0 hours and the 72 MP about 6.5~7 hours -- exactly what you're
seeing.  The 2 MP image should take about 0.064 hours, or 4 minutes.
You're seeing consistent behavior all the way up.  That's not usually
a signature of memory thrashing -- usually when that happens you hit a
wall, where above that point the time may well increase by orders of
magnitude.

   So my intuition is that there is a square or possibly cubic
   progression in the processing time as the final image size
   increases.  The processing time is proportional to something like
   n^3 where n is width of the image.  It is NOT proportional to n^4 -
   so it is NOT the square of the area.

Proportional to the cube of the width (linear dimension) appears to be
correct based on these 3 or 4 data points, but since each pixel has to
be processed I'd expect to calculate complexity based on the pixel
area.  Thus, N * sqrt(N).  Perhaps the developers can explain why it's
more than linear, but it's certainly not quadratic.

-- 
Robert Krawitz 

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

--~--~-~--~~~---~--~~
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: possible memory leak in enblend & enfuse?

[grow]

Stefan,
Thanks for your analysis of this.

You asked about memory and responsiveness.

My Mac has 5.5Gb of RAM ... when I have a large stitch to do I
sometime restart the machine and re-open the Hugin project with only
the Stitch tab open and no preview or anything else taking up
memory ... that way I have about 4Gb of free memory at the start of
the stitch.

I have a box on the shelf with 2GB more RAM that I will install
"soon"  - probably this weekend - but I said that last weekend also.
That will take the RAM to 7Gb (as I will have to take out 2x256Mb in
order to fit the the 2x1Gb  new cards).  I will of course try my
problematic Hugin projects after the upgrade to check whether it makes
a difference.

On responsiveness ... I haven't been systematic in measuring and
plotting the times.  These are all ROUGH NUMBERS FROM MEMORY - this is
NOT the result of a carefully controlled and systematically logged
analysis.

But with that disclaimer out of the way it goes something like
this ...
If I launch a Hugin-stitch of one of the problematic projects at say
2,000 x 1,000 it will take a few minutes (typically I will set a tiny-
test-stitch running ... switch windows to check email and the like ...
and by the time I check back on Hugin it has finished)
at 5,000 x 2,500 it might take perhaps 30 minutes  ... (I go
downstairs and watch an episode of The SImpsons ... when I get back to
my desk the stitch is finishing up)
at 8,000 x 4,000 it will run for about 2 hours (I go and cook and
serve dinner)
when it gets to 12,000 x 6,000 (I set it running before I go to bed
and check before breakfast in the morning  - either we have a good
final image or an error report) when I check the file creation times
it will have run for 6 or 7 hours!

So my intuition is that there is a square or possibly cubic
progression in the processing time as the final image size increases.
The processing time is proportional to something like  n^3 where n is
width of the image.  It is NOT proportional to n^4  - so it is NOT the
square of the area.

The crashing generally happens when complex masks are involved so when
I need a large image my way of getting the stitch to complete has been
to remove the masks and do Photoshop patching by hand afterwards
rather than masking before hand.

My guess is that there is something that happens in the process for
every pixel in the image - comparing the pixel to some other aspect of
the image - the mask perhaps?  If there is a bit-wize mask it might
be  that the determining factor in the processing time is the multiple
of the area of the image and the area of the mask. ... Oh that doesn't
make any sense because of course there isn't a single mask ...

When I get a chance I will try your suggestions from the other
message,

all the best

George

On Oct 9, 7:54 pm, Stefan Peter  wrote:

>...
> BTW, George, what amount of memory and swap space does your OSX
> installation have? Did you encounter unresponsiveness, too?
>
> Cheers
>
> Stefan Peter


--~--~-~--~~~---~--~~
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] gsoc2009_deghosting questions

[Steeve]

Hi

I took a copy of the trunk just after the deghosting was merged in
(svn 4554). This built without errors on the Windows SDK (Thanks to
everybody involved). I have been playing with the deghosting since it
is a feature I've been keenly waiting for.

I'm finding that the default options only produce blank masks. There
are a lot of options (-h) and I can see some of these altering the
generated masks, but basically I find I need to increase the threshold
(-t) to almost the maximum (255?) before I get anything much in the
masks.

I have tried several set of photographs, both LDR and HDR and always
end up in the same place -t 254.8..

I have posted one example http://www.miltonpanoramic.co.uk/deghosting.php.
I guess this is possibly not a good test? The constrast is high
between the sky and building, but low in the ghosted areas..  (All
images are jpg on the website but were obviously TIF. ) I also have a
set of bracketted images from the same location for HDR these show
similiar behaviour.

I have tried a better exposed LDR this has a lot of people moving
infront of a ruined build, which I had earlier manually masked to
remove the people. This did produce an impressive set of mask (clearly
highlighting the people) but again only with the threshold >254.

Has anybody got any hints on selecting these options? I happy to
experiment but am wondering if I'm in a dead-end?

Regards
Stephen






On Sep 21, 2:13 pm, Lukáš Jirkovský  wrote:
> Hi Harry
>
> 2009/9/20 Harry van der Wolf :
>
> > Hi,
>
> > I've never worked withdeghostingfrom Hugin and neither with HDR output. I
> > really need some explanation. I have been googling already for some
> > background information also but that's really scarce. Can someone point me
> > to some info?
>
> All the pto's in tarball should be prepared. First you need to check
> in stitcher tab if both Remapped images is checked for both Exposure
> fusion and HDR merging. Then you just run stitch. This should give a
> bunch of images. Images with *.exr extensions are used for
> hugin_hdrmerge and tiff images are used within deghosting_mask (but
> you can also use .exr images here too).
>
> For deghosting_mask run:
> deghosting_masks input_images -i 5
> where -i specify number of iterations, I suggest using about 5
> iterations. It should give results good enough. Since it's quite slow
> using more iterations is clueless.
>
> for other options:
> * if the masks doesn't mask part big enough to remove ghosting you can
> try lower threshold (-t parameter)
> * -a f should turn on computation similar to the olddeghostingcode
> from hugin_hdrmerge
> * if you try exr input here you can try using -a g, it seems to give
> better results (maybe I'll make it default)
> * if you want to see weights you can use -w w This will save weights
> in you current directory. The darker area is the higher possibility
> that it's "ghost" is.
>
> For hugin_hdrmerge run:
> hugin_hdrmerge -o foo.exr -m khan -i 5 input_images.exr
> where -m khan enablesdeghostingcode
>
> The options are the same, only -w options doesn't work here.
>
> How to interpret (and use) results:
> hugin_hdrmerge:
> just look at the output image. Ghosting artifacts shouldn't be present
> or they should be at least reduced (compared to running hugin_hdrmerge
> without -m khan).
>
> deghosting_mask:
> result shoud be bunch of b/w images. Then make sure they are in the
> same directory as the input images to the deghosting_mask and use use
> enfuse-mask (from Panotools::scripts):
> enfuse-mask input_files // note: do not specify the masks
>
> Resulting image should have ghosting removed or at least reduced.
>
> > Can I somewhere specify options for hugin_hdrmerge? If I need to do that on
> > the command line it's not much use for MacOSX users using the bundle, and
> > probably the same for Windows users (but that's a wild guess).
> > (I have a bundle ready for distribution but that's not useful if you can't
> > set options from the Gui).
>
> Yep, it's command line. It seems that I need to add some switch to GUI
> to easily enable it. I guess that it will take some time, because GUI
> toolkits are not my friends.
>
>
>
>
>
>
>
> > I do get "mask like" images instead of nicely merged images when running
> > hugin_hdrmerge from the command line, but actually I'm really clueless.
>
> > If the Tux images set functions best, a simple "hugin_hdrmerge for dummies"
> > based on this set would be useful and highly appreciated (unless I'm the
> > only dummy off course).
>
> > Harry
>
> > 2009/9/20 Lukáš Jirkovský 
>
> >> Hi all,
> >> I've created small compilation. All should contain some artifacts.
> >> With the files from folders Kyjov and Tanum the algorithm fails quite
> >> badly :-| because the ghosting is in smaller details.
>
> >> All folders contain input images and hdr.pto for remapping images to
> >> both HDR and LDR (to save bandwidth). The archive (22MB) can be
> >> downloaded from:
> >>http://blender6xx.ic.cz/pub/HDR.tar.bz2
>
> >> I'

[hugin-ptx] [OS X] Building External Tools for PowerPC on Snow Leopard?

[skip gaede]

Has anyone succeeded at building PowerPC architecture External Tools  
under Snow Leopard? I've tried, and only succeeded for Intel  
architecure for >,= 10.5. I did install the 10.4u SDK, and that did  
not help. It's not a biggie, but I'm curious.

Thanks,
--skip




--~--~-~--~~~---~--~~
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: hugin mentioned in an article

[Harry van der Wolf]

2009/10/9 Carl von Einem 

>
> Sorry for cross-posting...
>
> This is an article (in German language) about the presentation of
> gigapixel imagery in Linz, Austria
> 
>
> Oh, I just see that it's an article by Thomas Bredenfeld :-)
>
> Carl
>
> ps.
> I bet the Ars Electronica Center (AEC) would be a nice location for a
> panotools meeting...
>
>

When he writes about "montagesoftware" to create Gigapixel panos he says :
"Die ist sogar gratis zu haben, etwa beim Open-Source-Projekt Hugin, das
erst am 29. September die Version 2.0 für Linux vorgestellt hatte. Das
Programm ist - in niedrigeren Versionsnummern - auch für Windows und Mac OS
erhältlich."
(Sorry for those who don't speak German).

What does he mean with version 2.0? And lower versions also for windows and
Mac? I suppose he means 2009.2.0 but he's not very accurate.
I think we should be glad for the publication, but what do you mean with:
"Oh, I just see that it's an article by Thomas Bredenfeld :-)".

I know him because he asked me in April if he could add ImageFuser to the
DVD of his new book. Which was OK with me.
>From your reply I get the impression that you don't value him very high. Is
that correct?


Tschau,
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] hugin mentioned in an article

[Carl von Einem]

Sorry for cross-posting...

This is an article (in German language) about the presentation of
gigapixel imagery in Linz, Austria


Oh, I just see that it's an article by Thomas Bredenfeld :-)

Carl

ps.
I bet the Ars Electronica Center (AEC) would be a nice location for a
panotools meeting...

--~--~-~--~~~---~--~~
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: possible memory leak in enblend & enfuse?

[Stefan Peter]

Hi Lukáš

Lukáš Jirkovský schrieb:
> Hi Stefan,
> 
> 
> Here are my thoughts. Could anyone verify them?
> 1. the problem occurs when image cache is disabled or the limit
> exceeds (or almost fits almost exatly) memory size
> 2. the problem occurs when image cache is enabled but there is not
> enough memory to write temporary to disk.

I'm still investigating, but I don't think it has something to do with 
the image cache. Form what I have seen yet, the way the files are read 
and written seems to be the main culprit: In my tests, a 1.2 GByte Tiff 
for the resulting output file is created and accessed in its full size 
using mmap. This requires 1.2 GBytes of memory allocated to the application.
Additional memory is required for every of the source files. And, of 
course, the application itself will need some memory, too.
If physical memory gets tight, the system will start to swap. This leads 
to the unresponsiveness you mentioned. And in some cases, this swapping 
leads to thrashing: If the OS permanently is occupied with swapping in / 
out of pages, not much CPU performance is left over for the application.

The effect I noticed is worsened by using MP: There, the memory 
requirements occur in parallel whereas a nonMP application allocates 
memory resources sequentially. Therefore, nonMP compiled enblend 
versions will allow larger output files without breaking.

I have enabled the image cache only because I read that it has to be 
disabled when using OpenMP.

I'd like to have a closer look at the image handling functions (which I 
think are implemented somewhere in the vigra library. If there es a way 
to switch this from "full size access" (you have the full file 
accessible at the memory region used for the mmap) to "floating window 
access" (you only have a certain amount of the file mapped into the 
memory map of the application), the possible final size of the image 
would almost be infinite, but requiring only the amount of memory for 
the window size. Of course, performance would most probably suffer due 
to the fact that the window has to be shifted into the position required 
for the next write.

It actually may be that I'm on a totally wrong trace. Most information I 
try to explain here rely on some strace runs of
enblend --compression NONE -v --fine-mask --fine-mask \
  -w -f12018x6009 -o Village_Hotel.tif \
  Village_Hotel.tif Village_Hotel0001.tif Village_Hotel0002.tif\
  Village_Hotel0003.tif Village_Hotel0004.tif Village_Hotel0005.tif\
  Village_Hotel0006.tif Village_Hotel0007.tif Village_Hotel0008.tif\
  Village_Hotel0009.tif Village_Hotel0010.tif Village_Hotel0011.tif\
  Village_Hotel0012.tif Village_Hotel0013.tif Village_Hotel0014.tif\
  Village_Hotel0015.tif Village_Hotel0016.tif Village_Hotel0017.tif\
  Village_Hotel0018.tif Village_Hotel0019.tif Village_Hotel0020.tif\
  Village_Hotel0024.tif Village_Hotel0025.tif Village_Hotel0026.tif

One notable issue may be that the mmap for Village_Hotel.tif is roughly 
1.26 GBytes in size on my notebook according to strace, on the desktop 
with 4GB of memory, where the above command does finish without an 
error, the size of the final Village_Hotel.tif is only 551MBytes. You 
see, I will have to keep investigating.


If someone else has some insight into this area, I'd be delighted to be 
corrected or informed.

BTW, George, what amount of memory and swap space does your OSX 
installation have? Did you encounter unresponsiveness, too?

Cheers

Stefan Peter


--~--~-~--~~~---~--~~
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: windows binary release

[allard]

Software can be copyrighted but not patented. An algorithm can be
patented. It is a more high-level, abstract concept than a piece of
software. It's just too easy to change a few lines of code and claim
it's a different program, and too hard to say how much should be
changed before they are different.

At least that's what I learned in my very brief 'patent law for
engineers' class in university. Laws of man change faster than laws of
nature, I know the patent law has changed since then but I don't know
what the differences are exactly.

On Oct 8, 12:52 pm, Yuval Levy  wrote:
> I thought the European Patent Office would not grant patents on software?
> Yuv
>
> allard wrote:
> > Thanks. That certainly shows the USPTO database search is no good.
> > Also surprised that this goes unmentioned in so many places. But the
> > EPO was a pretty obvious place to look as well.
>
> >> See:http://v3.espacenet.com/publicationDetails/biblio?CC=EP&NR=2027558A2&;...
>
> >> ciao
> >>   Pablo
--~--~-~--~~~---~--~~
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: GSoC2009_layout with XYZ for Windows - please test

[Oskar Sander]

So what I was getting at is that could it be that most of the problems of
the layout branch like: windows-image-read-crash, EXIF-bug,
cropfactor-FOV-bug,  are actually code-baseline issues for that track that
would be mostly overcome after a merge into a more mature code-track.

While the really new features that needs fixing and testing are maybe
aligned-stack-optimization-crash  and even more so testing that the new
parameter model holds for all different panoramic purposes

I have reported problems of the layout view itself, but this bug only limits
usefulness, and is not blocking a release IMHO.  (although important for my
application)

I was getting at what is absolutely necessary to do with layout branch to
quickly get it merged. Once that has been done, it is easier to build
improvements on that.

>
>

--~--~-~--~~~---~--~~
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: replacing make?

[Alexandre Prokoudine]

On 7 окт, 17:04, Lukáš Jirkovský  wrote:

> I can imagine using something different instead of makefile. My first
> thoughts were about using some dynamic language like python or perl
> but I rejected these thoughts immediately. They would brink need to
> distribute python/perl/whatever with hugin. So this is no way. They're
> too big.

If you ever reconsider or need it for a different project, have a look
at waf. It's Python based, portable, *tiny* and very straightforward.

Alexandre
--~--~-~--~~~---~--~~
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: what is hugin doing to the exposure?

[Bart van Andel]

(I prefer to stay on-list except when not appropriate, so here's your
answer and my new reply)

On Fri, Oct 9, 2009 at 3:37 PM, don  wrote:
> I'm on Windows XP SP3. Not sure which version I can download, the
> latest ones seem to be for Windows Vista only, so i tried "hugin-
> SVN3943-setup.exe" - and the result is still abou the same.

Why not try the newest one? If it works on XP and you inform Ad
(either through this list or by email) he can inform others about this
fact too, just like Oskar Sander did with the build you've just tried.

Anyway, there's a tab called "Exposure", which is where you can apply
exposure correction to the images. This should improve your result.

--
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 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: what is hugin doing to the exposure?

[Lukáš Jirkovský]

2009/10/9 don :
>
> Thanks for the advice. I tried fiddling with the settings in EXPOSURES
> tab, but that didn't give me any good result. The source photos are
> JPEGs, straight from camera, both shot at 1/160 f11 @ ISO 100. To me
> it seems like Hugin is doing some kind of exposure optimisation which
> is not really necessary, hence the strange result. Perhaps it's worth
> mentioning that I'm using the stitch assistent - I choose the two
> photos from my hard drive, press ALIGN and when Hugin shows me
> Panorama preview, it already looks strange (http://don.vn.cz/temp/repo/
> hugin/huginpreview.jpg)
>
> On 9 říj, 14:36, dkloi  wrote:
>> On 9 Oct, 09:22, don  wrote:
>>
>> > Hugin makes something with them and
>> > that results in A) very weird brightness/contrast and B) in visible
>> > seams between the photos. The settings of the stitcher tab are 
>> > here:http://don.vn.cz/temp/repo/hugin/panosettings.gif
>>
>> > here is the result from 
>> > Hugin:http://don.vn.cz/temp/repo/hugin/panohugin.jpg
>> > here is the result from photoshop's 
>> > photomerge:http://don.vn.cz/temp/repo/hugin/panophotoshop.jpg
>>
>> > any tips? thank you.
>>
>> How did you take and process the input images? In camera JPG, or
>> processed from RAW? You may not get the same output even though the
>> exposure was fixed, depending on the exact processing chain.
>>
>> Try using the exposure optimisation tab, it'll fine tune the
>> differences between the two image. It also means that you no longer
>> have to lock exposure between taking source images, very useful if the
>> scene has much different brightness in different parts. I've been
>> using auto-exposure ever since this feature was introduced and only
>> need to bracket if the contrast is too great within a single frame.
>>
>> Example:http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/Clarke_Quay_sma...
>> I didn't need to bracket this 6+1+1 pano. Exposures ranged from 0.5s
>> to 2s at f/5.6. I also optimised the RAW development of each
>> individual frame to balance shadow and highlight detail. Exposure
>> optimisation was able to match all these widely different exposed
>> frames.
>>
>> Cheers,
>> Daniel.
> >
>

Hi Don,

if you've fixed exposure it should be enough to reset the exposure settings.

All you need to do is to go to the "Camera and Lens" select all images and:
1. in new version click on "Reset" button and select exposure.
2. in old version click on "Load EXIF". You may need to re-optimize
project in "Optimizer" tab then.

Lukas

--~--~-~--~~~---~--~~
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: what is hugin doing to the exposure?

[don]

I'm using Windows XP SP3, but I'm not sure which version I can
download - the latest ones seem to be for Windows Vista only. So I
tried installing "hugin-SVN3943-setup.exe" but the result is still the
same...

On 9 říj, 15:24, don  wrote:
> Thanks for the advice. I tried fiddling with the settings in EXPOSURES
> tab, but that didn't give me any good result. The source photos are
> JPEGs, straight from camera, both shot at 1/160 f11 @ ISO 100. To me
> it seems like Hugin is doing some kind of exposure optimisation which
> is not really necessary, hence the strange result. Perhaps it's worth
> mentioning that I'm using the stitch assistent - I choose the two
> photos from my hard drive, press ALIGN and when Hugin shows me
> Panorama preview, it already looks strange (http://don.vn.cz/temp/repo/
> hugin/huginpreview.jpg)
>
> On 9 říj, 14:36, dkloi  wrote:
>
> > On 9 Oct, 09:22, don  wrote:
>
> > > Hugin makes something with them and
> > > that results in A) very weird brightness/contrast and B) in visible
> > > seams between the photos. The settings of the stitcher tab are 
> > > here:http://don.vn.cz/temp/repo/hugin/panosettings.gif
>
> > > here is the result from 
> > > Hugin:http://don.vn.cz/temp/repo/hugin/panohugin.jpg
> > > here is the result from photoshop's 
> > > photomerge:http://don.vn.cz/temp/repo/hugin/panophotoshop.jpg
>
> > > any tips? thank you.
>
> > How did you take and process the input images? In camera JPG, or
> > processed from RAW? You may not get the same output even though the
> > exposure was fixed, depending on the exact processing chain.
>
> > Try using the exposure optimisation tab, it'll fine tune the
> > differences between the two image. It also means that you no longer
> > have to lock exposure between taking source images, very useful if the
> > scene has much different brightness in different parts. I've been
> > using auto-exposure ever since this feature was introduced and only
> > need to bracket if the contrast is too great within a single frame.
>
> > Example:http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/Clarke_Quay_sma...
> > I didn't need to bracket this 6+1+1 pano. Exposures ranged from 0.5s
> > to 2s at f/5.6. I also optimised the RAW development of each
> > individual frame to balance shadow and highlight detail. Exposure
> > optimisation was able to match all these widely different exposed
> > frames.
>
> > Cheers,
> > Daniel.
--~--~-~--~~~---~--~~
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: traditional preview

[T. Modes]

> how about (STEP 1) merging them visually with one single dropdown,
> Output, having three choices: FAST, LDR, HDR. The first one would be in
> FP, the other two would be in TP. The non applicable buttons in the
> toolbar would be grayed out?

Some points to consider:
Number 1: Currently fast preview and normal preview are both listen to
panorama changes. When both are active (but only one hidden) we can
get problems with performance, especially with big projects.
Number 2: In fast preview the difference mode is only activated when
graphic card is capable to do it. So when switch from fast to ldr/hdr
you also need to refresh the normal/difference mode box.

> Images
> - All
> - None
> - {list of the individual images}

I like the images in the toolbar. When moving to a menu it would be
harder to do a fast switch of visibility of single images.

> and we'd be left with (STEP 3) adding the tabs to the menu:
>
> Workflow
> - Assistant
> - Images
> - Camera and Lens
> - Crop
> - Control Points
> - Optimizer
> - Exposure
> - Stitcher
>
> I've broken this down into three steps. The goal is to turn the preview
> to the hub from which all action is started.
>
> many of the menu points would call up a palette-like window. The palette
> is as small as possible to cover the least of the preview. of course
> those function that requires large images (like Crop and Control Points)
> will display in separate, full size windows (maybe on top of the preview
> itself?)
>
> each incarnation of the palette-like window would have a single purpose.
> It would have a small number of fields to deal with. the new user won't
> be confused by the quantity of choices (and could be guided through the
> different palettes by the assistant); the fancy user could have many
> palettes open at the same time and juggle between them. The expert user
> could access each palette by a keyboard shortcut (they are menus). We'd
> break the complexity of the stitcher tab into manageable chunks and
> achieve a consistent interface.
>

I don't like the floating palette behavior. In this case the palette
which you will need is hidden by another palettes. And we can not
significant reduce the size of the single tabs. I like the tabbed user
interface.

> IMO the (Fast) Preview should become the hub and everything else should
> float around it.
>
> thoughts?

Performance! (especially with big projects)
With the current implemtation you can open a big project and start
working. When finish the optimising the can open the preview, wait a
little time - or a little more time, and check the result.
When the fast preview becomes the hub, you start opening a project,
now you have to wait until all images are loaded (take a coffee
break ;-), and then you can start working.

Thomas
--~--~-~--~~~---~--~~
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: traditional preview

[James Legg]

On Fri, 2009-10-09 at 09:13 +0100, Bruno Postle wrote:
> On Fri 09-Oct-2009 at 02:49 -0400, Yuval Levy wrote:
> >
> >does this mean that it is unlikely that the accuracy of the Fast Preview
> >will be improved?
> 
> I think it is very dependent on the graphics hardware.

There are a few constants that alter the quality / speed tradeoff. They
can be changed. I wanted to keep the preview fairly responsive on less
powerful machines, so the accuracy should be easily improved, at a cost
to speed. The constants could be tweaked, set based on hardware
specifications, or made a preference.

Here's where they are:
The number of pixels of image data used is set here:
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/TextureManager.cpp?revision=4005&view=markup#l_423
A too high value could cause a sudden performance drop on some hardware,
but I think the current value is quite cautious, and inappropriately low
when stacked images are used.

There are two ways of remapping the images. The transformations are
calculated by the CPU, but more accurate remapping requires transfering
more data to any dedicated graphics hardware, and then rendering there.
The quality level of the TexCoordRemapper, which maps evenly spaced
points on the panorama to the input images, is set here:
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/TexCoordRemapper.cpp?revision=3479&view=markup#l_27

There are several constants for the VertexCoordRemapper, which remaps
points on the input images into the panorama:
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/VertexCoordRemapper.cpp?revision=3721&view=markup#60
This remapper is adaptive: it adds detail where it thinks it is
necessary. You can increase the maximum detail level or change how it
decides when there is already enough.

The colour correction is more tricky. Most new graphics hardware is
programable, which would allow us to make an hdr mode, improve the
difference mode, and make photometric correction work well. However,
many existing machines don't support custom shaders, so we are stuck
with a fixed-function graphics pipeline. We can get exposure and white
balance correction this way, but is a bit of hack. The other colour
transforms need the photometrics mode, which does the colour transform
like the traditional preview (and changing the parameters causes a
potentially very long delay in this mode).

> >the only difference visible to me in the *chroma* around the preview is
> >that Fast Preview (FP) does not have the Output dropdown in the Preview
> >Options, that in the Traditional Preview (TP) is used to set the Output
> >to HDR/LDR.
> 
> It doesn't set the output of the project to HDR, it just implements 
> HDR merging and basic tonemapping in the Preview window itself.
> 
> >how about (STEP 1) merging them visually with one single dropdown,
> >Output, having three choices: FAST, LDR, HDR.

Also layout mode belongs in this menu, and maybe the control point
display mode as well.

> >That toolbar is actually the next thorn in my eyes. There are too many
> >buttons. We have a report that because of too long translation texts,
> >the toolbar is larger than the window and some actions are not available.
> 
> >How about (STEP 2) changing it into a menu?
> 
> Maybe, I would certainly like to free up some of the empty space to 
> make the preview canvas itself bigger, and a 'full screen (F11)' 
> mode has long been on the wishlist.  Definitely something that needs 
> mockups.
> 
> There are some buttons that do similar things, and some buttons that 
> are mutually exclusive, these are an opportunity to merge stuff 
> together.
> 
> I know we all hate the Office Ribbon, but I quite like the buttons 
> that are also pull-down menus - I don't know if wxwidgets implements 
> this.

There isn't a menu toolbar item in wxWidgets, but it does allow any
control to be added to a toolbar, so a combo box will do.
http://docs.wxwidgets.org/stable/wx_wxtoolbar.html#wxtoolbaraddcontrol

> This is all becoming imminent, the autocrop feature and the fast 
> preview will both add buttons to the Fast Preview window.

The GTK widget library will (optionally but by default) add a menu
containing toolbar items that don't fit on the toolbar on the edge of
it. I can't find a similar feature in wxWidgets, and it doesn't just
work on wxGTK. :-(

A normal menu bar seems appropriate, as we continue to add features to
the preview.

-James


--~--~-~--~~~---~--~~
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: possible memory leak in enblend & enfuse? (was: hugin-mac-2009.4.0-Beta1 for download)

[Lukáš Jirkovský]

Hi Stefan,

2009/10/8 Stefan Peter :
>
> Hi List,
>
> Sorry if the following is "all known by the old hands". Please feel free
> to correct me at your leisure, otherwise I may die dumb ;)
>
> I have downloaded the project in question, and here are some results.
> I used Hugin 2009.2.0.4461 on linux X86_64 with 4GB Memory and 8 GB swap
> for the first test. After creating a makefile from the pto, all tests
> have been conducted on the command line.
>
> o The original project worked fine in relatively short time (~ 30
> minutes, IIRC).
> o After adding an additional target (blended and fused equirect), the
> system started to thrash after about 1 hour and I had to cancel the job
> after a runtime of 9 hours without result.
> These tests where done using enblend 4.0-da9bc1a1ed87
>
> Afterwards, I switched to Linux X86_32 with 3GB of memory and 1 GB of swap:
> o The original project did not finish. An strace of the final enblend
> call (the one that creates the final equirect) showed that an mmap
> operation on one of the source files (400 MBytes!) failed.
> o Subsequent tests with various differently compiled enblend versions
> had some influence, but did not provide a remedy. I was not able to
> stitch the final pano, no matter what options i used for compiling
> enblend. But the point of failure shifted from Image 2 to Image 17 when
> disabling openmp and enabling image cache.
>
> As a preliminary statement, I'd say that
> o Enblending/enfusing large panos with 16bit tiffs is very memory
> intensive. If you don't have the RAM required, the final enblend step
> will fail with an "out of memory" message".
> o Having plenty of swap space is no cure: the system starts thrashing
> and will get unresponsive up to the point where you cancel the job
> voluntarily.
> o Although I did some valgrind and dmalloc tests, I could not find any
> leeks or problems beside the fact that all tiff files where accessed
> using mmap. This results in a memory footprint that mostly depends on
> the size of the input files.
>
> As a temporary fix, I would recommend to use "--disable--openmp" and
> "--enable-image-cache"  in order to limit the memory consumption.
> However, this has a negative influence on the runtime of enblend / enfuse.
> Another option is to reduce the size of the input images. It may be
> sufficient to use a compression for tiffs (I have not tested this), but
> reducing the color depth from 16 to 8 bit will have, most probably, the
> largest influence.
>
>
> The final solution for the memory problems in enblend / enfuse can only
> be an access method that does not rely on being able to access the
> _whole_ source files over memory maps. Without having looked at the code
> responsible for this (and not being a C++ programmer at all), I think
> that it should be possible to use a "window" (let's say 128 MBytes) for
> accessing at least the input files.
>
> With kind regards
>
> Stefan Peter
>
> >
>

Thank you very much for you in depth analysis.

Here are my thoughts. Could anyone verify them?
1. the problem occurs when image cache is disabled or the limit
exceeds (or almost fits almost exatly) memory size
2. the problem occurs when image cache is enabled but there is not
enough memory to write temporary to disk.

Both of them makes me think that it can be avoided by carefully
setting image cache to let's say available memory minus 100MB. So the
simplest solution may be setting apropriate image cache value at
runtime. But it would have it's drawbacks on systems with hot
pluggable memory.

Lukas

--~--~-~--~~~---~--~~
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: what is hugin doing to the exposure?

[don]

Thanks for the advice. I tried fiddling with the settings in EXPOSURES
tab, but that didn't give me any good result. The source photos are
JPEGs, straight from camera, both shot at 1/160 f11 @ ISO 100. To me
it seems like Hugin is doing some kind of exposure optimisation which
is not really necessary, hence the strange result. Perhaps it's worth
mentioning that I'm using the stitch assistent - I choose the two
photos from my hard drive, press ALIGN and when Hugin shows me
Panorama preview, it already looks strange (http://don.vn.cz/temp/repo/
hugin/huginpreview.jpg)

On 9 říj, 14:36, dkloi  wrote:
> On 9 Oct, 09:22, don  wrote:
>
> > Hugin makes something with them and
> > that results in A) very weird brightness/contrast and B) in visible
> > seams between the photos. The settings of the stitcher tab are 
> > here:http://don.vn.cz/temp/repo/hugin/panosettings.gif
>
> > here is the result from Hugin:http://don.vn.cz/temp/repo/hugin/panohugin.jpg
> > here is the result from photoshop's 
> > photomerge:http://don.vn.cz/temp/repo/hugin/panophotoshop.jpg
>
> > any tips? thank you.
>
> How did you take and process the input images? In camera JPG, or
> processed from RAW? You may not get the same output even though the
> exposure was fixed, depending on the exact processing chain.
>
> Try using the exposure optimisation tab, it'll fine tune the
> differences between the two image. It also means that you no longer
> have to lock exposure between taking source images, very useful if the
> scene has much different brightness in different parts. I've been
> using auto-exposure ever since this feature was introduced and only
> need to bracket if the contrast is too great within a single frame.
>
> Example:http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/Clarke_Quay_sma...
> I didn't need to bracket this 6+1+1 pano. Exposures ranged from 0.5s
> to 2s at f/5.6. I also optimised the RAW development of each
> individual frame to balance shadow and highlight detail. Exposure
> optimisation was able to match all these widely different exposed
> frames.
>
> Cheers,
> Daniel.
--~--~-~--~~~---~--~~
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: what is hugin doing to the exposure?

[Bart van Andel]

On 9 okt, 10:22, don  wrote:
[...]
> any tips? thank you.

Tip: you're still using a fairly old version. Version 0.8.0 has come
out not so long ago, and we are over 1000 svn commits further than
your current version. Newer versions might solve your issue, so please
try this first. You haven't supplied which OS you're using, but (links
to) instructions where to find recent builds for Windows, Linux or OSX
or compile them yourself can always be found on Yuv's blog [1].

[1] http://panospace.wordpress.com/downloads/

--
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 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: what is hugin doing to the exposure?

[dkloi]

On 9 Oct, 09:22, don  wrote:
> Hugin makes something with them and
> that results in A) very weird brightness/contrast and B) in visible
> seams between the photos. The settings of the stitcher tab are 
> here:http://don.vn.cz/temp/repo/hugin/panosettings.gif
>
> here is the result from Hugin:http://don.vn.cz/temp/repo/hugin/panohugin.jpg
> here is the result from photoshop's 
> photomerge:http://don.vn.cz/temp/repo/hugin/panophotoshop.jpg
>
> any tips? thank you.

How did you take and process the input images? In camera JPG, or
processed from RAW? You may not get the same output even though the
exposure was fixed, depending on the exact processing chain.

Try using the exposure optimisation tab, it'll fine tune the
differences between the two image. It also means that you no longer
have to lock exposure between taking source images, very useful if the
scene has much different brightness in different parts. I've been
using auto-exposure ever since this feature was introduced and only
need to bracket if the contrast is too great within a single frame.

Example:
http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/Clarke_Quay_small.jpg
I didn't need to bracket this 6+1+1 pano. Exposures ranged from 0.5s
to 2s at f/5.6. I also optimised the RAW development of each
individual frame to balance shadow and highlight detail. Exposure
optimisation was able to match all these widely different exposed
frames.

Cheers,
Daniel.
--~--~-~--~~~---~--~~
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: replacing make?

[Lukáš Jirkovský]

Hi Bruno,

2009/10/9 Bruno Postle :
>
> On Thu 08-Oct-2009 at 10:04 +0200, Lukáš Jirkovský wrote:
>>
>>> I know I'm not great at this stuff, but in the panostart tool there
>>> is a perl module that abstacts all the business of writing and
>>> escaping Makefile rules, i.e. you declare your intent with a list of
>>> input files, a list of output files, and the command(s) needed to
>>> generate those output files:
>
>>Yep, it's much cleaner. But I think this would be much more easy to
>>implement with XML or other markup language (eg YAML).
>
> Hugin needs to programatically define all the files it knows how to
> create and the commands for creating them somewhere.
>
> If you abandon 'make' then you need to find some way of recreating
> its functionality:
>
> Currently Hugin doesn't need to worry about ordering of commands, it
> just writes rules and then specifies the end target(s) it wants, you
> will need to write a dependency solver.

May be fun. I never did that :-D

>
> You would need to find some way to run commands in parallel as we
> can now with -j.
>
> Currently intermediate files are shared between targets, e.g. if you
> specify both kinds of Exposure Fused output, 'make' only remaps the
> images once with nona and reuses the files with the two different
> enblend/enfuse strategies.

I didn't think about that. AFAIK it only looks at the timestamps. The
question how difficult is to do it really multiplatform.

>
> Currently I can stop and restart stitching simply by killing the
> process, you will need to find some way of doing the same thing.  I
> can edit the alpha channel of one of the intermediate files then
> restart 'make' and it will pick up at the right point and only
> create the files that are effected by my changes.
>
>>I'd keep .pto format at least for storing image positions etc. But
>>with XML it would be much easier to store more informations to store.
>>I can think of storing informations about positions, stacks, it would
>>be possible to store informations about exposure
>
> We already store all this stuff in the .pto.

I admit that it wasn't a good example. Especially the one about
exposure. What I meant about positions was not "absolute" positions
like the ones in stored pto but instead something like "pictures a,b
and c are in stack" or "this picture is nadir".

>
> --
> Bruno
>
> >
>

It is said that every programmer tried to write his OS in his life.
I'm not that experienced (yet ;-) ) so this may be nice start.

I've just got an idea that I may reuse it in some school subject. This
term they allowed me to try to implement simple denoising algorithm
which I invented when I was drunk instead of the boring "standard"
task.

Lukas

--~--~-~--~~~---~--~~
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] what is hugin doing to the exposure?

[don]

Hi all,
I've come over this problem recently. I was using Hugin (with
autopanosift and enblend) about 2 years ago and for simple panoramas
(1 row of photos with fixed exposure) it worked perfectly. I installed
new Hugin recently (Version 0.7.0 (SVN 3465)) and when using the
stitching wizard, the results are very strange - even though the
exposure was fixed in both photos, Hugin makes something with them and
that results in A) very weird brightness/contrast and B) in visible
seams between the photos. The settings of the stitcher tab are here:
http://don.vn.cz/temp/repo/hugin/panosettings.gif

here is the result from Hugin: http://don.vn.cz/temp/repo/hugin/panohugin.jpg
here is the result from photoshop's photomerge:
http://don.vn.cz/temp/repo/hugin/panophotoshop.jpg

any tips? thank you.

--~--~-~--~~~---~--~~
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: Bug Tracker Policy

[sebastien delcoigne]

I don't think hugin will lose much by doing so. Most active contributors are
already registered.

On Fri, Oct 9, 2009 at 8:14 AM, Yuval Levy  wrote:

>
> Hi all,
>
> unless there are strong objections I intend to change the tracker policy
> to accept only bug reports from identified users.
>
> bug tracker statistics:
>
> * of 858 bug reports file overall, 341 were filed anonymously (40%).
>
> * of 145 open bug reports, 37 were filed by anonymous reporters (32%).
>
> many, too many, anonymous bugs are either incomplete and/or never
> followed up by the anonymous poster. time used to answer those bug
> reports is wasted.
>
> some of those anonymous bug reports are filed by users who are on
> Sourceforge, but forgot to log in.
>
> there is no drawback to being a Sourceforge member - no spam, no cost.
>
> i expect this to improve the quality of the bug reports.
>
> for the patches, we have had a few anonymous contributions, a couple of
> them in the last few days. There is an inherent problem with them. whom
> is Copyright assigned to? even worse: if the anonymous poster has copied
> code from somewhere else without permission, who is liable for the
> potential copyright infringement?
>
> last but not least, take a look at the quality and quantity of enblend
> bug reports to see what the result of this policy is.
>
> with this policy I hope to increase the quality of the report, and
> optimize the work of sorting them out.
>
> Yuv
>
> >
>


-- 
Sébastien

--~--~-~--~~~---~--~~
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: traditional preview

[Bruno Postle]

On Fri 09-Oct-2009 at 02:49 -0400, Yuval Levy wrote:
>
>does this mean that it is unlikely that the accuracy of the Fast Preview
>will be improved?

I think it is very dependent on the graphics hardware.

>and what was the result of the merger discussion?

..to do it later, after the Layout mode was done.

>the only difference visible to me in the *chroma* around the preview is
>that Fast Preview (FP) does not have the Output dropdown in the Preview
>Options, that in the Traditional Preview (TP) is used to set the Output
>to HDR/LDR.

It doesn't set the output of the project to HDR, it just implements 
HDR merging and basic tonemapping in the Preview window itself.

>how about (STEP 1) merging them visually with one single dropdown,
>Output, having three choices: FAST, LDR, HDR. The first one would be in
>FP, the other two would be in TP. The non applicable buttons in the
>toolbar would be grayed out?

Yes we need to group some stuff together.

>That toolbar is actually the next thorn in my eyes. There are too many
>buttons. We have a report that because of too long translation texts,
>the toolbar is larger than the window and some actions are not available.

>How about (STEP 2) changing it into a menu?

Maybe, I would certainly like to free up some of the empty space to 
make the preview canvas itself bigger, and a 'full screen (F11)' 
mode has long been on the wishlist.  Definitely something that needs 
mockups.

There are some buttons that do similar things, and some buttons that 
are mutually exclusive, these are an opportunity to merge stuff 
together.

I know we all hate the Office Ribbon, but I quite like the buttons 
that are also pull-down menus - I don't know if wxwidgets implements 
this.

This is all becoming imminent, the autocrop feature and the fast 
preview will both add buttons to the Fast Preview window.

-- 
Bruno


--~--~-~--~~~---~--~~
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: traditional preview

[Seb Perez-D]

On Fri, Oct 9, 2009 at 09:58, Bruno Postle  wrote:
>
> Is this the case even with the 'Photometrics' button enabled in the
> Fast Preview?

I must say I hadn't noticed this button. Gosh, if a frequent user like
me misses this, I can only imagine how daunting Hugin can look like
for a newbie... ;-)

Cheers,

Seb

--~--~-~--~~~---~--~~
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: traditional preview

[Bruno Postle]

On Fri 09-Oct-2009 at 06:48 +0200, Seb Perez-D wrote:
>>
>> The 'old' Preview is somewhat more accurate, it doesn't have the
>> problems the Fast Preview sometimes has with images getting
>> scrambled, but the main thing is that it is currently the only way
>> to show HDR stacks with tonemapping - It isn't clear that this
>> could be done at all in the Fast Preview.

>Also, the normal preview is the only one accurate enough for white
>balance and exposure correction. The Fast preview will show strange
>colours.

Is this the case even with the 'Photometrics' button enabled in the 
Fast Preview?

-- 
Bruno

--~--~-~--~~~---~--~~
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: Language Translation Patch, second attempt

[Yuval Levy]

Kornel Benko wrote:
> Am Thursday 08 October 2009 schrieb Yuval Levy:
>> Kornel Benko wrote:
>>> Why not use  FindGettext.cmake?
>> because to my understanding FindGettext.cmake finds the tools, not the 
>> library, and this is why FindGettextLibs.cmake does - at least on Linux 
>> and BSD.
> 
> I must have missed something. I did this for the lyx-project. No problems at 
> all
> with libraries.

maybe it is because the gettext libraries are used by so many packages 
that you already have them on all machines you tested with?

when I first changed the code, I did not even bother with CMake. I 
simply assumed that gettext was already used/found with wxWindows. THen 
on Windows, despite gettext in the SDK, I had an error. So I added 
FindGettext.cmake and looked what it generates. Still did not help 
Windows. So I googled further and found FindGettextLibs.cmake. I 
replicated the values that it created in Ubuntu to the Windows 
equivalent and bingo, it worked. The ultimate test would be to try it on 
a machine without gettext.

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 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: windows binary release

[Rogier Wolff]

On Thu, Oct 08, 2009 at 03:52:16PM -0400, Yuval Levy wrote:
> I thought the European Patent Office would not grant patents on
> software?

Because they get paid for the work they do, the patent office likes
"more patents". So they were a strong proponent of the practise. 

I believe there was a short period where they allowed software
patents and the legislators had not yet intervened. 

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
-~--~~~~--~~--~--~---