Hmm.
I'm not buying in on many of your arguments here.
I don't know enough about this particular change in Enfuse. Was the
decision to treat all pages of multipage TIFF files equally taken with
a clear understanding of the repercussions of that choice?
Certainly it is not the case that al
Am Dienstag, 14. September 2010 schrieb Dale Beams:
> It appears there is a problem. It's looking for those packages
> specifically by number when trying to install.
>
That's the problem :)
Kornel
signature.asc
Description: This is a digitally signed message part.
Would love to do this with a philosphere
> Date: Mon, 13 Sep 2010 20:11:00 -0700
> From: bbbri...@gmail.com
> To: hugin-ptx@googlegroups.com
> Subject: Re: [hugin-ptx] New tutorial, creating gores for assembling globes
>
> Nice tutorial, Bruno -- thanks! One of my youngsters is busy taping
>
Nice tutorial, Bruno -- thanks! One of my youngsters is busy taping
together a globe at this very moment.
Attached is a hugin template that will speed things up for those
interested in trying your technique. To use it, create a new hugin
project, and load 12 copies of your equirectangular im
Thanks Yuval, I think I've solved it. My system has 8GB of RAM. I
tried using a version of Enblend compiled without image cache and I
finally got a successful stitch! Thanks for your suggestions.
On Sep 13, 5:33 pm, Yuval Levy wrote:
> On September 13, 2010 04:35:36 pm Brandroid wrote:
>
> > Two
Hullo All,
I have only recently been playing about with dragging images into
rough alignment in the Fast preview window (FPW), prior to setting
control points and optimisation, so have not previously seen the
effect of a projection change at this this stage.
If I load a number of rectilinear images
On September 13, 2010 12:41:08 pm Erik Krause wrote:
> Am 13.09.2010 15:52, schrieb Yuval Levy:
> > Processing PSD layers is the default behavior of most modern
> > applications so why should the default for TIFF layers be different?
>
> Because these are no layers. Layers always have the same res
It appears there is a problem. It's looking for those packages
specifically by number when trying to install.
u...@ubuntu:~/src/hugin/hugin.build$ sudo dpkg -i
hugin-2010.3.0-Linux.deb
(Reading database ... 195430 files and directories currently installed.)
Preparing to replace hugin 2010.3.0
On September 13, 2010 05:07:00 pm Dale Beams wrote:
> This should work provided the >= is the lowest common denominator. For
> example, if your system is at (>= 0.2.0) and mine has 0.2.2 then it
> should check and say it's ok to install.
that's what I would expect too. Let's try it, and if it do
On Mon 13-Sep-2010 at 09:56 -0700, WaterWolf wrote:
Recently I tried creating one of those 360 degree 'little planet'
stereographic projections that you can find in the gallery on the
hugin homepage. So I went out into my garden and took a 360 degree
matrix of images. It took 42 images to cover
Hi,
On September 13, 2010 12:56:28 pm WaterWolf wrote:
> So issue 1: The resulting image is unnecessarily large for my purposes
> and so took much longer to generate than it needed to. What is the
> best way of reducing the size of the final image and speeding up the
> process? It would also be ni
On September 13, 2010 04:35:36 pm Brandroid wrote:
> Two other pieces of information that may be important: The remapped
> images from Nona are all as they should be (proper bit depth, properly
> mapped). I also successfully stitched two of the images in this pano
> at 10k by turning off the other
This should work provided the >= is the lowest common denominator. For
example, if your system is at (>= 0.2.0) and mine has 0.2.2 then it
should check and say it's ok to install.
Dale
On Mon, 2010-09-13 at 22:46 +0200, Kornel Benko wrote:
> Am Montag 13 September 2010 schrieb Dale Beams:
> > Re
Am Montag 13 September 2010 schrieb Dale Beams:
> Reviewing CMakeLists.txt, I've noticed:
>
> SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libpano13(>=2.9.17), libpost2c2,
> libglew(>=1.5), freeglut3, libboost-filesystem(>=1.38.0), liblcms1,
> libopenexr6, libtiff4")
>
> Which appears to set debian package
Two other pieces of information that may be important: The remapped
images from Nona are all as they should be (proper bit depth, properly
mapped). I also successfully stitched two of the images in this pano
at 10k by turning off the other 6.
On Sep 13, 3:39 pm, Brandroid wrote:
> I'm trying to s
I've tried almost every single pano-tool on the web to accomplish
this. SO, does anyone know of a solution that can dewarp two 180
degree fisheye images and combine them? It doesn't need to be perfect
on the edges, just dewarped and a flat JPEG.
--
You received this message because you are subscr
I'm trying to stitch a 10,000 pixel wide pano as a merged and blended,
32 bit EXR from a set of EXR source images, but the resulting image is
always completely black. I've had success with the same images when
stitching at lower resolutions (2k, 4k, 8k, 9k), and I can stitch a 8
bit image at 10k wi
Reviewing CMakeLists.txt, I've noticed:
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libpano13(>=2.9.17), libpost2c2,
libglew(>=1.5), freeglut3, libboost-filesystem(>=1.38.0), liblcms1,
libopenexr6, libtiff4")
Which appears to set debian package dependencies at >= for certian
packages. I assume this can be
Hello,
I'm quite new to hugin but so far I've generally been getting
excellent results creating standard panoramas.
Recently I tried creating one of those 360 degree 'little planet'
stereographic projections that you can find in the gallery on the
hugin homepage. So I went out into my garden and
Am Montag 13 September 2010 schrieb Dale Beams:
> Earlier I had indicated using echo from a script to read in the
> dependencies. Someone mentioned that this would not work? Is this
> because of the location of the line in the CMakeLists.txt?
It was me.
1.) Location
2.) Syntax
> I'd have to dig
Earlier I had indicated using echo from a script to read in the
dependencies. Someone mentioned that this would not work? Is this
because of the location of the line in the CMakeLists.txt?
I'd have to dig around for the e-mail, but someone indicated that
-DCPACK_BINARY_DEB:BOOL=off/on could be
Am 13.09.2010 15:52, schrieb Yuval Levy:
Processing PSD layers is the default behavior of most modern
applications so why should the default for TIFF layers be different?
Because these are no layers. Layers always have the same resolution and
bit depth. TIFF pages don't. Gimp uses TIFF pages a
Am Montag 13 September 2010 schrieb Dale Beams:
> I'm getting ready to build this afternoon. Where are we at for CMake?
> Questions are ...
>
> 1. Does CMake determine the min dependency, and can evaluate and confirm
> the correct one without hardsetting version numbers for the
> dependencies?
N
I'm getting ready to build this afternoon. Where are we at for CMake?
Questions are ...
1. Does CMake determine the min dependency, and can evaluate and confirm
the correct one without hardsetting version numbers for the
dependencies?
2. Can -DCPACK ... RPM=on be turned off by default? This wou
> Hi all,
> When compiling , I get the message:
> 'LAPACK not available, LU will be used for matrix inversion when
> computing the covariance; this might be unstable at times'
> I've seen no instructions for Windows on whether LAPACK is
> recommended, or how to get it if it is. Anyone have experien
On September 12, 2010 05:01:21 am Erik Krause wrote:
> Am 12.09.2010 08:51, schrieb Harry van der Wolf:
> > You can also use tiffsplit to split your tiffs first.
>
> Hmm, an additional step that wouldn't be necessary if the programmers
> would have thought a bit further...
You might be surprised
On Sep 12, 9:11 pm, Aron H wrote:
> On Sep 11, 8:58 am, "T. Modes" wrote:
>
> ...
> Hi thePanz,
> I will definitely share my build when I can confirm that I can build
> x64 too. In the next day or two!
> Aron
Hi all,
When compiling , I get the message:
'LAPACK not available, LU will be use
i agree this should be an option, not a feature that can't be turned
off.
batch thru imagemagick does NOT seem like a reasonable solution ;-)
On Sep 12, 11:01 am, Erik Krause wrote:
> Am 12.09.2010 08:51, schrieb Harry van der Wolf:
>
> > You can also use tiffsplit to split your tiffs first.
>
Dale Beams wrote:
> ametz...@downhill.at.eu.org Date: Sun, 12 Sep 2010 17:56:44
[...]
>> One of or probably the strongest point of Debian is that we have a
>> policy that describes in great detail how packages must look like to
>> make it possible that the packages work together and upgrade
>> cor
On Sun, Sep 12, 2010 at 8:14 PM, Erik Krause wrote:
> Am 12.09.2010 17:18, schrieb T. Modes:
>
> I assume, that the builder has compiled libtiff without this change.
>> Please check your libtiff.
>>
>
> In this case: thePanz, could you use a different source for the binaries in
> the installer?
30 matches
Mail list logo
