Is there an easy way to stitch multi-row panorama. I shoot a test
image set (3 rows and 9 columns). PTGUI-pro version failed to stitch
it automatically for me. I ended up assign control points manually for
the adjacent images. I can't imagine if I took a set of 20+ rows and
50+ columns, it will take me forever to manually add all the control
points. Does PTGUI have some kind of image input table so that I can
hint PTGUI the relative image locations.
What's the upper limit of rows and columns of an image set that PTGUI
can handle? Or maybe, I should name the images in a certain way that
PTGUI can interpret it as a multi-row image set.
I recently ordered a gigapan pro and would like to have some fun to
take a panorama of over 1000 images. Even though I haven't tried,
someone told me that the software come with gigapan can only stitch an
image of 600M pixels. I have seem PTGUI users created images of over
5G pixels. Just wondering how does people do it.
For images over 4G (2^32) of pixels, what image file format shall I
use? Will an 8-core intel Xeon system with 16G of RAM handle such
heavy load? How about over 16G of pixels?
These questions may sound very naive, I am simply lost. Thanks!
Alfred
You can do more than hint. You can specify the exact yaw, pitch and
roll values on the Image Parameters tab (in Advanced mode). It's a
little laborious, but you can speed things up a lot by selecting sets
of boxes to enter the same value in each, and use Fill Yaw for
entering incrementing values. You can also select images in a row or
column and generate control points just for those.
John
ptgui can stitch almost any size of panorama, but you are limited to
300x300k pixel, which is the largest what the photoshop large format
(PSB) allows (no real limit on the file size, since it can contain
layers). tiffs are limited to 4GB size (independent of the pixel
dimensions). every other file format has even more severe limitations.
there is as far as i know no limit on the number of tiles ptgui can
handle, but based on anecdotal experience, 2000 tiles shouldn't be a
problem, although you need a lot of patience, and HD space.
ptgui can easily do multi-row/multi-column, and I have done many many
of them. maybe your setup has enormous parallax errors, or you didn't
shoot with enough overlap (25-33% is recommended, 20% is the lower
end, 15% might fail to generate enough meaningful control points. more
than 45% is overkill.) ptgui is also not able to place tiles
automatically if there are no features to generate CPs, like i.e.
empty sky tiles. ptgui also has problems to generate CPs for tiles
that are severely under or over exposed.
joergen
Yes, the set with 27 images were taken on a regular ball-head (with
excessive parallax error). Since then, I acquired a 303SPH and Gigapan pro
robotic head. So those issues should be taken care of. The current world
record has 354159x75570 pixels. It has already gone beyond 300k pixel per
dimension. Do you know what file format do they use?
Regular TIFF file is limited to 4G. However, BigTIFF
(http://www.awaresystems.be/imaging/tiff/bigtiff.html) doesn't seem to have
that limit. Does PTGUI pro support BigTiff?
On another thought, can PTGUI pro output the resulting panorama into
multiple images so that the physical limit is no longer an issue. Any idea?
Thanks!
Cheers,
Alfred
alfred,
joergen
--
You received this message because you are subscribed to the Google Groups
"PTGui" group.
To post to this group, send email to pt...@googlegroups.com
To unsubscribe from this group, send email to
ptgui+un...@googlegroups.com
Please do not add attachments to your posts; instead you may upload files at
http://groups.google.com/group/ptgui/files
For more options, visit this group at http://groups.google.com/group/ptgui
To unsubscribe, reply using "remove me" as the subject.
For your 27 tile pano, excessive parallax error depends on the
distance between your subject and your camera, if your "stuff" was at
infinity, it shouldn't matter so much... if your tiles didn't have
enough overlap, you might be able to "salvage" the project by some
manual adding of some CPs...
in terms of the world record, it might have been shot/optimized to
354k width, but I am pretty sure the final output was below 300k (the
dresden 26gpx pano was 290kpx wide).
300kpx will be a limit for the foreseeable future. while bigtiff
supports much larger files (both in terms of pixel dimensions, and
also in file size), there aren't many applications that either write
or read it. Adobe photoshop seems to have some preliminary bigtiff
support (since they are the stake holders for the tiff file format),
there isn't too much happening in that direction. I was/am planning a
seriously large pano here in NYC, and I spoke with Adobe (J. Nack and
others) about support for larger projects, and they don't really see a
market value to add support for larger things to photoshop (it costs
money to develop >300kpx, and even more money to test it (imagine the
wait time to just open and play around with those monster files)). so
unless more people request this feature, it won't happen soon in
photoshop. and quite honestly, I don't know any other app that allows
you to manipulate files like this (with maybe the exception of
mathematica et al), but I would be a very happy camper if somebody
could show me alternatives. Joost said that it would be possible to
support bigtiff, but since nothing reads it, it's not worth his time
yet.
a possible alternative could be rendering 90x90deg cube faces directly
from ptgui (each up to 300x300kpx), and then drop them into krpano
(which supports PSB as input). this could theoretically create panos
1.2x0.6mpx, but given the fact that this is a boatload of work, it
will take some time until somebody tackles that. maybe 5 years from
now it will be feasible.
so, for now the world record breakers will have to explore the
vertical dimension. IMO, the 26gpx dresden pano is only a 13Gpx pano,
since half of it is sky anyway... paris and prague are much better
contenders, since there is enough vertical view to justify the
gigapixel race, and maybe I will get around to shoot a 100gpx NYC pano
this year.
i hope this helps
joergen
> Please do not add attachments to your posts; instead you may upload files athttp://groups.google.com/group/ptgui/files
> For more options, visit this group athttp://groups.google.com/group/ptgui
Hi Joergen,
Just curious, what kind of support does it have already?
Actually the 300,000 pixel limit is a limitation of Photoshop, not of
the .psb format. I'm thinking of just removing this limit from PTGui so
you can create much larger panoramas.
Joost
I do not know too much about it, it may be able to read it (i haven't
tested it yet), but adobe says that if somebody want to write a file
extension plugin for photoshop and bigtiff, that shouldn't be a
problem at all.
300kpx is an internal limit of photoshop, and is set arbitrarily (it
was increased from 30kpx some versions ago and labeled "large enough
for the foreseeable future", but unfortunately for adobe, any
ambitious photographer can break the 300kpx barrier now in 2010.)
what we need is a petition to adobe to increase the limit to something
larger (i.e. 1mpx x 1mpx, aka 1 terapixel doc) in photoshop CS6. if
john nack sees that there is a demand for it, they are more inclined
to go for it.
since CS6 is at least 18 months away from spring 2010, maybe it would
be interesting to go another route:
- add bigtiff support to ptgui, and lift the max output size limit
- add special logic to the output module so people don't complain that
something doesn't work at the end of a render (i.e. don't allow PSB
output for larger than 300kpx, similar to no jpg larger than 30kpx)
- convince klaus from krpano.com and others to support bigtiff input
(krpano has some PSB support as far as I know, but I don't know if any
of the other flash players have as "robust" tools as krpano)
this scenario would allow for much larger output, and would add new
fuel to the gigapixel race. the limitations are that there won't be
any editing in photoshop, no retouching... the only method of
"editing" would be pre-masking and playing with the blend priority.
this is going to be insane. we will treat 2TB sata drives like the old
100MB zip drives.
joergen