Kolor has closed

(Damon Lynch) #21

Yes. I own a license to Autopano Pro and I only used it with TIFF files as input. AFAIK Autopano Giga is like Pro but with more features. If there is a special license that ties it to one camera model, I know nothing about that.

(Tobias) #22

Not me, but yes. Have a look at this links:

(Mica) #23

One would need to contact GoPro support to ask about freeing the source code.

(Tobias) #24

One would need to contact GoPro support to ask about freeing the source code.

I’m quoting from the first link in my last post:

John Story, Associate General Counsel and head of International Legal at GoPro, said that many months had been spent trying to find a better way forward, including open source, but with no success. “Open sourcing Panotour is not feasible,” he told us.


Nope, but since it’s proprietary there is no way to add support for the new cameras, raw files and new lenses.

I’ve tried Hugin yesterday with 16 jpg images to create a 360*180 panorama for VR purposes.
It failed to autodetect points so hard that it’s not even funny. PtGUI is similar to hugin, gives somewhat better results but not even close to Autopano.

I’ve been doing this for a few years now and my verdict is that there is no software suitable for Panorama stitching at scale at the moment. And I’ll go even further to say that an opensource alternatives will not be up to pair with Autopano for 10 years+.

So in my view, the only way is to:
a) somehow convince GoPro to release the source,
b) raise the funds to buy the software and release it as gpl
c) get a hold of some of the original developers to see if they are up for recreating the tech but in gpl, provided there is a way that they or the new project doesn’t get into a legal trouble.

One could start simply with change.org petition for GoPro to release the source and then gradually increasing the pressure trough emails, forums and social media.

The worst that can happen is, some other company filling the vacuum with another proprietary solution.

(Carmelo Dr Raw) #26

Any chance you could share a failing example, so that we can have a look? This might be a good opportunity of putting new efforts into hugin… for smaller panoramas, as far as my experience goes it work perfectly.


sorry for the redacted part. It’s an unreleased head.
So it was shot on 77D and Canon 10-18mm at 10mm.

Hugin failed to properly connect the panorama to the point where it was not worth the time to start manually adding points.
Autopano Giga on the other hand have no problem connecting it perfectly without any other input needed.

Here’s the link:


Let me know what you get :slight_smile:

(Tobias) #31


I used your images for a test. I:

  • downloaded the images
  • dropped them into hugin
  • hit the allign butten
  • hit the horizon straiten button
  • and then created the panorama
  • converted the panoramas to webp to reduce the size by 2 copared to the tiff files

The result is quite good. There is a small problem in the sky.


No way, My result is nowhere close to that.

I’ve tried again now a few times but every time Hugin doesn’t stitch anything, it exits with error saying it exited…

(exits the stitching and export, not the app)

(Tobias) #33

OK, then it looks like its a problem on your system. As I can’t help you here you should contact the developer via the hugin mailinglist:

(Carmelo Dr Raw) #34

@Tobias @KristijanZic
I confirm that stitching through Hugin’s assistant seems to work very well with the provided panorama. The only problematic image is the first one (the nadir image, I guess), for which I get some slight alignment glitches.

@KristijanZic: As a side note, I have seen that your shots have a quite limited overlap, and non-uniform white balance, as in this example:

A larger overlap would allow to better correct for lens distortions and vignetting, as well as provide a more comfortable set of control points for alignment.
Concerning white balance, it cannot be corrected accurately with images encoded in standard sRGB colorspace, due to the non-linear TRC.

Here is what I get with the full set of pictures: https://drive.google.com/open?id=1kv9iT-QtV6QfbwQy4ejFmo8NE9DCXwNt

Here is what I get without the nadir: https://drive.google.com/open?id=1nDo3IUjq4LAAFEz0jAFdKQ5cfUe_GmEU

Link to the .pto file: IMG_7381 - IMG_7396.pto (68.4 KB)

Notice that I have used the current development version for alignment and stitching. I still have to check if the current 2018.0 stable version gives different results or not…

The steps I followed are very simple:

  1. opened hugin with the “simple” interface, and loaded the images

  2. hit the “Align…” button to obtain this:

  3. went to the “Move/Drag” tab and hit the “Straighten” button:

  4. went back to the “Assistant” tab and hit the “Create panorama…” button. There, I selected JPEG as output format, and left everything else as it was:

Hope this helps!


@Carmelo_DrRaw @Tobias thank you so much to taking the time to test this out and to give me some useful info @Carmelo_DrRaw. You guys are saints.
Atm, I cannot get the thing to work correctly for me but I’m in the process of making a new PC build, so when I’m done I’ll be testing this heavily and judging by the results you two have presented me with, I think I might put Hugin as a default in my pipeline. Assuming I get it to work on a new build or find a bug and a dev willing to fix it ofc.

I have to say, I’m so amazed that it worked so well for you two. Hugin was the first software I tried many years back and it just didn’t work for me at all and that’s why I went with Autopano in the first place. It going out of business might be the perfect time for me to replace it with an open source solution :smiley:

If my machines specs are the issue, here they are:

OS: Ubuntu 18.10 x86_64
Kernel: 4.19.1-041901-generic
Uptime: 1 day, 4 hours
Packages: 2780 (dpkg), 52 (flatpak),
Shell: bash 4.4.19
Resolution: 1920x1200, 1680x1050
DE: GNOME 3.30.1
WM Theme: Adwaita
Theme: Adwaita-dark [GTK2/3]
Icons: Yaru [GTK2/3]
Terminal: gnome-terminal
CPU: Intel i5-2400 (4) @ 3.400GHz
GPU: AMD ATI Radeon RX Vega 64
Memory: 2843MiB / 3925MiB

In addition, I’m using the foss driver that’s in the kernel. Should I install amdgpu-pro?

I’ll be replacing the cpu with a Threadripper 1900x as soon as I get the ram, 16gb G-Skill (Samsung B-dye). I hope that fixes it, although I haven’t really looked at all at what the actual issue might be so fingers crossed.

(Mica) #36

I believe the Foss driver for that card is quite good!


Yeah, but it doesn’t have OpenCL support or ROCM, the proprietary one has that. Is that needed for Hugin?

(Mica) #38

OpenCL support in Hugin is experimental, but has worked pretty well for me using the proprietary nVidia driver.

(Carmelo Dr Raw) #39

What kind of problems are you encountering exactly?

I think your specs are fine, except maybe for the amount of RAM. OpenCL will speed up computations, but it will not improve the quality of the result.
Since you are using Linux, you might be interested in trying my Hugin AppImage packages. They would allow you to easily test the development version, without having to deal with complex dependencies.
You can find some details and instructions here:

This is the version I have used for stitching your photos…

EDIT: the not-so-hidden advertising of my Patreon page is purely intentional :wink:

(Carmelo Dr Raw) #40

It might be a problem of insufficient RAM… I get a similar problem when running Hugin in a virtual machine with 2GB of memory.


It launches much quicker than the deb version for some reason, but it gives the same result in terms of errors. “Batch renderer exited with errors”.

Also the generated log file is 237mb of pure text! Is that normal?

Yeah, I know about your patreon, you’ve already saved me once with a Gimp 2.10 appimage when I needed G’MIC to work, it’s just that I’m waiting to make one video to hopefully promote that entire “foss business model” to the uninitiated.
So I’ve had an idea about a youtube video for a while now, in which I’ll be ditching my Netflix, Deezer, Spotify and other subscriptions and distributing that money to the FOSS projects that I use and would like to support, also to the developers that I follow and that have patreons.

Unfortunately there are some projects that just refuse donations or are scared that then ppl will hold them accountable to do more work or something. Darktable devs do it just for fun as I understand and Kdenlive just forwards everything to the KDE foundation. Also while we’re at it, Hugin doesn’t accept donations either. Their donate button just links to a 404 sourceforge page…