Only time will show, what will come.
Some might remember ads about kitchen TV's.
http://chesscomicsandcrosswords.blogspot.com/2012/12/vintage-ads-when-sony-launc\
hed-its.html
or even better
http://boingboing.net/2011/11/21/portable-tv-ad-is-that-cigar.html
Smallest what found now is 19 inch.

--- In PanoToolsNG@yahoogroups.com, Keith Martin  wrote:
>
> On 10 Feb 2013, at 16:23, Trausti Hraunfjord  wrote:
>
> > I don't find much REAL use for displaying panos on phones and small tablets
> >
>
> While some don't, others do. For example, the two different organisations I'm
doing pano work for at the moment both have mobile device support as a primary
requirement. In my experience, iOS-friendly panos are a must, right here and
now. Willy's recent posting of iOS usage stats is also interesting, and it shows
that these so-called iToy things are getting significant use.
>
> Ormar made an interesting point; we *are* aiming for ever-higher resolution
panoramas but have to accommodate devices with tighter memory requirements and
smaller screens than we've seen on the desktop for a while. But we're still
delivering to desktop-OS devices as well, and higher-res originals mean we can
be more precise about production accuracy before we optimise output for smaller
screens. (If anyone finds their work is always larger than they need, shoot and
process at lower resolutions and speed up the workflow!)
>
> I teach publishing up to postgrad level, and I'm the technical editor of a
major computer magazine; it's my business to have considered, professional
opinions on these topics. Support these devices or don't, it's everyone's
choice. But trust me, even if you don't like them, they're here to stay and they
are a major part of everyone's future, one way or another. Hence my choice in
tools.
>
> k
>

I just became aware of your challenge this evening since I rarely read this
list.  Normally I would pass this by as a waste of time, but with the bragging
about the difficulty, I couldn't resist.

It turned out to be dissapointingly easy.

I assumed you were using actual encryption (AES-256, etc...), so I took the
difficult but reliable route of manually dissecting the SWF bytecode itself.

What I found was that your "encryption" isn't encryption at all, but rather
simple obfuscation consisting of plain old base 64 encoding with 7 garbage
characters prepended.  Any of the image or XML files can be easily "decrypted"
by the following python script:

import base64
import sys

def process(inname,outname):
     f = open(inname)
     data = f.read()
     f.close()
     bindata = base64.b64decode(data[7:])
     f = open(outname,"wb")
     f.write(bindata)
     f.close()

if __name__=="__main__":
     if len(sys.argv) != 3:
         print("Usage: decode.py  ")
     else:
         process(sys.argv[1],sys.argv[2])

This brings me to another issue.  On your Pano Cocoon product page, you claim
that "XML Encryption will encrypt the main .xml file in the project with 256 bit
encryption, making it literally impossible to break the encryption."

There is nothing 256-bit about it.  It isn't even real encryption.  Obviously,
the last part is false, but even real encryption can still be cracked since
viewing requires decryption.  If it used real encryption, my original approach
would still have worked.  This entire statement is false advertising.

--- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord  wrote:
>
> Not moving goal posts?  Tell that to Apple while you have that thought :)
>
> Actually you are right, simply because I didn't write exactly what I had in
> mind... I corrected that a bit later.  People were saying that the
> encryption didn't work, and it does work perfectly.  Both for the images
> and the xml.  Same thing.
>
> People said they could get the images from OpenGL ... no proof, and not
> possible from what I learned by trying to do just that.
>
> Screenshots are possible, and then there is the possibility of shooting
> pictures of the screen with a camera too.
>
> Neither method gives the same result as having the original imagery.  100%
> protection is an illusion, but no protection is just being plain stupid.
>  None of us would build our home without walls or doors... some protection
> is needed... and most of us use door locks on the exterior doors.  That is
> what the encryption should be seen as.  People can still walk past the
> house and steal pictures from the outer surface and even peek in the
> windows, but they won't get the same quality of imagery as if they were
> actually inside.
>
> Keep the pano if you like :)
>
> Trausti
>
> On Fri, Feb 8, 2013 at 6:11 AM, Jeffrey Martin  wrote:
>
> > **
> >
> >
> > Trausti,
> >
> >
> > your original "challenge" was not to get the xml, rather, to make a useful
> > pano. don't move the goalposts, dude! this is what you said:
> >
> > "Here you have a project that has been encrypted, and you are more than
> > welcome to take the images from the browser cache and do with them as you
> > like... or in some other magical way turn this into a usable panorama on
> > your end: http://goo.gl/**Q9wyB "
> >
> > I guess if someone stole your pano, you would not care if they did it via
> > screenshots? Or you only go after them if they steal it "the right way" by
> > stealing the xml? :)
> >
> > Anyway, i'm asking "what is your end game" not regarding this security,
> > but more in response to Sacha's comment. Seems like your tool would be much
> > better - and sell a lot more - if it was based on krpano.
> >
> > your pano is still on 360cities, it will earn enough ad revenue to buy you
> > a beer when you come to prague. unless you want me to remove it?
> >
> > cheers,
> > jeffrey
> >
> >
> >
> >
> >
>

I was wondering if anyone has done a comparison test between the two Samyang
fisheyes for NEX.  Samyang/Rokinon has a 8mm f2.8 -- the new one -- and the
first gneeration 8mm f3.5 with an E-mount

The first generation fishey -- the f3.5 -- is getting cheap.  It's big and
clumsy compared to the f3.5 but maybe it's a better lens than the f2.8.  It
would be interesting to see a comparison.  That's something that I don't have
the resources to do.

Has anyone done a comparison?

From: luminouslabs

To: PanoToolsNG@yahoogroups.com

Sent: Monday, February 11, 2013 2:47 AM

Subject: [PanoToolsNG] Re: Html5 xml and image encyrption

 

I just became aware of your challenge this evening since I rarely read this list. Normally I would pass this by as a waste of time, but with the bragging about the difficulty, I couldn't resist.

It turned out to be dissapointingly easy.

I assumed you were using actual encryption (AES-256, etc...), so I took the difficult but reliable route of manually dissecting the SWF bytecode itself.

What I found was that your "encryption" isn't encryption at all, but rather simple obfuscation consisting of plain old base 64 encoding with 7 garbage characters prepended. Any of the image or XML files can be easily "decrypted" by the following python script:

import base64
import sys

def process(inname,outname):
f = open(inname)
data = f.read()
f.close()
bindata = base64.b64decode(data[7:])
f = open(outname,"wb")
f.write(bindata)
f.close()

if __name__=="__main__":
if len(sys.argv) != 3:
print("Usage: decode.py ")
else:
process(sys.argv[1],sys.argv[2])

This brings me to another issue. On your Pano Cocoon product page, you claim that "XML Encryption will encrypt the main .xml file in the project with 256 bit encryption, making it literally impossible to break the encryption."

There is nothing 256-bit about it. It isn't even real encryption. Obviously, the last part is false, but even real encryption can still be cracked since viewing requires decryption. If it used real encryption, my original approach would still have worked. This entire statement is false advertising.

--- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord wrote:
>
> Not moving goal posts? Tell that to Apple while you have that thought :)
>
> Actually you are right, simply because I didn't write exactly what I had in
> mind... I corrected that a bit later. People were saying that the
> encryption didn't work, and it does work perfectly. Both for the images
> and the xml. Same thing.
>
> People said they could get the images from OpenGL ... no proof, and not
> possible from what I learned by trying to do just that.
>
> Screenshots are possible, and then there is the possibility of shooting
> pictures of the screen with a camera too.
>
> Neither method gives the same result as having the original imagery. 100%
> protection is an illusion, but no protection is just being plain stupid.
> None of us would build our home without walls or doors... some protection
> is needed... and most of us use door locks on the exterior doors. That is
> what the encryption should be seen as. People can still walk past the
> house and steal pictures from the outer surface and even peek in the
> windows, but they won't get the same quality of imagery as if they were
> actually inside.
>
> Keep the pano if you like :)
>
> Trausti
>
> On Fri, Feb 8, 2013 at 6:11 AM, Jeffrey Martin wrote:
>
> > **
> >
> >
> > Trausti,
> >
> >
> > your original "challenge" was not to get the xml, rather, to make a useful
> > pano. don't move the goalposts, dude! this is what you said:
> >
> > "Here you have a project that has been encrypted, and you are more than
> > welcome to take the images from the browser cache and do with them as you
> > like... or in some other magical way turn this into a usable panorama on
> > your end: http://goo.gl/**Q9wyB "
> >
> > I guess if someone stole your pano, you would not care if they did it via
> > screenshots? Or you only go after them if they steal it "the right way" by
> > stealing the xml? :)
> >
> > Anyway, i'm asking "what is your end game" not regarding this security,
> > but more in response to Sacha's comment. Seems like your tool would be much
> > better - and sell a lot more - if it was based on krpano.
> >
> > your pano is still on 360cities, it will earn enough ad revenue to buy you
> > a beer when you come to prague. unless you want me to remove it?
> >
> > cheers,
> > jeffrey
> >
> >
> >
> >
> >
>

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2897 / Virus Database: 2639/6092 - Release Date: 02/09/13

 

Well , LOL, does this mean the plot thickens? Wonder how many are saving this post? Anyway, I have a favor to ask.. this has been a pretty brutal thread.. Some of the ego's here are bigger then my winter boots.. ( I'm ok with that except it's tuff to watch a few of you beat each other up so badly)  

 

Soooo getting past the ego thing..it's actually a good concept to have encrypted pano's and images etc.. Regardless of using HTML 5 or flash ..encryption to protect an image for you guys is a good thing not bad.. and quite frankly I like to see that developed for your use.. The worlds is just to full of thieves without proper laws to deal with it effectively.. This group has in it's mix some of the best heads I've been exposed to ... your all very very dedicated people..

 

So maybe after taking a few deep breaths (assuming that this script works) how could this encryption be implemented to make it function as intended?

I'll be a fly on the wall for a while on this I reckon..

 

j ----- Original Message -----

From: luminouslabs

To: PanoToolsNG@yahoogroups.com

Sent: Monday, February 11, 2013 2:47 AM

Subject: [PanoToolsNG] Re: Html5 xml and image encyrption

 

I just became aware of your challenge this evening since I rarely read this list. Normally I would pass this by as a waste of time, but with the bragging about the difficulty, I couldn't resist.

It turned out to be dissapointingly easy.

I assumed you were using actual encryption (AES-256, etc...), so I took the difficult but reliable route of manually dissecting the SWF bytecode itself.

What I found was that your "encryption" isn't encryption at all, but rather simple obfuscation consisting of plain old base 64 encoding with 7 garbage characters prepended. Any of the image or XML files can be easily "decrypted" by the following python script:

import base64
import sys

def process(inname,outname):
f = open(inname)
data = f.read()
f.close()
bindata = base64.b64decode(data[7:])
f = open(outname,"wb")
f.write(bindata)
f.close()

if __name__=="__main__":
if len(sys.argv) != 3:
print("Usage: decode.py ")
else:
process(sys.argv[1],sys.argv[2])

This brings me to another issue. On your Pano Cocoon product page, you claim that "XML Encryption will encrypt the main .xml file in the project with 256 bit encryption, making it literally impossible to break the encryption."

There is nothing 256-bit about it. It isn't even real encryption. Obviously, the last part is false, but even real encryption can still be cracked since viewing requires decryption. If it used real encryption, my original approach would still have worked. This entire statement is false advertising.

--- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord wrote:
>
> Not moving goal posts? Tell that to Apple while you have that thought :)
>
> Actually you are right, simply because I didn't write exactly what I had in
> mind... I corrected that a bit later. People were saying that the
> encryption didn't work, and it does work perfectly. Both for the images
> and the xml. Same thing.
>
> People said they could get the images from OpenGL ... no proof, and not
> possible from what I learned by trying to do just that.
>
> Screenshots are possible, and then there is the possibility of shooting
> pictures of the screen with a camera too.
>
> Neither method gives the same result as having the original imagery. 100%
> protection is an illusion, but no protection is just being plain stupid.
> None of us would build our home without walls or doors... some protection
> is needed... and most of us use door locks on the exterior doors. That is
> what the encryption should be seen as. People can still walk past the
> house and steal pictures from the outer surface and even peek in the
> windows, but they won't get the same quality of imagery as if they were
> actually inside.
>
> Keep the pano if you like :)
>
> Trausti
>
> On Fri, Feb 8, 2013 at 6:11 AM, Jeffrey Martin wrote:
>
> > **
> >
> >
> > Trausti,
> >
> >
> > your original "challenge" was not to get the xml, rather, to make a useful
> > pano. don't move the goalposts, dude! this is what you said:
> >
> > "Here you have a project that has been encrypted, and you are more than
> > welcome to take the images from the browser cache and do with them as you
> > like... or in some other magical way turn this into a usable panorama on
> > your end: http://goo.gl/**Q9wyB "
> >
> > I guess if someone stole your pano, you would not care if they did it via
> > screenshots? Or you only go after them if they steal it "the right way" by
> > stealing the xml? :)
> >
> > Anyway, i'm asking "what is your end game" not regarding this security,
> > but more in response to Sacha's comment. Seems like your tool would be much
> > better - and sell a lot more - if it was based on krpano.
> >
> > your pano is still on 360cities, it will earn enough ad revenue to buy you
> > a beer when you come to prague. unless you want me to remove it?
> >
> > cheers,
> > jeffrey
> >
> >
> >
> >
> >
>

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2897 / Virus Database: 2639/6092 - Release Date: 02/09/13

Exactly my point!!
Quentin

On 2/11/2013 7:38 PM, jimbo wrote:
> but even real encryption can still be cracked since viewing requires
> decryption

NO way.

prove it. show me a picture of your hand, and a nexus 7.

--- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord  wrote:
>
>
> A Nexus7 tablet is smaller than my hand ....

Hey great! Another challenge!
You guys are spoiling us!

....oh dear....

Cheers!

Erik Leeman

--- In PanoToolsNG@yahoogroups.com, "giant_klobasa_monster"  wrote:
>
> NO way.
>
> prove it. show me a picture of your hand, and a nexus 7.
>
> --- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord  wrote:
> >
> >
> > A Nexus7 tablet is smaller than my hand ....
>

this is true.


EVERY SINGLE INQUIRY we get from a potential client wants the ability to show
the panos on "mobile devices"

so hate all you want, but in the end, do you want to feed your kids or just sit
around complaining that the world is not fair?

for the record, i use apple and android and windows, and they're all CRAP! :-)



--- In PanoToolsNG@yahoogroups.com, Keith Martin  wrote:
>
> On 10 Feb 2013, at 16:23, Trausti Hraunfjord  wrote:
>
> > I don't find much REAL use for displaying panos on phones and small tablets
> >
>
> While some don't, others do. For example, the two different organisations I'm
doing pano work for at the moment both have mobile device support as a primary
requirement. In my experience, iOS-friendly panos are a must, right here and
now. Willy's recent posting of iOS usage stats is also interesting, and it shows
that these so-called iToy things are getting significant use.
>
> Ormar made an interesting point; we *are* aiming for ever-higher resolution
panoramas but have to accommodate devices with tighter memory requirements and
smaller screens than we've seen on the desktop for a while. But we're still
delivering to desktop-OS devices as well, and higher-res originals mean we can
be more precise about production accuracy before we optimise output for smaller
screens. (If anyone finds their work is always larger than they need, shoot and
process at lower resolutions and speed up the workflow!)
>
> I teach publishing up to postgrad level, and I'm the technical editor of a
major computer magazine; it's my business to have considered, professional
opinions on these topics. Support these devices or don't, it's everyone's
choice. But trust me, even if you don't like them, they're here to stay and they
are a major part of everyone's future, one way or another. Hence my choice in
tools.
>
> k
>

On 02/12/2013, at 10:10 PM, giant_klobasa_monster wrote:
> EVERY SINGLE INQUIRY we get from a potential client wants the ability to show
the panos on "mobile devices"
> [ snip ]
> for the record, i use apple and android and windows, and they're all CRAP! :-)


Ahhh, but we've been spoilt by big, high res screens, expecting crisp high res
images, and for many of us, our eyes aren't what they used to be 20 years ago
;-)

The "mobile" generation are after instant gratification, cheap drinks rather
than quality wine. They haven't developed a discerning palate and in the race to
do things faster or easier may never do ...

Cheers,
KathyW.

Creative long-exposure use of a 30 camera "bullet time" rig.
https://vimeo.com/59474122
Lots of results here:
http://360player.nl/

I've seen this setup in person. It was fun to hear the cameras beep in quick
succession as they turned on and started taking pictures.


'do

The day I can create a Pano, with HDR on a tablet will be the day I start to use
one seriously! Until then they are effectively read/display only devices.

I got a Nikon 1 V1, the Nikon entry into the mirrorless camera arena,
yesterday and took the first pictures with it today. It takes RAW 10
megapixel images at 14 bit, I think, I'll have to check that.

I am happy with the image quality. I have a Nikon D200 and I think the
V1 matches or maybe even surpasses the images from the much bigger and
heavier D200. It doesn't have the good bracketing capabilities of the
D200, so if I am going to be photographing Sequoia groves or something I
will still need to lug the DSLR gear, but for most uses the N1 looks
like it is going to work.

The interpretive staff at Grand Canyon National Park commissioned me in
2011 to shoot a panoramic image from Plateau Point inside the Canyon
that is now an 18' x 6' mural that is the main attraction at one end of
the new main visitors center, right next to the entrance to the theater
where they screen the Ken Burns film on the Grand Canyon in continuous
loop. I shot that image with the ten megapixel D200. (many, like 175,
exposures stitched to the final image using an 85 mm (in 35 mm terms) lens.

The kit with the V1 and the 10-30 and the 30-110mm lenses is still
available at B&H and is priced at an $800 discount at $399. They won't
last long, so if you have been debating getting into the mirrorless
world, now is the time.

http://www.stevehuffphoto.com/2011/11/14/the-nikon-v1-camera-review-the-camera-i\
-expected-to-hate/

http://www.stevehuffphoto.com/2012/07/16/camera-strangelove-or-how-i-learned-to-\
stop-worrying-about-the-sensor-and-love-the-camera-by-craig-litten/

http://www.bhphotovideo.com/c/search?atclk=Category_Mirrorless+System+Cameras&ci\
=16158&N=4288586281+4291315846

Sample pano at 1/4 resolution. Shot with raw with the 30-110mm in
program mode and iso 100 at 35.89 mm focal length. 8 images

http://inyopro.com/images/carson_and_colorado_.5.jpg

That train is at the Eastern California Museum about 2 blocks from my
house. The Carson and Colorado was a steam powered narrow gauge railroad
that ran through the length of the Owens Valley up until 1960.
Unfortunately no one understood the tourism value of old steam trains
and the tracks were torn up and sold for scrap. We have a locomotive
here in Independence that we are restoring and will be laying a mile or
so of track so we can run the train at least a little bit.

Paul Fretheim

Thanks Blochi,
I'll have one!
Michael

--
Michael Bajko BFA
The Fine Art Of Panoramic Photography
Waimate, Ssouth Canterbury
Aotearoa/ New Zealand

That day has come already, Microsoft's new tablet should allow you to do
that..

Joost

On 13/02/2013 21:59, g8dhe wrote:
> The day I can create a Pano, with HDR on a tablet will be the day I start to
use one seriously! Until then they are effectively read/display only devices.
>
>
>
> ------------------------------------
>

Hi Fabio
Did you try to run Photoshop as an Administrator?. I struggled a long time with
PTCorrect on Photoshop CS6 before reading Jim Watter's notes on his site (just
before writing to him!).
All other plug-ins worked but PTCorrect...After running as an Administrator all
went fine
Jean Huberson

--- In PanoToolsNG@yahoogroups.com, Jim Watters <jwatters@...> wrote:
>
> Yes that version does suffer that issue after a few uses of larger images.
>
> I have been very slow at getting a new version out.  Right now I still have a
few days left to a vacation.  The new version does not seam to suffer this
problem but still needs some features to have everything as the current version.
>
> A search of this list will find a link to a beta 64bit Windows version.
>
> Sent via phone.
>
> Jim Watters
> http://photocreations.ca
>
> Fabio Bustamante <contato@...> wrote:
>
> >Hey Fernando,
> >
> >Comming to think of it, I think I've been using his versions of the
> >plugins. I just thought that some other version could be more stable.
> >
> >Fact is my panotools plugin for PS (specially the adjust) is a bit
> >buggy. Every time I apply it to a certain number of images it starts
> >giving an error message and I have to restart PS. And now that I'm
> >working with higher resolution images, I have to do it more ofen (every
> >2 or 3 uses), which is starting to become annoying. So I figured that
> >maybe a different version could be free from this bug.
> >
> >Do you have any idea why PS doesn't recognize the 8BF plugins from the
> >sourceforge page? BTW, did you ever encounter this bug?
> >
> >Regards,
> >
> >Fabio
> >
> >Em 02/12/2010 16:09, Fernando Chaves escreveu:
> >> Hi Fabio,
> >> I'm using the installer from Jim Watters, on winvista 32.
> >>
> >> http://www.photocreations.ca/panotools/index.html
> >>
> >> It works fine in ps3, ps4 and 5 (32 bits).
> >>
> >> Best regards,
> >>
> >> Fernando
> >> -----Message d'origine-----
> >> De : PanoToolsNG@yahoogroups.com [mailto:PanoToolsNG@yahoogroups.com] De la
> >> part de Fabio Bustamante
> >> Envoyé : 2 décembre 2010 12:27
> >> À : PanoToolsNG@yahoogroups.com
> >> Objet : [PanoToolsNG] Filters for PS
> >>
> >> Today I decided to check out the newer version of the PT plugins for PS,
> >> since the ones I'm using here are so old I can't even remember where I
> >> got them.
> >>
> >> Problem is that after I place the files in PS's plugins folder, it
> >> apparently does not recognizes them. I'm placing the files
> >> (PTAdjust.8BF, PTCorrect.8BF, etc.) in the same folder the old ones used
> >> to be, but after PS is launched the "filter" shows no panotools option.
> >> Aparently they won't work both on PS 32 and 64 bits. These newer files
> >> are quite bigger than my old ones (76kb vs 8,5kb).
> >>
> >> Any idea what I'm doing wrong?
> >>
> >> Thanks a lot.
> >>
> >>
> >>
> >>
> >>
> >> ------------------------------------
> >>
> >
> >
> >------------------------------------
> >
> >--
> >
> >
> >
>

Am 16.02.2013 15:54, schrieb Thomas:
> 1] do all PT family stitchers use the same coordinate system as original
> PanoTools?

As for Yaw, Roll and Pitch: Yes, as far as I know. The TrX, TrY, TrZ
mosaic coordinate model is unique to hugin/nona. PTGui uses a different
model with 5 coordinates: VPx, VPy, VPz, VPpan and VPtilt. They are not
documented (AFAIK) but Helmut Dersch found them out for himself and
implemented them in PTStitcherNG.

Furthermore PTGui uses PTStitcher o-line C-coordinates while hugin/nona
use S-coordinates. That means hugin coordinates are relative to the
complete source image while PTGui coordinates are relative to the
cropped image specified by the C-coodinates (the crop rectangle/circle).
See
http://wiki.panotools.org/PTStitcher#o-line_options for details

--
Erik Krause
http://www.erik-krause.de

On 2013-02-17 6:47 AM, Erik Krause wrote:
> Am 16.02.2013 15:54, schrieb Thomas:
>> 1] do all PT family stitchers use the same coordinate system as original
>> PanoTools?
> As for Yaw, Roll and Pitch: Yes, as far as I know. The TrX, TrY, TrZ
> mosaic coordinate model is unique to hugin/nona. PTGui uses a different
> model with 5 coordinates: VPx, VPy, VPz, VPpan and VPtilt. They are not
> documented (AFAIK) but Helmut Dersch found them out for himself and
> implemented them in PTStitcherNG.
  From Helmut: "PTGui uses a 2-axis pan/tilt + 3-d translation, in that order"
http://tech.groups.yahoo.com/group/PanoToolsNG/message/39331

Dev Ghosh who originally worked on the mosic mode for Hugin during a GSoC, but
never got finished, has just posted on the hugin-ptx list, "mosaic mode with
intuitive warp parameters", that he is implementing his original method to
create orthogonal views.



>
> Furthermore PTGui uses PTStitcher o-line C-coordinates while hugin/nona
> use S-coordinates. That means hugin coordinates are relative to the
> complete source image while PTGui coordinates are relative to the
> cropped image specified by the C-coodinates (the crop rectangle/circle).
> See
> http://wiki.panotools.org/PTStitcher#o-line_options for details
Yes the GUIs of PTGui and Hugin use different cropping models.
http://tech.groups.yahoo.com/group/PanoToolsNG/message/6212
PTStitcher definitely understands both.

--
Jim Watters
http://photocreations.ca

Thank you Jim and Erik.

The references on PTStitcher are helpful.

I am having a devil of a time figuring out how to apply PTGui y,p,r to a
panosphere having a right-handed coordinate system (meaning my X axis points
left) Like PT, view is centered on (0,0,1) at y=p=r=0.  Inverting the X axis in
the rotation matrix seems to give correct alignments, however my projection
mapping fns then fail.

I need to invert the hand again without losing the alignment, this is surely
possible but I can't find the right way to do it.

Alternatively I could revert to left-handed coords, which Panini used for a long
time, but I feel a bit stubborn since it took some effort to convert everything
to right-handed.

-- Tom

--- In PanoToolsNG@yahoogroups.com, Jim Watters <jwatters@...> wrote:
>
> On 2013-02-17 6:47 AM, Erik Krause wrote:
> > Am 16.02.2013 15:54, schrieb Thomas:
> >> 1] do all PT family stitchers use the same coordinate system as original
> >> PanoTools?
> > As for Yaw, Roll and Pitch: Yes, as far as I know. The TrX, TrY, TrZ
> > mosaic coordinate model is unique to hugin/nona. PTGui uses a different
> > model with 5 coordinates: VPx, VPy, VPz, VPpan and VPtilt. They are not
> > documented (AFAIK) but Helmut Dersch found them out for himself and
> > implemented them in PTStitcherNG.
>  From Helmut: "PTGui uses a 2-axis pan/tilt + 3-d translation, in that order"
> http://tech.groups.yahoo.com/group/PanoToolsNG/message/39331
>
> Dev Ghosh who originally worked on the mosic mode for Hugin during a GSoC, but
> never got finished, has just posted on the hugin-ptx list, "mosaic mode with
> intuitive warp parameters", that he is implementing his original method to
> create orthogonal views.
>
>
>
> >
> > Furthermore PTGui uses PTStitcher o-line C-coordinates while hugin/nona
> > use S-coordinates. That means hugin coordinates are relative to the
> > complete source image while PTGui coordinates are relative to the
> > cropped image specified by the C-coodinates (the crop rectangle/circle).
> > See
> > http://wiki.panotools.org/PTStitcher#o-line_options for details
> Yes the GUIs of PTGui and Hugin use different cropping models.
> http://tech.groups.yahoo.com/group/PanoToolsNG/message/6212
> PTStitcher definitely understands both.
>
> --
> Jim Watters
> http://photocreations.ca
>

Am 17.02.2013 21:07, schrieb Thomas:
> I need to invert the hand again without losing the alignment, this is
> surely possible but I can't find the right way to do it.

Read on Euler angles: http://en.wikipedia.org/wiki/Euler_angles

(This is the exact point where my knowledge ends ;-)

--
Erik Krause
http://www.erik-krause.de