Re: [hugin-ptx] Hugin computing power

"multiblend is exceptionally fast compared to enblend (maybe 10x to 20x faster, as I recall)." It's not a fixed increase. Enblend has O(n^2) runtime (it scales with the square of the number of pixels) whereas Multiblend is linear. I don't know of anyone who's tried a terapixel blend with both,

[hugin-ptx] Re: Problem with bright splodge in panorama from enblend.

Have you tried re-ordering the images? Order matters in enblend. (And of course you could always try Multiblend ;) ) On Thursday, 20 April 2023 at 20:35:23 UTC+1 irthoma...@gmail.com wrote: > > Thanks. Raws are here >

Re: [hugin-ptx] Stop enblend from removing result

Enblend's blending is dependent on the order that images are specified on the command line. By specifying the images in a different order (maybe in reverse, or maybe with the "redundant" image and its neighbour that you want it to blend with first) you may get something closer to the result

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

I finally got around to packaging up the files with the last few bugfixes. It doesn't include list file processing though, which is still on the to-do list. https://horman.net/multiblend/ On Wednesday, 20 October 2021 at 15:51:01 UTC+1 carr...@gmail.com wrote: > @Florian K¨nigstein, @Mon

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

t_p is readable > (above dst_pp_m = (__m128i*)dst_p; was executed). > > Monkey schrieb am Samstag, 3. Juli 2021 um 21:51:58 UTC+2: > >> Actually never mind, that probably isn't it... I'll keep looking. >> >> On Saturday, 3 July 2021 at 20:46:48 UTC+1 Monkey wrote:

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

Actually never mind, that probably isn't it... I'll keep looking. On Saturday, 3 July 2021 at 20:46:48 UTC+1 Monkey wrote: > Line 683 of image.cpp - please replace > > size_t channel_bytes = (width * height) << (bpp >> 4); > > with > > size_t channe

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

> contains 0 bytes. Probably the Debugger would raise an error at the same > line. At night I will run the new version with the debugger. > Monkey schrieb am Samstag, 3. Juli 2021 um 20:16:46 UTC+2: > >> Ah, how foolish of me, I think I failed to account for the required >&

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

61567 int > + [Raw View] {_Mypair=allocator } std::vector> > > x_offset = 75967 > y_offset = 0 > sy = 30780 > ey = 61567 > y = 30780 > The input files have a total size of 90 GBytes, but if nothing helps, I > could upload them somewhere. > > On Thursday I stitc

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

ixels with Multiblend in about 6 minutes. It's > super fast. Thanks @ Monkey ! > The maximum memory usage was about 24 GBytes. My photos would allow to > stitch it to about 10 GPixels, but due to my RAM (64 GBytes) I will > probably only be able to stitch about 2 - 2.5 GPixels. > >

Re: [hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

t a deficiency in the Hugin lens model. At least lay the groundwork for >>> it. >>> >>> The Brown-Conrady model parameters are sound, but the intersection with >>> the abc-Hugin parameter set contains only one (1) non-trivial distortion >>> p

[hugin-ptx] Re: Is there any way to keep pixels unchangeable with Hugin?

Is there any way you can convert your false colour images to a linear greyscale first? On Friday, 25 June 2021 at 15:52:48 UTC+1 alvaroh...@gmail.com wrote: > Hello! > > I'm trying to stitch thermal images (codified with Rainbow HC palette for > false color) and once I've stitched the images

[hugin-ptx] Re: Frustrado com Hugin

sudo apt install hugin Parece funcionar bem para mim no Ubuntu. On Saturday, 12 June 2021 at 20:28:41 UTC+1 jer...@gmail.com wrote: > > Instalei o DigiKam para editar fotos que é um dos meus hobbies. Uso o > Ubuntu Studio. O programa veio sem o Hugin para criar panorama. Quando > baixo o

Re: [hugin-ptx] Aligning 2nd Image Control Points to Match 1st Image

Strange. My two deleted messages from 3-4 days ago both appeared in my group digest email this morning. Anyway, he's a different link to the image I was trying to link to: https://horman.net/warped.jpg On Sunday, 18 April 2021 at 13:54:18 UTC+1 Monkey wrote: > > Please don't post

Re: [hugin-ptx] Aligning 2nd Image Control Points to Match 1st Image

My reply seems to have been deleted, not sure how or why... but anyway, here's my result of using my video plugin to warp the old image to the new one based on the control points in the PTO file: https://i.imgur.com/Vp0VkqR.jpeg It's cropped a bit because of the way the process works. On

Re: [hugin-ptx] Aligning 2nd Image Control Points to Match 1st Image

Using warping: https://i.imgur.com/8AQjDwf.jpg On Saturday, 17 April 2021 at 23:51:14 UTC+1 Tduell wrote: > Hello Meowly, > > On Sat, 2021-04-17 at 19:20 +0800, Meowly Bear wrote: > > Hi, > > > > Here is the slightly lower res version of the two pictures, together with > > the .pti file. I'm

Re: [hugin-ptx] Aligning 2nd Image Control Points to Match 1st Image

> Please don't post large attachments directly to mailing lists, not everyone > wants to receive the attachment. > It's always good etiquette to put your attachment on a cloud service (Dropbox or > similar) where those that want to can retrieve it. But not Imgur, I'm guessing? Because I've

Re: [hugin-ptx] Aligning 2nd Image Control Points to Match 1st Image

There's quite a large difference in geometry which I think Hugin is going to unable to fully correct. Can you upload your .pto file? I have a video plugin that should be able to warp one image to the other using the control points in the file. On Friday, 16 April 2021 at 11:32:34 UTC+1 Meowly

Re: [hugin-ptx] enblend error while stiching large image

t; that what you mean? > > On Tuesday, April 13, 2021 at 3:49:15 AM UTC-5 Monkey wrote: > >> Was that with Enblend or Multiblend? Have you made sure to mask out the >> shadowed/darkened strip at the edge, as well as the actual square? >> >> On Tuesday, 13 April 2021 at 05:19:

Re: [hugin-ptx] enblend error while stiching large image

ciate the continued support. > > > On Monday, April 12, 2021 at 7:13:08 PM UTC-5 Monkey wrote: > >> That's not the border I meant. It's the thin gray border with black lines >> which is at the top and/or left and/or bottom of *all* the images. It >> might be p

Re: [hugin-ptx] enblend error while stiching large image

tp://hugin.sourceforge.net/tutorials/Blend-masks/en.shtml), but it > seems like that's addressing a fundamentally different issue, so wasn't > sure how to apply that to this image. > > On Monday, April 12, 2021 at 6:25:13 AM UTC-5 Monkey wrote: > >> The problem is the grey bord

Re: [hugin-ptx] enblend error while stiching large image

t 1 around the bottom center of the map. All of the water > should be a reasonably uniform blue, except for those 4 stains in the > upper-left. > > On Wednesday, April 7, 2021 at 5:48:32 AM UTC-5 Monkey wrote: > >> If the remapped images don't show the difference in colour, but the bl

Re: [hugin-ptx] Re: Software to stitch 100+ Gigapixel panoramas,

the remaining control points are actually good. As you can see, the sea and the sky are going to be a problem... On Friday, 9 April 2021 at 15:25:11 UTC+1 Monkey wrote: > Okay, I haven't got finished PHP scripts yet but (for me, anyway) it's the > way to go. > > In preparation, can you download

[hugin-ptx] Re: Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

: > I'll give it a shot. last time I used it it for a aerial 360 it removed > cars and other ground objects. > > On Friday, March 5, 2021 at 3:57:30 PM UTC-8 Monkey wrote: > >> *(* for a Gigapixel mosaic, anyway; it's complicated, see below)* >> >> http://horman.net/

Re: [hugin-ptx] Re: Software to stitch 100+ Gigapixel panoramas,

Okay, I haven't got finished PHP scripts yet but (for me, anyway) it's the way to go. In preparation, can you download the top zip file from here: https://windows.php.net/download#php-8.0 Extract the contents to C:\php (or any other folder, doesn't have to be on C: and doesn't have to be the

Re: [hugin-ptx] Re: Software to stitch 100+ Gigapixel panoramas,

ly going to try it again, aswell as noting > the exact feild of veiw so I can feed it in to the stitching program > On Wednesday, 7 April 2021 at 8:45:08 pm UTC+10 Monkey wrote: > >> Gigapxtools looks to be an extremely piece of software. As far as I can >> see it just

Re: [hugin-ptx] enblend error while stiching large image

If the remapped images don't show the difference in colour, but the blend still does, could you output a reduced size remapped image set and upload it somewhere? On Tuesday, 6 April 2021 at 22:00:38 UTC+1 bruno...@gmail.com wrote: > On Tue 06-Apr-2021 at 13:46 -0700, Jared wrote: > > > >I have

Re: [hugin-ptx] Re: Software to stitch 100+ Gigapixel panoramas,

- and, one assumes, extremely good - lens, and with a motorised mount, should make a lot of the usual Hugin workflow redundant and we go straight to playing directly with images. On Tuesday, 6 April 2021 at 21:51:35 UTC+1 ryanf...@gmail.com wrote: > Monkey, its 0.44x0.67 degree per image, or ab

[hugin-ptx] Re: Software to stitch 100+ Gigapixel panoramas,

Well that's ambitious! If you know how the images overlap, one could call cpfind manually on each valid image pair just to get the control points for that pair, then combine all the pairs' control points into one big project file. I think actually using the Hugin GUI might be out of the

[hugin-ptx] Re: enblend error while stiching large image

I think Enblend doesn't like some of the pixel values in your images. You could try specifying a different blend colorspace (--blend-colorspace=IDENTITY might be a good option, but I'm just guessing). Or you could try Multiblend , which has no such colourspace

Re: [hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

You can probably replace any malloc except the one on line 20 of functions.cpp, but they should all be pretty small anyway. I'm guessing it's the seam map that's growing too large, but if you set --cache-threshold=1 that should cache all the images before it gets to the seam map and might

Re: [hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

Ugh, that had me stumped for a while. I couldn't work out why it was telling me it was trying access 0x. Anyway, the solution is to change lines 316 and 325 of pyramid.cpp to: pixels = _mm_load*u*_si128(src_pp_m++); On Saturday, 3 April 2021 at 16:41:48 UTC+1

Re: [hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

have any effect on execution. On Saturday, 3 April 2021 at 13:59:33 UTC+1 Monkey wrote: > Oh, how embarrassing... for a fix to that immediate problem, change line > 96 of threadpool.cpp to read: > > for (i = 0; i < *n_threads*; ++i) { > > -fsantize=address - which I s

Re: [hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

points very >> roughly, just to keep the photos of the sky in the right place. Is there >> another way to position them better, perhaps manually without using control >> points? >> >> Il giorno domenica 7 marzo 2021 alle 00:14:00 UTC+1 Monkey ha scritto: >> >>&

Re: [hugin-ptx] Hugin freezing during blending

Not that I would expect it to be default - I assume that's going to be Verdandi at some point - but what "necessary" features is it missing? I believe Multiblend was at one point bundled with Hugin as an alternative to Enblend for a release or two, not sure why it was dropped. On Sunday, 21

Re: [hugin-ptx] Hugin freezing during blending

Enblend is very slow. Multiblend is much, *much *quicker: http://horman.net/multiblend/ You change the Hugin settings under the Programstab (Use alternative Enblend program) and point it to multiblend.exe instead. On Friday, 19 March 2021 at 19:24:00 UTC MikaylaL wrote: > Hi Bruno, > > Thanks

Re: [hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

at 22:50:33 UTC ginos...@gmail.com wrote: > Hi Monkey, > I have done some tests with the same 56 photos 360° Panorama I already > sent to you. I have a pto with some masks to avoid bad seams on the > buildings. > Stitching this with Multiblend is much much faster but the result i

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

Tried to build on Ubuntu Mate and got this: /usr/include/Vc/scalar/../common/../sse/intrinsics.h:601:13: error: argument to '__builtin_ia32_vec_ext_v4sf' must be a constant integer _MM_EXTRACT_FLOAT(f, v, i); ^~

Re: [hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

itself, it might be blocked just because it doesn't have HTTPS (my current host is pretty terrible and their Let's Encrypt option doesn't work). On Saturday, 6 March 2021 at 15:44:27 UTC ginos...@gmail.com wrote: > Hi Monkey > > I am only writing to report that my BITDEFENDER TOTAL

Re: [hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

lend-dist/Libraries/libjpeg.8.2.2.dylib > multiblend-dist/multiblend > > Removed a few "sloppy" things from the script: > https://mega.nz/file/FR9CxCpB#ucZGem59Z6n8jVP7NriuqKS9YwGvMtIok9DZqX75vro > > Harry > > Op za 6 mrt. 2021 om 13:02 schreef Monkey : > >

Re: [hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

Fixed and updated, plus a fix to ignore (properly) an Enblend parameter that was stopping Hugin from successfully calling Multiblend. http://horman.net/multiblend/ David On Saturday, 6 March 2021 at 11:22:47 UTC hvd...@gmail.com wrote: > Builds fine and runs fine (under Hugin) on my Ubuntu

Re: [hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

3-05 at 15:57 -0800, Monkey wrote: > > (* for a Gigapixel mosaic, anyway; it's complicated, see below) > > > > http://horman.net/multiblend/ > > > > It seems Groups won't let me post the quasi-essay I had written, > complete with > > images, so the link ab

[hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

*(* for a Gigapixel mosaic, anyway; it's complicated, see below)* http://horman.net/multiblend/ It seems Groups won't let me post the quasi-essay I had written, complete with images, so the link above will have to suffice. Here's Multiblend 2.0, faster, better, more... blendy. I'm calling it

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

> and it's use of image pyramids relies on a variant of image pyramids based on b-splines. > To me, the implementation of the Burt/Adelson Algorithm is a major breakthrough. Is there a simple way to explain how this/these differ from a standard Laplacian pyramid? On Monday, 1 March 2021 at

Re: [hugin-ptx] Feature requests for Multiblend 2.0?

Anyone on Mac OS who can check if it compiles if I email a link to the source? On Friday, 12 February 2021 at 16:50:06 UTC bugbear...@gmail.com wrote: > True as far as it goes. > > An OS will manage virtual memory, swapping data between RAM and Disc as > needed, normally in pages of some fixed

Re: [hugin-ptx] Feature requests for Multiblend 2.0?

parently managing memory > behind the scene. > > I understand Photoshop does its own memory management, but it dates back > to the days when it ran under OSes that had no real memory management. > > So why does an app like multiblend need to do its own memory management? >

Re: [hugin-ptx] Feature requests for Multiblend 2.0?

gt; The gimp splits big images into tiles that small enough so a few of them > fit into the RAM and then tries to work on these tiles one at a time. > On 11.02.21 18:33, Monkey wrote: > > It's been several years but I'm working on a new version of Multiblend > that's a bit faster,

[hugin-ptx] Feature requests for Multiblend 2.0?

It's been several years but I'm working on a new version of Multiblend that's a bit faster, produces much nicer results, and will blend much bigger mosaics. Does anyone have any feature requests for a blender that I could consider incorporating? Along the same lines, does anyone use Enblend's

Re: [hugin-ptx] Trying to use Hugin, and...

anyone know why this happens? Is it an OpenGL problem? Some images turn into jagged strips, some don't appear at all (they do appear in the little "sphere" preview to the left). On Monday, 8 February 2021 at 06:48:03 UTC m.l...@up.ac.za wrote: > Hallo Monkey, > > Sunday, Febr

Re: [hugin-ptx] Does anyone have any image sets, particularly ones that don't blend well, that they could share for testing purposes?

at 04:47:43 UTC Laurent E wrote: > Hi Monkey, > I'm finishing a virtual tour that includes 8 street-art flat panoramas. > Some are 30 meters wide. > Is it the kind of pano you're looking for? > > On Tuesday, January 26, 2021 at 5:13:22 AM UTC+7 Monkey wrote: > >> Perfect,

Re: [hugin-ptx] Does anyone have any image sets, particularly ones that don't blend well, that they could share for testing purposes?

Perfect, thanks! On Monday, 25 January 2021 at 20:35:45 UTC Donald Johnston wrote: > Hi Monkey … these are links to some file sets I have on Sync.com. Let me > know if they are useful. > > https://ln2.sync.com/dl/f27685a80/392a24qm-7uudw2mp-4vzsr5eg-qaj852qx > https://ln2.sync.c

[hugin-ptx] Does anyone have any image sets, particularly ones that don't blend well, that they could share for testing purposes?

I'm making a new version of Multiblend but I don't have a lot of panoramas/mosaics to test it with. Does anyone have any image sets they could share, perhaps via Google Drive, particularly ones which have proven problematic to blend together? 360s x 180s, gigapixels, planar mosaics and such

[hugin-ptx] Re: Any reason to use Enblend over Verdandi?

different numbers of levels for every image, as the overlap allows, but as well raising the possibility of inconsistent blending this also seems to result in later images being blended more than earlier ones). On Friday, 22 January 2021 at 15:44:05 UTC T. Modes wrote: > Hi Monkey, > > verda

Re: [hugin-ptx] Any reason to use Enblend over Verdandi?

Did you try both seam modes? They do quite different things, and the default is not the Enblend-like one. On Tuesday, 19 January 2021 at 22:00:11 UTC GnomeNomad wrote: > On January 19, 2021 10:54:28 AM HST, Monkey wrote: >> >> I haven't used Hugin for a while, but I recently sta

[hugin-ptx] Any reason to use Enblend over Verdandi?

I haven't used Hugin for a while, but I recently started updatng my old Multiblend project as I had recently rewritten the pyramid processing part of it for another project. I hadn't used the built-in Hugin blender (Verdandi), so I gave it a try and was pleasantly surprised with the results.

[hugin-ptx] Rounding bug in Nona and/or image reading

The attached project consists or two images - small, ostensibly single-colour JPEGs. When opened in Photoshop, green.jpg has pixels all of value (0,255,1). yellow.jpg has pixels all of value (255,255,0). After stiching to separate tifs, one tif is over 10x larger than the other. On opening

[hugin-ptx] Re: Hole in panorama

I think it's either a stitching problem or you've inadvertently masked out that section of the image. Switch from enlblend to built-in or vice versa, or check the Masks tab. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this

[hugin-ptx] Re: multiblend error

This one's not so obvious. Try changing line 531: int lp; to size_t lp; If that doesn't work, which I suspect it won't, you may just have to add printfs to figure out exactly where it's breaking. On Saturday, 25 January 2020 12:25:30 UTC, Hans Bull wrote: > > Your guess was right!!

[hugin-ptx] Re: multiblend error

The likely suspect is the memset on line 449. "(output->pitch*output->h)pitch*output->h)pitch*(size_t)output->h)< > After multiblend repeatedly aborted while trying to blend a 28611x51445, I > recompiled it with -fsanitize=address and got the following.

Re: [hugin-ptx] Re: enblend / black corners and fringes

On Sunday, 29 September 2019 22:58:09 UTC+1, lukas wrote: > > > you mean lower frequency, right? > No, higher (I said highEST but I meant highER). Lower frequencies would be expected to be used, because they will have spread from valid areas. You don't want to see the higher frequency

[hugin-ptx] Re: enblend / black corners and fringes

I think all three should be fixed. #3 was one motivation for writing Multiblend, because it can cause problems even when seams don't stray (particularly when image edges make a corner). Multiblend assumes any out-of-bounds pixel (per image) is the same colour as its nearest in-bounds

Re: [hugin-ptx] Compilation error on multiblend

It (probably) won't build without -ljpeg. Try changing the "true" on those two lines to "boolean(true)" For the warnings, you can change p>=0 to p>0 (strictly speaking it is a bug, but not one you are likely to trigger unless you have pathological input images). -- A list of frequently asked

Re: [hugin-ptx] Re: Enblend oddity

I tried all combinations. Yes, in a certain order, it blends > without problems. Maybe that's worth filing a bug report for...? > > (Also, I should add a feature request for multiblend: support deflate > compression ...) > > Thanks! You saved my pano. :) > > Best, &

[hugin-ptx] Re: Enblend oddity

Are you wedded to enblend? multiblend would have no such issues, and actually does blend, not just assemble, disconnected images. Alternatively, have you tried reordering the images? Rename testing0002.tif to testing.tif and vice versa. -- A list of frequently asked questions is available

Re: [hugin-ptx] enfuse/enblend discussions?

I don't think I asked any questions before releasing multiblend, more-or-less fully formed (in fact I had previously developed some more complex GUI software for image blending, but never released it). The ideas behind enblend/enfuse aren't protected; the enblend documentation itself goes

Re: [hugin-ptx] Why is part of the stitched image black?

Rather splitting the panorama in two, have you tried reordering the images? Enblend produces different results depending on the input order. On Tuesday, 17 January 2017 16:19:43 UTC, Hans Bull wrote: > > The new default graph-cut algorithm in most cases seems to produce better > seams, but

[hugin-ptx] Re: Can Hugin change the projection of a video?

Equirectangular Panini, but I forgot to type the second word. On Tuesday, 12 July 2016 01:57:53 UTC+1, Robert Giordano wrote: > > Hi Monkey, > > Avisynth looks very interesting. I'm on a Mac but I have access to Windows > machines. I do my editing in Adobe Premiere/After Effects CS6. The onl

[hugin-ptx] Re: Can Hugin change the projection of a video?

in the distribution which will give individual transform coordinates on request, from a PTO - but I don't recall finding out a way to give a full map of coordinates in one call. If that could be done I could modify my plugin to read the map and apply it to the video) -Monkey On Sunday, 10 July

[hugin-ptx] Re: Multiblend with CMake build support??

I have no idea about CMake, but it does compile with Visual Studio - well, as long as you have a static compile of libtiff, turbopeg, libpng and zlib to link against... Open multiblend.cpp as the only source file and the rest are #included from there. On Friday, 26 February 2016 11:58:29 UTC,

Re: [hugin-ptx] Enblend performance on mosaics?

The problem with your "quadrant" plan may be down to the order you supply the images on the command line. It may be that each image must be connected to the previous images. So if you had 9 images: ABC DEF GHI And you supplied them in the order A,B,C,H... enblend might be able to blend A,B,C

Re: [hugin-ptx] Enblend performance on mosaics?

The problem with your "quadrant" plan may be down to the order you supply the images on the command line. It may be that each image must be connected to the previous images. So if you had 9 images: ABC DEF GHI And you supplied them in the order A,B,C,H... enblend might be able to blend A,B,C

Re: [hugin-ptx] Enblend performance on mosaics?

You might save time by pre-merging alternate images in each row - not blending them, but just joining them into a single image. Then you end up with two images: 1-3-5- -2-4-7 which can blended in one enblend step. This should be a lot quicker. One of enblend's big problems, as far as I can

Re: [hugin-ptx] Re: Verdandi: the new blender

A seam map export from Verdandi would be awesome. Then I could feed it into multiblend, since multiblend doesn't do seam optimisation. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the

Re: [hugin-ptx] Re: Some curious blending results

I think those sample images were not the best that could have been chosen to illustrate flat stitching, with their abstract design and lack of visual clues as to orientation. I had to double check to make sure they hadn't been rotated as it's not immediately obvious, nor is it easy to gauge how

Re: [hugin-ptx] Re: Some curious blending results

On Wednesday, 22 April 2015 22:53:11 UTC+1, Roger Broadie wrote: Monkey davidh...@gmail.com javascript: commented on Wed, 22 Apr 2015 at 04:53:56 -0700 (PDT): The blurred patch [in Terry Duell's screenshot of Tue, 21 Apr 2015 at 17:37:32 +1000] is not down to the blending

[hugin-ptx] Re: Looking for tutorial on making a 3-D image of an object.

You could look into Photosynth: http://photosynth.net/ It doesn't actually build 3D models but it may be of interest. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups

Re: [hugin-ptx] nona produces small TIFF images

Not quite on-topic, but out of curiosity, will this generated project try to connect all images to every other image? Can it be done so that images only align to, for example, the first image? Otherwise there's going to be a LOT of control point finding going on... On Wednesday, 10 September

[hugin-ptx] Best way to align a stack to base image only

Is there an easy to generate control points for a set of images, such that all images are linked only to the first image? Aligning an image stack aligns images in sequence (0-1, 1-2, 2-3, etc) but I would prefer (and think it would be better) if all images were aligned to image 0 only (0-1,

[hugin-ptx] Re: unblended triangle in fused version?

The following applies to a 2012 Windows build, but... Go to File-Preferences, Programs tab, tick Use alternative Enblend program and specify the path to a multiblend executable. If that doesn't work, you could just replace the enblend executable, though that's not a neat solution.

[hugin-ptx] Re: unblended triangle in fused version?

I had a similar problem crop up while I was developing multiblend, though that had a slightly different cause. My guess at what may have happened is that, given three images in horizontal order, A B C, enblend has blended the small overlap between A and C before considering B. When it does come

Re: [hugin-ptx] Strange haze on panorama photo stitched in HUGIN

Is anybody else worried about what's in the bag? :S ;) -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from

Re: [hugin-ptx] A curious omission

The option for stitching with no exposure correction is to reset the exposure parameters before stitching. That seems unnecessarily opaque, but okay. But then why should there be separate Exposure correction/No exposure correction options under Remapped Images? It seems inconsistent to

[hugin-ptx] Re: Scripted stitching of webcam pictures - advice appreciated

(or is supposed to work). On Friday, 6 June 2014 10:46:28 UTC+1, Jacob Hämmerle wrote: Hey Monkey, thanks for your advices! I've tried to reproduce and the result is pretty ok. 1. Why did you choose 45 for HFOV? The Cameras are nearly set to full wideangle which acc. to the specs

[hugin-ptx] A curious omission

Why does Hugin include No exposure correction, low dynamic range among the Remapped images options, but it doesn't have a related no-exposure entry under Panorama Outputs? Might it not also be clearer to disable the Exposure corrected options when no Exposure optimisation has been done/no

Re: [hugin-ptx] A curious omission

Sorry Bruno, you've only confused me further! I wasn't considering fusing stacks or anything that advanced. What is the suggested procedure if I just want a blended, single-file output panorama with no exposure correction from a basic mosaic of images? It seems to me that none of the options

[hugin-ptx] Re: Scripted stitching of webcam pictures - advice appreciated

4. Last and least: How would you do it? What is your advice to me? I got a pretty good result by doing the following: Load the images into Hugin, and set an approximate HFOV (I used 45 degrees) and a projection of equirectangular Create some control points - I used Create control points on the

[hugin-ptx] Re: Scripted stitching of webcam pictures - advice appreciated

Actually, having said all that, I now find that when dragging the images around in the GL viewer, they don't stay fixed together as I was expecting them to, so maybe I'm entirely wrong to suggest doing it that way! -- A list of frequently asked questions is available at:

Re: [hugin-ptx] Map Difficulties 2

On Monday, 28 April 2014 11:02:10 UTC+1, Bruno Postle wrote: On 28 April 2014 10:24, paul womack wrote: On this particular map, some of the tiles have borders, which I am attempting to remove using Hugin's crop/mask features. Yes, masking in Hugin isn't very useful where there are

Re: [hugin-ptx] Map Difficulties 2

Quick and dirty multiblend attempt with a handmade mask: http://i62.tinypic.com/24b29vb.jpg -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free

[hugin-ptx] Re: Multiblend option like --no-ciecam?

It doesn't, but if you can send me some example files (address at the bottom of the homepage, http://horman.net/multiblend/) I'll take a look. On Wednesday, 19 March 2014 20:08:10 UTC, Donald Johnston wrote: Hi, I’ve had to switch back to enblend and use the --no-ciecam option to fixed some

[hugin-ptx] Re: Multiblend option like --no-ciecam?

Oh, *that* kind of glaring! (emailed images show red and blue channels swapped in output) You just need the --bgr switch :) David On Thursday, 20 March 2014 16:29:47 UTC, Monkey wrote: It doesn't, but if you can send me some example files (address at the bottom of the homepage, http

[hugin-ptx] multiblend 0.6.1 released (bugfixes)

Hi all, multiblend, the super-fast blender and drop-in replacement for Enblend, has been updated to version 0.6.1 in order to fix a bug which could cause a dark band to appear at the bottom of the image. It also fixes another bug introduced in a previous version relating to large uncropped

Re: [hugin-ptx] Stacking stars with Hugin's help (show and tell)

Nope, I wanted to remap the images so as *not* to generate star trails. There is software around that does this, but I've never found one I'm completely happy with - either they only support simple remapping (sometimes only translation, sometimes also rotation but that isn't always enough), or

Re: [hugin-ptx] Batch stitching multiple panoramas

If there was a way to export nona's pixel mappings, someone (possibly me) could write an Avisynth (Windows, but runs under Wine) video filter to do the heavy lifting. If it's all rectilinear and doesn't involve any of the fancier stuff, you might be able to do it with a a

Re: [hugin-ptx] Batch stitching multiple panoramas

Thanks Bruno (and Pablo, who wrote it!), that has a lot of promise. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To

[hugin-ptx] Some fast bicubic code of any use to Hugin?

Some time ago I wrote what, for me, was some fast and highly efficient code (using look-up tables and SSE) to do bicubic (or any 4x4 window) interpolation on 8-bit RGBA images. It can remap an HD image (1920x1080) in about 0.07s on my quad core 2.20GHz laptop - to be honest I don't really know

[hugin-ptx] Re: Stitching of many-channel images

Hi Erik, I'm replying more out of curiosity towards what sounds like an interesting project than being able to contribute any ideas, but it seems to me that there may not be much room for shortcuts even if Hugin could handle multi-channel images. As my best guess, it would still need to do the

[hugin-ptx] Re: Stitching of many-channel images

Okay, I've been foolish - of course, Hugin wouldn't have to recalculate all the pixel coordinates, though I'm unsure how much time this could save. I can imagine the ability to export those coordinates could be useful for all kinds of things, though. -- A list of frequently asked questions is

[hugin-ptx] Re: Enblend: limiting minimum levels

I may be getting my wires crossed but I don't think the change Chris has made will provide the effect John wants. What I think is being requested is more complicated than just limiting or forcing the number of levels, but actually requires blurring the top level mask, so that the dividing line

[hugin-ptx] Re: Enblend: limiting minimum levels

What you can do is use Enblend's --save-masks, blur the saved mask file(s), then blend again using --load-masks to use the blurred masks. Overlap corners may need to be checked for problems. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You

Re: [hugin-ptx] So long to do 90 photo stitching

May I also shamlessly recommend multiblend http://horman.net/multiblend/, if blending speed is an issue? It won't give identical results to enblend, but is certainly faster. On the other hand it's not quite as good at memory management, so it *may *not be able to complete your blend. On

  1   2   >