Am 03.06.2011 08:29, schrieb kfj:
Hi all!
I have some questions about cpfind:
- if my images have been taken with a stereographic lens (I use the
Samyang fisheye), will cpfind notice the fact (it's in the input pto)
and omit remapping the image, even though the hfov is above the
remapping
Hi Bruno,
Am 07.04.2011 20:20, schrieb Bruno Postle:
On Wed 06-Apr-2011 at 23:54 -0700, Jeffrey Martin wrote:
If I knew what a standard response curve looked like as EMoR parameters
then I would suggest that Hugin used it as a default.
Currently we use 0,0,0,0,0 which doesn't correspond to
Hi Lukas,
Please review them and comment on them, because I'd like to send
them to the upstream soon. I'm not sure about copyrights in some cases
(eg. canvasSize patch) but I think most of it is Pablo's work. I'll look
it up in the subversion history.
great, looks good, feel free to submit
Hi kfj,
Am 04.03.2011 10:23, schrieb kfj:
On 3 Mrz., 19:26, Pablo d'Angelopablo.dang...@web.de wrote:
But just throwing in a new free lunch feature without
documentation for everyone to figure out how it works by trial and
error isn't what I consider good style. For example, it took me quite
Hi Kay,
Am 03.03.2011 18:34, schrieb kfj:
Hmmm... I'm very much in two minds about features like this. I feel
that image processing functionality should be kept out of hugin. Of
course we need to align the images photometrically, but manually
finetuning the white balance is close to where I'd
Am 13.02.2011 16:25, schrieb kfj:
On 13 Feb., 11:13, Jeffrey Martin360cit...@gmail.com wrote:
I was thinking also...
for panos, the centers of images usually do not overlap.
isn't searching the WHOLE of images a big waste?
There is another aspect which becomes more important with fisheyes
Hi Jeffrey,
Am 07.02.2011 23:10, schrieb Jeffrey Martin:
I'm quite swamped with real work right now, so I don't have time to
work on cpfind for the next weeks.
HI Kay,
a bunch of nice ideas!
comments below
On Monday, February 7, 2011 3:34:25 PM UTC+1, kfj wrote:
If I could tell the CPG
Hi Jeffrey,
Am 27.01.2011 23:42, schrieb Jeffrey Martin:
I'm trying to build hugin from source, on Ubuntu (I installed Ubuntu today)
After some missteps with getting the latest pano13 compiled, I finally
got to building Hugin, but now I'm getting this error:
[ 36%] Built target flann_cpp_s
Hi Kay,
Am 24.01.2011 18:12, schrieb kfj:
J. Martin asks
so your standard 6 shots around and 1 shot up pano (fullframe fisheye) where
the up shot has been rotated to landscape orientation by the camera - this
should not pose any problems for hugin?
I'd say - not really a problem, but if the
Hi Can,
Am 24.01.2011 09:20, schrieb Can-C. Dörtbudak:
Hi guys,
could anyone please tell me, where i can get a development Version of
hugin like 2010.5 something?
As far as I know, nobody produces nightly builds for windows. Some
outdated information on building hugin for windows is
Hi Yuv,
Am 23.01.2011 15:10, schrieb Yuval Levy:
Michel's test/challenge was for this to work out of the box and I did not
have time to investigate further. I realize now when running Exiftool that it
reports 0mm focal distance; and that Hugin sets the focal length to 50mm by
default, even if
Hi all,
panomatic and thus cpfind use a RANSAC step for outlier removal. This
used to be based on a homography, which works ok for non-wide angle
images. It breaks for fisheye images, here a large error tolerance must
be choosen, and this results in a rather weak outlier check for wide
angle
Hi Carl,
On 21 Jan., 09:07, Can-C. Dörtbudak doertbu...@googlemail.com wrote:
same problem for me. I've tried the fullscale option and sieve1size
etc. as well. I can't find control points in the pictures of my
walimex fish eye. If somebody wants to verify this here is the link to
the
Am 20.01.2011 10:48, schrieb Jeffrey Martin:
Hi Pablo,
Thanks for the explanation. A couple questions and clarifications:
On Wednesday, January 19, 2011 10:46:59 PM UTC+1, Pablo d'Angelo wrote:
Yes, it should. I have seen that the circle in your example was a bit
offset. This might
Hi Bloddy,
Am 17.01.2011 17:52, schrieb bloody tomatoes:
Hello,
I'm reading this http://wiki.panotools.org/Cpfind and i have a few
questions:
1) The default settings of cpfind - this is the best setting for normal
(non-fisheye) images? or it's probably good enough but as cpfind is
very new,
Hi Jeffrey,
Am 19.01.2011 22:23, schrieb Jeffrey Martin:
Thanks Pablo for the detailed explanations.
By the way, with these photos, I am still getting CP's outside the
cropping circle. does anyone have any idea why that would be the case?
www.vrlog.net/temp/cpfind-pablo/bad-cp-shaved-nikkor.zip
Hi Kay,
Am 19.01.2011 10:04, schrieb kfj:
hg export 4852:bf77427fe623 4853:9de97bcfd3b2 patch4853
gzip patch4853
I hope this is just what you need and convenient enough to use. Echoes
welcome.
From http://mercurial.selenic.com/wiki/Export, it seems that hg bundle
is the preferred way for
Hi Thomas,
Am 18.01.2011 19:24, schrieb T. Modes:
But I found an issue: I can not access the image variables of
SrcPanoImage like getImage(0).getYaw() and so on
Thats probably because these functions are defined using some macros
inside Panorama.h. Maybe swig needs to call the C
Hi Tomato,
On 17 Jan., 16:03, bloody tomatoes bloodytomat...@gmail.com wrote:
using the latest hugin (2010.4) and cpfind, i have many control points
outside the circle used to crop my images.
the cpfind included in 2010.4 unfortunately performs quite badly on
fisheye images. Yesterday I did
Hi all,
unfortunately, there is still a bug in cpfind, which prevents it from
processing fisheye images with a fov 170 degrees or so.. I'm working
on a fix.
ciao
Pablo
Am 17.01.2011 22:13, schrieb bloody tomatoes:
Harry, this build [OSX] New hugin-mac-2010.5.0-4854_d29b1d6da0e0 incl.
Hi Tomato,
Am 17.01.2011 18:12, schrieb bloody tomatoes:
Hi Pablo,
I have sent you the files. Let me know if you received it ok.
I got the files, thanks. I did fix some cpfind issues with circular
fisheye images. With the new fixes I didn't get points outside the crop
circle.
Btw. you
Hi all,
Am 25.12.2010 19:26, schrieb Yuval Levy:
I have started a tracker ticket:
https://bugs.launchpad.net/hugin/+bug/694329
I have improved cpfind to be much more reliable when using fisheye
images. Most tests so far have been positive, except for images with
very little overlap. If
Hi Tom,
Am 16.01.2011 23:28, schrieb Tom Sharpless:
Great.
Now please, publish a URL for a current windows release package.
Everyone says it exists, no-one will say where :-
I'm currently running 2010.2. Got cpfind from a zip of 2010.3 (bin
directory only) that has defective Hugin, but working
Hi Kay,
Am 10.01.2011 12:39, schrieb kfj:
I have set out creating a scripting interface for hugin.
Great, I think that hugin can benefit greatly from such an interface,
both for custom utilities, as well as quick prototyping of new ideas.
So the next thing that I feel needs to be done
Am 06.01.2011 19:03, schrieb kfj:
Bruno, thank you for your advice. I have started out on a new project
towards the goal of eventually providing a scripting interface for
hugin,
that would be really nice! I once tried with boost::python, but I hit
some strange roadblocks, which prevented me
Am 04.01.2011 20:24, schrieb dmg:
oh, if I remember correctly, nona does multithreading. But I am not an
expert, so I'll let Pablo and those who know nona
describe it.
Yes, nona is multithreaded. As far as I know, ptmender doesn't perform
the photometric (vignetting white balance)
Hi all,
I have found that the integrated control point creator fails when images
are rotated with respect to each other, which might be problematic with
handheld and wide angle/fisheye images. I haven't tried many panos, so
I'm not sure if I just was unlucky or if it only affects a few
Hi Matthew,
Am 16.12.2010 18:49, schrieb Matthew Gates:
An example DSS plate .tgz cab be found here:
http://porpoisehead.net/misc/S357.tgz (13 meg)
There are many of these files 1792 of these files - the one above is
the smallest. Total size ~65 gig! I love me some hefty data. :D
Is
Hi Markku,
Am 05.06.2010 13:40, schrieb markku.kol...@iki.fi:
On 5 kesä, 09:33, Lukáš Jirkovskýl.jirkov...@gmail.com wrote:
OpenMP isn't supported in the Express edition of VisualC++, you need
at least the Professional version to use it:
Am 04.06.2010 15:42, schrieb Lukáš Jirkovský:
Hello,
today I decided to improve the performance of deghosting in hugin.
First try using SSE didn't work really well [1].
Did you check that your data was properly aligned for use with SSE?
Second one using
OpenMP show noticeable increase of
Hi Harry,
Harry van der Wolf schrieb:
Hi,
2010/4/23 Pablo d'Angelo pablo.dang...@web.de
mailto:pablo.dang...@web.de
I had already built a debug version. I hoped that would create a better
crash report.
First a gdb run starting panomatic (I renamed it back) without parameters:
Hmm
Hi Harry,
Harry van der Wolf schrieb:
Hi,
I tried to file a bug via the tracker on
https://code.launchpad.net/~pablo.dangelo/hugin/panomatic-lib;, but I
can't find how to do that. Has the Launchpad bug tracker been activated
for panomatic-lib?
I haven't looked at the bug tracker setup on
Bruno Postle schrieb:
On Mon 19-Apr-2010 at 14:17 -0700, Battle wrote:
So where are my bottle necks? The optimization process in hugin
proper in the 32 bit build seems slow. On smaller projects of 10 to
20 images the optimization tab can take almost as long as actually
stitching the
Antoine Deleforge schrieb:
Hi Antoine,
Thanks for your clarification Bruno. So if I understood well, the idea
here is just to assume that consecutive pictures will likely overlap,
since users usually take pictures consecutively along rows/columns while
shoting their panorama.
What I was
Hi Yuv,
Yuval Levy schrieb:
Hi Pablo,
On March 20, 2010 02:41:16 am Pablo d'Angelo wrote:
I think that moving to mercurial would good, and now is the right time
to do so.
OK, let's try to fix what still needs fixing.
I can see the value in keeping a subversion repository, but I dislike
Hi Bruno,
Bruno Postle schrieb:
On Thu 18-Mar-2010 at 21:00 +0100, Lukáš Jirkovský wrote:
I've just got a great news – it seems that hugin was accepted[1] for
the Google summer of code 2010!
Great!
We have two or three mentors volunteered so far, we need more at least
to do backup roles.
Hi Yuv,
I think that moving to mercurial would good, and now is the right time
to do so.
Yuval Levy schrieb:
On March 19, 2010 01:55:36 pm T. Modes wrote:
It's easy to lock SVN making it read-only and allowing commits only from
an hgsvnpush cron job.
But then the svn repository is only a
Hi Bruno,
Pablo d'Angelo schrieb:
I'm willing to be a backup admin and backup mentor. I won't be available
at mid to end of June.
I tried to apply as a mentor for hugin at http://socghop.appspot.com,
but I couldn't find a way to do so. Hugin is not listed when I select
Apply to become
Hi Aron,
Aron H schrieb:
I've just been successful in building on Win XP with VS 2005, and
started playing with panomatic_nopatent :). With the default settings
from the readme, on a 2 row, 360 panorama, I'm finding a number of
false matches. I'd like to provide helpful input, or other help,
Robert wrote:
=== Announcement: Photoropter lens correction library ===
Seems to be very similar to lensfun:
http://lensfun.berlios.de/
I think lensfun is really good, however, it never really got of the
ground nicely (its used by ufraw though), because adding new lenses etc.
is not as
hdrpano wrote:
I had the same problem a month ago. Concluded that nona is unable to
preserve hdr when remapping. Let me know if you figure this out...
It should work, if you set the Camera response type to linear.
(Lens tab, photometric sub tab).
cheers,
Pablo
--
You received this
Zoran Zorkic wrote:
On Jan 29, 12:01 am, Bruno Postle br...@postle.net wrote:
In practice Hugin doesn't cope with any of these '=' references
pointing to an image with a later number, so image 0 should never
have any. This sounds like a bug, do you only see this with the
trunk?
Only with
allard wrote:
I did a first attempt to build on Wndows XP and that was not
successful. Let me describe the steps.
-Downloading and installing bazaar from their webpage and getting the
trunk trough their GUI went smooth.
-I ran CMake (i use 2.8.0 RC5 GUI), which went smoothly except that I
had
Hi Matthias,
Matthias Kabel wrote:
Hello,
I just tried to update my libpano13 and hugin installation with libpano13
revision 1214 there is an error with hugin.
hugin: queryfeature.c:376: panoProjectionFormatCount: Assertion
`sizeof(panoFormatNames) == 20 * sizeof(int)' failed.
I fixed
Hi all,
Jean-Luc Coulon (f5ibh) wrote:
For me [tm] 1203 works
1214 doesnt.
assert(sizeof(panoFormatNames) == PANO_FORMAT_COUNT * sizeof(int));
^^
This is the offending line and present on 1214
This line was existing in 1202, has been removed in 1203.
It is not present from
Hi Bruno,
Bruno Postle wrote:
So here is my recipe for efficiently matching a multi-row panorama:
1. First use ptochain to connect all consecutive photos in the project,
the result will be a project with one or more groups of connected photos
- With luck each of these groups will correspond
Hi Harry,
On 3 Jan., 13:08, Harry van der Wolf hvdw...@gmail.com wrote:
Hi Pablo,
Many thanks for this achievement. Even though the current autopano-sift-c
and panomatic doe their job very nicely, it is really getting a pain in the
backside to have to deal with this patent/license
Hi all,
I have taken some time in the last few days and continued my work on on
a patent free control point detection algorithm, which I haven't had
time to continue since I started it in March 2009.
I have taken panomatic as base, as it is a relatively clean code base
(compared to the
D M German wrote:
FYI,
Adding Tr parameters to the script will restrict the output of the any
remapped image be at most 180 degrees, even if it can spawn longer (such
as most of the cylindrical panoramas).
I am not sure why this happens yet.
Only images that have nonzero TrXYZ should be
bruno.postle wrote:
On Dec 21, 2:51 pm, Mick Crane mick.cr...@gmail.com wrote:
Common point
'shared features' is another one I like.
In photogrammetry, what we call control points is called tie points. I
like that term it more than control points, but panotools has used
control point, and
Rogier Wolff schrieb:
On Wed, Oct 28, 2009 at 10:56:08PM +0100, Pablo d'Angelo wrote:
Implementations of Minimum cut algorithms are widely available, for
example from the boost graph library or
http://www.cs.ucl.ac.uk/staff/V.Kolmogorov/software.html (maxflow v2.2
is GPL licensed).
I
Hi Andrew,
Andrew Mihal schrieb:
Hi Pablo,
Can you elaborate a little on your criticism of snakes?
Is the problem:
- That the polyline formulation cannot describe a good solution at all?
A polyline can describe all possible solutions, if it is fine enough.
- That the size of the
Hi Andrew,
Andrew Mihal schrieb:
Hi,
I suspect a problem in the vectorization of the seam lines.
Actually, the approach of using vectorized seam lines is a relatively
complicated process. Additionally, snakes are not particularly well
known to find good global solutions. I think a
Oskar Sander schrieb:
Ok! I think one of the big challenges with this is to visualize the
paramters in some some of tutorial/online manual.
Indeed. But so far I'm not sure if I have found the right parameters...
The camera plane is Z=0,Xc,Yc right?
Yes.
How do you then describe
Hi all,
I have just commited some experimental extension to the TrX, TrY, TrZ
parameters for mosaicing images of a planar scene to the libpano13 SVN trunk
One of the main drawbacks of the Tr* parameters is/was that the images
had to be located on plane straight ahead of the panorama. This is
allard schrieb:
no panomatic is definitely not in the SDK. and it adds short term
problems - until the patent (SURF) expires.
I think we need to follow the lead of the Mac OSX builds and make
separate installers for the CP generators. But I also think that this
should come after the
Hi Oskar,
For these two mosaics I did this by forcing only XYZ optimization first,
then adding angles in the next run. That converged nicely, and exposed a
few CP that were completely off. Other things i can think of are:
* Observed initial values - Some UW mosaics uses ROV that captures
Hi Matt,
Matt Williams wrote:
2009/9/22 Pablo d'Angelo pablo.dang...@web.de:
At work, we have a full frame camera system ( 3xCanon EOS-1d) with 50 mm
lenses. Flying that at 1000m gives reasonable detail when looking
straight down and the imaged area is much larger than with your example
Brent wrote:
Pablo,
Now that I think about it, there is something odd in the fact that
doing a multi-step optimization by changing which variables are
optimized works any better than a full optimization.
Maybe my explanation in the previous email was a bit misleading. What I
meant is to
Hi Brent,
Brent schrieb:
From a purely empirical point of view, it appears that there is some
undesirable linkage between these parameters that makes the
minimization process get trapped into local minima and have difficulty
finding a solution in some cases.
I have had the same problem,
Hi Oskar,
did you also try panomatic? It might work better than autopano-sift-c.
ciao
Pablo
Oskar Sander schrieb:
My idea is to run CP finding on preprocessed images, and then
substitute these for the originals before the stich step.
I'd like to understand the APC inner
Jim Watters schrieb:
Pablo d'Angelo wrote:
If I understand correctly both models will align an image so it is on
the same plane as others.
After some more reading of the code, I'm quite sure that the tilt can
only work well with rectilinear input images. If only that case
Hi Bruno,
Bruno wrote:
Works for me, I also found that I can successfully optimise lens
parameters:
http://www.flickr.com/photos/36383...@n00/3947727801/
..so when can we have this in Hugin? ;-)
It doesn't make sense to add these the the trunk, as it would complicate
the merging of
D M German wrote:
Pablo dAngelo twisted the bytes to say:
Pablo I'm still struggling to understand the geometric interpretation of
the Tx,Ty,Tz angles and the Ts parameters.
hi Pablo,
I have created this document to explain the use of the three parameters.
Thank you for the pdf, it
Hi Matt,
This is the method I had been using before, but obviously without the
Tilt parameters and so it really struggled.
Actually, I played around a little, and I wasn't satisfied with the tilt
parameters, so changed libpano to allow estimate the X,Y and Z camera
position (assuming a
Matt Williams wrote:
2009/9/22 Oskar Sander oskar.san...@gmail.com:
Hi Matt,
If you experiment on this further, it would be really sweet if you did a
tutorial writeup here even if it doesn't work out perfect right now.
I absolutely will. This won't be the last time that OSM hire a plane
Stefan de Konink wrote:
We did; we have a rectifying program, and like I posted before I was
pointed myself to efoto. From there on we can use qgis and mapserver for
final positioning. Come and idle in #osp on oftc ;)
Do you have a procedure that works nicely for the large amount of image?
Matt Williams wrote:
2009/9/22 Pablo d'Angelo pablo.dang...@web.de:
Hi Matt,
This is the method I had been using before, but obviously without the
Tilt parameters and so it really struggled.
Actually, I played around a little, and I wasn't satisfied with the tilt
parameters, so changed
Pablo d'Angelo schrieb:
Matt Williams wrote:
2009/9/22 Pablo d'Angelo pablo.dang...@web.de:
Hi Matt,
This is the method I had been using before, but obviously without the
Tilt parameters and so it really struggled.
Actually, I played around a little, and I wasn't satisfied with the tilt
Hi Matt,
The general workflow for proper orthorectification (as used by the
professionals) is:
1. Measure some ground control points (GCPs) in the images. These
associate an image point with a 3D world position (lat, lon, height). If
a full bundle adjustment is used, this is not needed for
Pablo d'Angelo wrote:
Hi Matt,
The general workflow for proper orthorectification (as used by the
professionals) is:
1. Measure some ground control points (GCPs) in the images. These
associate an image point with a 3D world position (lat, lon, height). If
a full bundle adjustment
Hi Yuv,
6. vigra-1.6 (Lukáš): it has been decided to push the changes upstream;
wait for vigra-1.7 with the changes; then make Hugin work with
[vigra]-1.7. @Lukáš and @Pablo: what does it take to prepare Lukáš' work
to go into vigra; and how do we make it available to vigra?
I'll make a
Bruno Postle wrote:
Cpclean is ready to go in as far as I'm concerned, the only question
is do we run it automatically with the Align... button?:
If in doubt: Make it configurable. I guess that it should be done for
people that use the automatic method. However, if somebody adds some
Hi Lukas,
Lukáš Jirkovský wrote:
Hi,
while working on my GSoC project I've noticed that current OpenEXR
implementation has only 4 bands. This makes it's usage inconvenient
sometimes because it makes everyone to use ImportImageAlpha even when
alpha is not necessary. It seems that OpenEXR
Lukáš Jirkovský wrote:
Hello,
there's one part of hugin code which I'm thinking of. I have many
questions about it. It's code in src/hugin_qtbase.
Is it alive? Is there anyone who actually cares about it? For now it seems
dead.
This is part of Ippei' GSOC 2007 project, where he did a
Yuval Levy schrieb:
Hi all, particularly develoeprs,
- vigra-1.6 (Lukáš' patch from before 0.8.0)
I think this is best done by adding the hugin changes to the main vigra
lib. Most changes are related to the vigra impex functinality, and it
shouldn't be hard to get them integrated (Maybe
Kornel Benko wrote:
Am Mittwoch 09 September 2009 schrieb Ryan Sleevi:
As you indicated in your follow-up, the CMAKE_BUILD_TYPE is what controls
whether or not the compiler is set to be optimized for release mode. For
the Windows platforms, all the build types are exported into a
Hi Yuv,
Yuval Levy wrote:
James Legg wrote:
hugin-ptx is the only list linked to on hugin.sourceforge.net, and
sourceforge makes the lists it hosts difficult to find. Could all the
lists be listed there and at sourceforge.net/projects/hugin/?
I am not sure what can and can't be listed on
Hi all,
This description is correct. Note that align_image_stack was really
written more like a proof of concept and is not really well optimized.
Actually, the implementation of the normalized cross correlation in
hugin is very basic and thus quite slow. Replacing it with a properly
Hi James,
Just a quick note below:
James Legg wrote:
It probably wouldn't take too long to combine this with the OpenGL
preview, and might even be less work than putting it in its own tab.
Sounds good!
I don't know about animating the transition between preview and layout
mode though.
Lukáš Jirkovský schrieb:
2009/4/4 Faruq writefa...@gmail.com:
Hi,
you should take a look at the:
src/hugin1/tools_vips/*
src/hugin1/tools/img2vips.cpp
These are some toy programs I wrote some time ago.
these are unfinished results from the Google Summer of Code project to
integrate VIPS
Hi Peter,
Peter Gawthrop schrieb:
Hi Pablo,
I'd like to have a look at this. Could you tell me exactly where the
current algorithm lives within the hugin tree?
The main correlation happens in:
src/hugin_base/vigra_ext/Correlation.h
vigra_ext::PointFineTuneRotSearch()
Hi Lukáš,
Lukáš Jirkovský wrote:
Hello,
I'd really want to participate, but I've not yet decided what should
be my application. think about two things:
1. Making deghosting act more like as a library. This probably would
ease integration to enfuse. The second part would be adding
Hi Peter,
Peter Gawthrop wrote:
As far as I know, Fine-Tune is unaware of lens effects. If so, it seem
that the general solution would be to make Fine-Tune aware of the lens
and, for example, map the two small areas used by Fine-Tune to the
centre of the image for processing and then map
Yuval Levy schrieb:
Guido Kohlmeyer wrote:
Meanwhile I found huginApp::Get()-GetXRCPath(), which is the same.
is there a reason to have twice the same thing, or is this a redundancy?
if it is, from which class does it make sense to get the XRCPath? from
huginApp.h or from MainFrame.h?
Hi Bruno,
Bruno Postle schrieb:
On Wed 25-Feb-2009 at 14:19 +0100, Harry van der Wolf wrote:
During gsoc 2007 Zoran Mesec created/worked on matchpoint: the patent free
keypoint detector. As far as I'm aware matchpoint works fine, but still has
problems dealing with transparency masks.
True
Lukáš Jirkovský schrieb:
Hello,
As I'd like to show that I'm still not bored hacking hugin I've done
some tweaks to EXR implementation in Hugin, unfortunately none of them
is tested.
1.) workaround for bug causing clipping of some data (changes in
ExrEncoderImpl::nextScanline() and
tennevin yves wrote:
I have been trying to build hugin under native mingw,
I am trying first with hugin7.0 source, since it's supposed to compile.
I managed to compile the dependencies
Now I am getting some errors when wxWidget is invoved in the make.
getting errors like
`wxConvISO8859_1'
Hi Lukáš,
I had a quick look at the patch, and it looks good (I haven't had time
to do any testing...).
ciao
Pablo
Lukáš Jirkovský wrote:
No response? So if nobody will complain about it, I'll put it into the
trunk tomorrow.
Hi Yuv,
Yuval Levy wrote
I've tested quickly hugin_hdrmerge in Windows. I applied your two
patches (30/Jan and 31/Jan).
The good news is that it builds and it seems to get further than it used to.
The bad news is that it still crashes. I am trying to merge three 16bit
TIFF images of
Yuval Levy schrieb:
Hi Pablo,
Pablo d'Angelo wrote:
Actually, hugin_hdrmerge assumes that images where the gray values
correspond to intensity values
Aha.
(ie.
if corresponding pixels are exposed well, they should have the same
value). Suitable images are the .exr files
Daniel German schrieb:
Now, regarding hugin. Some time ago I modified libpano to report the
projections
available to hugin. The idea was that hugin does not need to hard code the
projections, but rather can query them from libpano. This meant that
you just need to recompile, install
Hi Guido,
Guido Kohlmeyer wrote:
Dear Yuv,
I modified the license text slightly and build a new setup file.
It can be found at
http://hugin.panotools.org/testing/hugin/hugin-0.7.0_win32-setup.exe
the MD5 checksum is available as well
Hi Bruno,
Bruno Postle wrote:
Congratulations to everyone responsible for this release!
Thanks a lot for doing the final hard work for making the release
possible. Also thanks to all other developers who made this happen. I
have been very busy with day time work and other commitments
94 matches
Mail list logo
