Notes on photo sphere/panoramic EXIF metadata

• Google's EXIF/XMP metadata tag specification for panoramic images
• Panorama images with sky are to have a negative value for the CroppedAreaTopPixels tag. (The panoramic viewer of Facebook ignores the value altogether, though, and assumes the horizon in the middle of the picture.)
• If a camera or software normally produces panoramic images with cylindrical projection, then doing a vertical capture actually produces a transverse cylindrical image. There is no standardized value for the EXIF ProjectionType field to cover this. (One option is to reproject them to equirectangular — which, again, is not very well supported.)
• Facebook's document on what tags to set
• The Facebook web interface insists that FullPanoHeightPixels be half the size of FullPanoWidthPixels. Else you get “no new photos were uploaded”.

/ Tags: Photo.

IPv6 at home: proto-50 instead of proto-41

SIXXS and HE (two tunnelbrokers I significantly used in the past) have certain limitations, so running IPv6 over a VPN tunnel to a dedicated server is something I considered. Root of the problem is of course the set of inert German ISPs that will not budge a quad in delivering IPv6, especially in light that RIPE's pool has now also reached the restricted giveaway mark.

SIXXS. Convoluted registering scheme. You need to deal with RIPE handles, wait for human approval, request a pointtopoint tunnel (though it is a /64, it only serves tun::2/128 to your end), wait for human approval, use the “aiccu” tool (maintenance is lacking), request a real /64 route (for e.g. virtual machines), wait for human approval, request nameserver delegation, wait for human approval. Oh, did I mention waiting for approval?

Hurricane Electric. Register. Create /64 routed tunnel. Set DNS delegation. Configure local end, done. One can set the tunnel parameters in a scripted fashion, but there seems to be no aiccu-like tool for users with dynamic addresses. But for servers with static addresses, this is just excellent and quick.

While both SIXXS and HE essentially use IP6-in-IP4 (SIT, sometimes called “proto-41”) transport, my approach sports a IP6-in-ESP4 (proto-50) connection. The upside is that you can use well-established, well-maintained tools (like StrongSWAN) to connect. They will deal with a dynamic endpoint address, NAT, let you choose between passwords and certificates, and encryption to the other endpoint if so desired. If you are running a dedicated server yourself, you will have full control of DNS records, addresses, routing and so on. The following was verified to work with kernel 3.4 and strongswan-4.5.3.

# client-side ipsec.conf
conn nakamura-seven
        left=%defaultroute
        leftsubnet=2001:db8:61:1fa::dead:beef/128
        leftid=@laptop-beef.company.de
        right=192.0.2.1
        rightsubnet=192.0.2.1/32,::/0
        rightid=@vpn.company.de

# server-side ipsec.conf
conn seven-nakamura
        left=192.0.2.1
        leftsubnet=192.0.2.1/32,::/0
        leftid=@vpn.company.de
        right=%any
        rightsubnet=2001:db8:61:1fa::dead:beef/128
        rightid=@laptop-beef.company.de

For the %default section, see an earlier post. You will also need to make sure that 2001:db8:61:1fa::dead:beef/128 is present on the client-side internet-facing interface — before the connection is established, or you will get a “no local address found in traffic selector 2001:db8:61:1fa::dead:beef/128” error. Having the address set may involve some work of your own at the distribution level, especially when the distro is set to use DHCP by default, or when things like NetworkManager make it all the more difficult. The leftupdown= variable cannot be used to add/delete the IPv6 address, as the script is executed too late and would get you in exactly that aforementioned error.

Posted 2012-09-15 08:09 / Tags: Ipsec, Ipv6, Linux, Networking. / link