On Jul 11, 7:43 pm, Bruno Postle wrote:
[snip]
>
> So the black preview is a clue, do you still have the project file?
> It would be useful to know if hugin is systematically getting
> something wrong or if you accidentally clicked the preview to turn
> the panorama 'frame' 180°.
I didn't ha
On Jul 11, 7:52 pm, Bruno Postle wrote:
> It would be nice to fix this and I'm sure it is fixable, but this is
> basically why we still have the old preview around.
OK, thanks
Cheers,
Terry
--~--~-~--~~~---~--~~
You received this message because you are subsc
Hi these are all good ideas, but they are going to get lost on the
mailing list, they really need to be added as separate items on the
'feature request' tracker:
http://sourceforge.net/tracker/?group_id=77506&atid=550444
--
Bruno
On Sat 27-Jun-2009 at 18:43 +0200, Thomas Steiner wrote:
>
>So
On Sat 11-Jul-2009 at 19:35 +0200, Lukáš Jirkovský wrote:
>2009/7/11 J. Schneider :
>>
>>> Looking at these results it seems like a badly computed EMoR response
>>> curve. Can you try it with reseting camera response?
>> How can I reset it? The UI seemingly doesn't allow (wasn't that a
>> feature
2009/7/11 J. Schneider :
>
>> Looking at these results it seems like a badly computed EMoR response
>> curve. Can you try it with reseting camera response?
>> ...
>> Lukáš
> How can I reset it? The UI seemingly doesn't allow (wasn't that a
> feature request?).
> regards
> Joachim
>
> >
>
Just wri
> Looking at these results it seems like a badly computed EMoR response
> curve. Can you try it with reseting camera response?
> ...
> Lukáš
How can I reset it? The UI seemingly doesn't allow (wasn't that a
feature request?).
regards
Joachim
--~--~-~--~~~---~--~
2009/7/11 J. Schneider :
>
> Hi all,
> recently I'm experiencing a problem with colours, seemingly in
> connection with photometric optimization. Colour/brightnes values get
> screwed up, particularly in bright areas.
> For most of my quick-and-dirty handheld panos I follow the "standard"
> workfl
Hey Tom,
When I posted what valgrind reported I had not looked at the source code.
Now that I did some primary peeking around the call stacks, I'd have to
agree with you that the places valgrind is reporting should not be leak more
than a few bytes... In my test the call stack that reports 7.5MB i
Hi all,
recently I'm experiencing a problem with colours, seemingly in
connection with photometric optimization. Colour/brightnes values get
screwed up, particularly in bright areas.
For most of my quick-and-dirty handheld panos I follow the "standard"
workflow (at least standard in that it is
Thanks very much Andrew
I am a bit puzzled over the various memory leakage reports on APSCP.
I've now seen several valgrind reports that show "leaks" in the second
phase of APSC only, where keypoints from all images are processed,
giving the final control point list. Most of those are actually
On 30 Jun., 13:08, Yuv wrote:
> will get back to this thread / these ideas later on when I have more
> time.
Could you have a look? I'd be very curious!
And I can add another one:
* The preview window should have a "close" or "ok" button. When i do
something (eg crop) in the preview it is not
On Sat 11-Jul-2009 at 07:02 -0700, Tom Sharpless wrote:
>
>Sure. But I would prefer to store them as binary data ( 50x smaller &
>faster than XML ), with maybe a text option (10x) for people who
>really want to get the feature points into scripts.
A text option with one keypoint per line would b
Hi Yuv
On Jul 10, 11:55 pm, Yuv wrote:
> Hi Tom,
>
> On Jul 10, 2:31 pm, Tom Sharpless wrote:
>
>
>
> > On Jul 10, 8:00 am, Seb Perez-D wrote:
> > > On Fri, Jul 10, 2009 at 13:46, Bruno Postle wrote:
>
> > > > If I were stitching gigapixel panoramas (which I'm not), I'd want to
> > > > script
2009/7/10 Bruno Postle :
>
> On Fri 10-Jul-2009 at 21:52 +0200, Oskar Sander wrote:
>>
>>What's the state with all the projects currently?
>
> It's the mid-term evaluation this week, so now would be a good time
> to check out the code and give some feedback if you are interested.
>
> Below is the
Hi Bruno
On Jul 10, 2:57 pm, Bruno Postle wrote:
> On Fri 10-Jul-2009 at 11:31 -0700, Tom Sharpless wrote:
>
>
>
> >Now, this is an area where real improvement is both needed and
> >possible. It is a pure waste of time to look for control points where
> >you know there is no image overlap; and
Manolo wrote:
> Because of earth movement, I can't do really long exposure
> shots; perhaps about 30 seconds for small focal length lenses (~18 mm)
> and 5-10 seconds for medium ones (~50 mm). Moreover, I must take very
> high sensitivities 1600~3200 ASA to get something similar to an sky
> image
2009/7/11 Ryan Sleevi :
>
>> My experiences with profile-optimized code have been far less
>> positive. For me the speed-up varied from several percent (Enblend,
>> Enfuse, UFRaw) to actually slowing down the code (gcc).
>>
>> One explanation for my findings could be that I ran all of my
> My experiences with profile-optimized code have been far less
> positive. For me the speed-up varied from several percent (Enblend,
> Enfuse, UFRaw) to actually slowing down the code (gcc).
>
> One explanation for my findings could be that I ran all of my tests on
> very fast machines,
Hi Manolo,
Enfuse definitely averages as well. I build ImageFuser which is a MacOSX Gui
for enfuse and I have described this in the online manual. Take a look at <
http://members.home.nl/harryvanderwolf/imagefusermanual/> at chapter 5. It
is off course written to do it from ImageFuser, but from th
> There are two ways of running the Batch Processor on the
> command-line, one it to specify a series of projects:
>
> PTBatcherGUI project1.pto project2.pto project3.pto [...]
>
> The other is to specify project/output-prefix pairs:
>
> PTBatcherGUI project1.pto prefix1 project2.pto prefix2
On Fri 10-Jul-2009 at 21:13 -0700, Tduell wrote:
>
>I'm beginning wonder if the problems I'm uncovering with my Fedora 11
>X86_64 version of Hugin rc5 are due to some local build issue.
>Further testing of some projects that built OK with rc4 has uncovered
>a set of 3 images that have 'very bad fi
Just for fun I ran valgrind with autopan-sift-c on 2 small images and I had
roughly 7.5MB of lost memory. svn version 4014. The majority of the memory
was allocated from the following call stack but never freed:
==21097== 7,755,142 (44 direct, 7,755,098 indirect) bytes in 1 blocks are
definitely
On Fri 10-Jul-2009 at 20:52 -0700, Tduell wrote:
>
>enblend --compression 100 -w -f10020x5009 -o test-1.jpg
>enblend: no input files specified.
Hugin checks for photos outside the panorama 'frame' (or turned off
in the preview) and removes them from the stitching task.
You get this error when
On 10 jul, 20:06, Seb Perez-D wrote:
> On Fri, Jul 10, 2009 at 19:47, Manolo wrote:
>
> > Do you know if align_image_stack produce equally sized images?
>
> Yes. If not, you can play with the pto file that align_image_stack can
> produce.
I tested "aling_image_stack" a bit. It seems to work
2009/7/11 Tduell :
>
> Hullo All,
> I have just been doing a bit of testing of hugin-0.8.0_rc5, revisiting
> some sets of pics that hugin rc4 had been used to stitch.
> I have come across one set of 4 images that throws an enblend error.
> After the alignment stage I'm told 'very good fit' and the
On Fri, Jul 10, 2009 at 08:55:39PM -0700, Yuv wrote:
>
> > Now, this is an area where real improvement is both needed and
> > possible. It is a pure waste of time to look for control points where
> > you know there is no image overlap; and important to put as many well-
> > spread-out control p
26 matches
Mail list logo
