Re: [hugin-ptx] Nothing but green

[Stefan Peter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Macr

On 15.10.2013 09:45, mac...@gmail.com wrote:
> Sorry if this is a repost but I can't see my original post.

I see it. However, this is a mailing list, you will have to allow some
time to pass until all mail servers involved have done their virus and
spam checking.

> Anyway, from the beginning. I have installed Hugin from the Fedora
> package system and it appears to have installed ok, but every time
> I try to stitch an image I get a result like the one attached. Any
> idea what I or the program is doing wrong?

I have never seen anything like this output. And for me, it doesn't
contain enough information to deduct the cause of this behaviour. Can
you send us the .pto file hugin has created for this "pano"? And some
more detailed information like, for example, version numbers for hugin
and fedora could help, too.

With kind rgards

Stefan Peter


- --
In theory there is no difference between theory and practice. In
practice there is.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSXPZZAAoJEBgqi52L7+L/qmAH/21e2M3OLMSxuD+B7oGkYLt5
XyQqhbxOlTWjrrfjXomRBbcBrckpP/nB3CY1tax3rX9ApxZYBgNXcr8YMP3M+6cJ
AvW8b5+qAfanZVn8++0mCEv82wn+F3XwPtIjcCuJq7NM3L79Rf427OAyTHtARoDx
2PwYayeQ1FUKzNEj9/5OfOCsQd8qXODr+0eT56JcdsKgMSR00YdJWrLMJMbO/Xe1
11LbKpa1pPiQwL0Qapg5+qoIDz0aqTHfEtOglfrlCjBWGM0QVQrQsrfYRDPaWQfy
dJ4ZvPddN6SWUeSuGlQdHBP6/1lqT0THXRUDknPJ4XRLBTxLopJOv/xYJByaAvA=
=HpCX
-----END PGP SIGNATURE-----

[mac...@gmail.com]

I certainly can Stefan.
Here you go.

Operating System: Linux 3.10.10-100.fc18.x86_64 x86_64
Architecture: 64 bit
Free memory: 6282572 kiB

Hugin
Version: 2012.0.0.a94faa15c927
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Path to user lensfun database: /home/macr/.local/share/lensfun

Libraries
wxWidgets: 2.8.12.0
libpano13: 2.9.18
Boost: 1.50.0
Exiv2: 0.23.0

Regards

Macr

[Bruno Postle]

Hi Macr, there are some strange things in your .pto project: there is a very large lens distortion and the photos are in the project twice which is triggering an unnecessary exposure fusion step.

But otherwise it is ok, you should get an image resembling a panorama from this project. My best guess is that something in the tool chain doesn't like your TIFF files.

How did you create these TIFF files? can you upload one somewhere? If they are too big, the output from `tiffinfo NMA_Centre.tif` or `identify -verbose NMA_Centre.tif` would be useful.

--

Bruno

On 15 October 2013 10:58, <mac...@gmail.com> wrote:

Operating System: Linux 3.10.10-100.fc18.x86_64 x86_64
Architecture: 64 bit
Free memory: 6282572 kiB

Version: 2012.0.0.a94faa15c927

 

wxWidgets: 2.8.12.0
libpano13: 2.9.18
Boost: 1.50.0
Exiv2: 0.23.0

 

--
Bruno

[mac...@gmail.com]

Bruno. I have deleted every TIF that has been created except the original 3.
I am currently running the process again.
The TIFs were created using Corel AfterShot Pro. No adjustments, just saved as TIF.

On Tuesday, October 15, 2013 7:01:29 PM UTC+11, Stefan Peter wrote:

[mac...@gmail.com]

Hey look,
it has changed colour, but still no better.

[Stefan Peter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Macr

On 15.10.2013 11:58, mac...@gmail.com wrote:
> I certainly can Stefan. Here you go.
>
> Operating System: Linux 3.10.10-100.fc18.x86_64 x86_64
> Architecture: 64 bit Free memory: 6282572 kiB
>
> Hugin Version: 2012.0.0.a94faa15c927 Path to resources:
> /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ Path to
> user lensfun database: /home/macr/.local/share/lensfun
>
> Libraries wxWidgets: 2.8.12.0 libpano13: 2.9.18 Boost: 1.50.0
> Exiv2: 0.23.0

Thanks for the info. As it looks, you are using a rather up-to-date
version of hugin, so no complaints here.

So I went back and had a look at your pto file. In addition to the
issues already mentioned by Bruno Postle, I saw
o you can not have a rectilinear output projection with
an output field of view > 90 degrees
o with 3 only partially overlapping images, "exposure fused
from any arrangement" does not make any sense.

I reset all the parameters to sane values, but I could not get a
decent output from this set.

So I tried to redo the pano: I took the 3 images and created a new
pto. I manually set the positions from your pto to my pto. With an
output projection set to cylindrical, I was able to get an ok looking
output. So, why doesn't it work with your pto? I will have to
investigate this more thoroughly, but further investigations showed
that this has nothing to do with your problems.

The next thing I tried was to manually copy over your control points
to my pto so I could run the optimization. Much to my horror, a simple
optimization for "Positions and View (y,p,r,v)" resulted in a focal
length of 299 mm for the lens.

Together with the weird lens and photometric parameters in the
original pto, I have to conclude that this pto simply is over
optimized. Unfortunately, the pto optimizer actually is capable of
this. If given enough variables to optimize with not enough data
points, the solver will find a solution that mathematically makes
sense, but photographically does not so. Maybe we should limit the
scope of the optimizer accessible by the user based upon FOV or number
of images, at least in the simple interface?

Anyhow, although I don't have the actual images, I suppose that you
simply want to create a "wide image" composed from 3 24mm images. I'd
propose the following:

o create a new project in hugin
o set the Interface to "simple"
o add your 3 images to this project
o make sure the lens type is set correctly
(if the 24 mm focal length of your pto
is correct, most probably "Normal (rectilinear)"
is correct, too).
o use the "2. Align.." button to create control points
between your images.
o Use the "3. Create panorama ..." button to get a first
result.
If this gets you some halfway decent result, you can make a copy of
your .pto file and set the interface mode to advanced or expert. In
these modes, you have a very fine grained control about all the
"obscure" parameters of your panorama. But be aware, using the expert
interface without being an expert may result in non usable output.

If you have any questions, please make you heard on this mailing list.

With kind regards

Stefan Peter

- --
In theory there is no difference between theory and practice. In
practice there is.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSXYC1AAoJEBgqi52L7+L/PgMH/0yCGSl1w7QXR7IeVzGdOYIh
x6SmXl/YIFZtmgch5sF5upFjAPXY6+RHXdO7cDN6e6MPFO77MqV616meeKpDzSmh
cPe/Lou5iZwF1te4dKYN+2M73rwbdpWy3AUKPMRrf2iUCRM2CCD34Hr7XFwMttJo
z7VZXaPQRiAWV/wnvbiWp3kFCBUjUhbr49XsQTNSgUd8D8yzsMoH5OPhq5GSKVJR
ulfppR6Xq4cHw5QX1w0d4Rqa15H3f8QAFQRy5qP33IU29pYxRvNYWTnW6gwD831X
JZX3bTw0CYervj+JYw+3qwMIYKJ5hncZJpx3QAE9iT7+D2X5GhH0SO0uULEZ/rc=
=ATAU
-----END PGP SIGNATURE-----

[mac...@gmail.com]

I see where the issue is and I think this will end up with a blame game.
I still get bad images using Corel AfterShot Pro (ASP) to convert the image to TIF format. When I use UFRAW, then I can create a pano. But here is the rub, I cannot open the subsequent TIF in (ASP).
I am now certain that ASP has an issue, as I raised an issue about metadata disappearing when I opened a tif converted in ASP in GIMP.

This doesn't help me as I would like to be able to process the image in ASP.

[Rogier Wolff]

On Tue, Oct 15, 2013 at 07:51:49PM +0200, Stefan Peter wrote:
> The next thing I tried was to manually copy over your control points
> to my pto so I could run the optimization. Much to my horror, a simple
> optimization for "Positions and View (y,p,r,v)" resulted in a focal
> length of 299 mm for the lens.

...

> simply want to create a "wide image" composed from 3 24mm images. I'd
> propose the following:

You should optimize "v" or viewing-angle only if you have a 360 degree
pano.

When you have a 24mm lens, three pictures won't take you all the way
around.

If you'd take something like 18 pictures at 24mm and go all the way
around, the mathematical viewing angle calculated from the 24mm focal
length will differ slightly from the actual viewing angle. This will
make the first and last picture "not fit". To correct for this you
can optimize "v" as well. However this does not make sense to do when
you have only a 90 degree total viewing angle.

Of course, the "difference" will still be there, but it won't
influence the actual pano-sphere that much. Just a little scaling
around the center.

Roger.

--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

[Stefan Peter]

Hi Macr

On 15.10.2013 22:07, mac...@gmail.com wrote:
> I see where the issue is and I think this will end up with a blame game.

A blame game? We don't play any games here. We are strictly hugin
related business here, aren't we?

> I still get bad images using Corel AfterShot Pro (ASP) to convert the
> image to TIF format.

I use ASP (almost) exclusively here for all my images fed into hugin and
I can not confirm any issues with this process. However, if your export
settings do not allow the inclusion of metadata, it may be a little more
complicated as you will have to enter things like focal length or focal
length multiplier required by hugin manually. Failing to do so may
actually lead to "funny looking panoramas". But in order to confirm this
to be a problem in your case, you'd have to follow Brunos advice and
either publish your tiffs or, at least, their metadata as mentioned in [1].

When I use UFRAW, then I can create a pano. But
> here is the rub, I cannot open the subsequent TIF in (ASP).

There are different reasons why a tiff/jpeg/exr can not be opened. In
the case of ASP, there are size constraints (see [2]) and the fact that
tiffs with an alpha channel can not be opened or even displayed. What
happens if you set the hugin output to jpeg? Can you open this with ASP?
Can you open the tiffs with the image viewer?

> I am now certain that ASP has an issue, as I raised an issue about
> metadata disappearing when I opened a tif converted in ASP in GIMP.

Check your ASP export settings: If metadata is being stripped on the
export step, it won't be in the file, no matter what application you use
to search for it. And be aware that gimp is not really suited to handle
or display metadata. For gimp, tiff is an export data and gimps native
xcf format does not support much in terms of metadata,

>
> This doesn't help me as I would like to be able to process the image in ASP.

What does not help you? Please remember that this mailing list is not
devoted to ASP support and this is your first email actually mentioning
ASP. How should we have known that this is your problem?

With kind regards

Stefan Peter

[1] https://groups.google.com/d/msg/hugin-ptx/t3vV_UX6ysc/hvlzob4lu_kJ
[2]
http://product.corel.com/help/AfterShot/540111115/Main/EN/Doc/supported_image_formats.html


--
"In summary, I think you are trying to solve a problem that may not
need to be solved, using a tool that is not meant to solve it, without
understanding what is causing your problems and without knowing how
the tool actually works in the first place :)"
Jeffrey J. Kosowsky on the backuppc mailing list

[David W. Jones]

Hmm, makes me glad I stuck with Bibble Lite. I've heard that ASP is very
buggy.

Very rarely, Bibble would export an image with no metadata, no matter
what I tried. Then someone on the original Bibble support forums said to
delete Bibble's cache folder. I don't know where that would be with ASP
or Windows; Linux Bibble Lite 5 stores it in a hidden folder in the home
folder: .bibble5.

That fixed the problem. Maybe ASP is having the same problem?

--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

[mac...@gmail.com]

On Wednesday, October 16, 2013 7:57:48 AM UTC+11, Stefan Peter wrote:

Hi Macr

On 15.10.2013 22:07, mac...@gmail.com wrote:
> I see where the issue is and I think this will end up with a blame game.

A blame game? We don't play any games here. We are strictly hugin
related business here, aren't we?

Stefan, I may not be explaining myself well enough. Let me go back in time a little and explain what I mean.
I always produce images with EXIF/Metadata and export them with this information. Some times I will export an image (TIF) from ASP to do some ancillary processing in GIMP (I don't like to, as GIMP is only 8 bit, but that is beside the point). It leaves with Metadata and disappears when opened. I then have to use EXIFTool to copy the EXIF from the TIF which I exported from ASP into the JPG exported from GIMP. IIRC when I posted this on the ASP forum, they said it was an issue with GIMP and vice versa on the GIMP forum.
Now I export TIF with all the EXIF/Metadata from ASP to Hugin and it accepts the image files and creates the new files for stitching, but the output becomes a green or red image.
Then I do the same with UFRaw to Hugin and it produces a panorama which I can view with GIMP and image viewer, but does not turn up in ASP when I right click -> Open with ASP. Even when I refresh the folders, I cannot see the final output, but I can see the 3 images for Left, Right and Centre.

> I still get bad images using Corel AfterShot Pro (ASP) to convert the
> image to TIF format.

I use ASP (almost) exclusively here for all my images fed into hugin and
I can not confirm any issues with this process. However, if your export
settings do not allow the inclusion of metadata, it may be a little more
complicated as you will have to enter things like focal length or focal
length multiplier required by hugin manually. Failing to do so may
actually lead to "funny looking panoramas". But in order to confirm this
to be a problem in your case, you'd have to follow Brunos advice and
either publish your tiffs or, at least, their metadata as mentioned in [1].

Where would you like me to publish these images and which ones? The three created by ASP, the three created by UFRaw or the final image created by Hugin from the UFRaw conversion, that I cannot see in ASP?

When I use UFRAW, then I can create a pano. But
> here is the rub, I cannot open the subsequent TIF in (ASP).

There are different reasons why a tiff/jpeg/exr can not be opened. In
the case of ASP, there are size constraints (see [2]) and the fact that
tiffs with an alpha channel can not be opened or even displayed.

Looking at the reference you posted, I found this:

Up to 30 megapixels and 10,240 pixels on the longer side, RGB colorspace (CMYK, grayscale or TIFFs with alpha channel not supported)

Some adjustment tools are more limited or are not available (Highlight Recovery) with TIFF files.

I think my image just squeezes under that dimension. 4929 x 2037. Actually that is under half of that stated dimension.

Can I remove the Alpha channel on export to edit it in ASP? Actually does Hugin create the alpha channel or does UFRAW?
 

What
happens if you set the hugin output to jpeg? Can you open this with ASP?

I will try for the sake of your investigation, but opening a jpeg, just defeats the very reason that I converted them to TIF in the first place.

Can you open the tiffs with the image viewer?

Yes I can.

> I am now certain that ASP has an issue, as I raised an issue about
> metadata disappearing when I opened a tif converted in ASP in GIMP.

Check your ASP export settings: If metadata is being stripped on the
export step, it won't be in the file, no matter what application you use
to search for it. And be aware that gimp is not really suited to handle
or display metadata. For gimp, tiff is an export data and gimps native
xcf format does not support much in terms of metadata,

As stated earlier I do not strip EXIF/Metadata.

>
> This doesn't help me as I would like to be able to process the image in ASP.

What does not help you?

The fact that I cannot still post process my images in ASP, as I cannot see them.
 

Please remember that this mailing list is not
devoted to ASP support and this is your first email actually mentioning
ASP.

Fully understand that, that is why my next stop is to the ASP forum, to see if they have a solution why it cannot output the pano generated by Hugin
 

How should we have known that this is your problem?

You shouldn't have, that is why I mentioned it in my last post!

With kind regards

Stefan Peter

Regards

Macr

[Stefan Peter]

Hi Macr

On 16.10.2013 10:12, mac...@gmail.com wrote:
>
> On Wednesday, October 16, 2013 7:57:48 AM UTC+11, Stefan Peter wrote:
> Hi Macr
>

> On 15.10.2013 22:07, mac...@gmail.com <javascript:> wrote:
> > I see where the issue is and I think this will end up with a blame
> game.
>
> A blame game? We don't play any games here. We are strictly hugin
> related business here, aren't we?
>
>
> Stefan, I may not be explaining myself well enough. Let me go back in
> time a little and explain what I mean.
> I always produce images with EXIF/Metadata and export them with this
> information. Some times I will export an image (TIF) from ASP to do some
> ancillary processing in GIMP (I don't like to, as GIMP is only 8 bit,
> but that is beside the point). It leaves with Metadata and disappears
> when opened. I then have to use EXIFTool to copy the EXIF from the TIF
> which I exported from ASP into the JPG exported from GIMP. IIRC when I
> posted this on the ASP forum, they said it was an issue with GIMP and
> vice versa on the GIMP forum.

This is true, I think. Gimp does, at least according to my experience,
simply ignore exif data. However, for hugin this is not a real problem
because all hugin wants to know is the focal length and the focal length
multiplier of the input files. Gimp removing this information actually
is understandable: If you open an image in Gimp and crop it, the
original exif information simply does not apply anymore. So, better
supply no exif information than supplying wrong exif information.

> Now I export TIF with all the EXIF/Metadata from ASP to Hugin and it
> accepts the image files and creates the new files for stitching, but the
> output becomes a green or red image.

As I have mentioned before, I use ASP as well and I never had any
problem manifesting itself in a similar manner. The worst I had with ASP
generated images using an export setting that did not honor the exif
data was that hugin asked me for the focal length and the focal length
modifier for the shots. But, as I have a manual lens that does not
provide any exif data anyway, I am used to enter these values manually.
And hugin will recalculate the field of view anyhow, the numbers entered
(or read from the exif data) server as a starting point only.
So, I don't think that missing exif data are the problem here.

> Then I do the same with UFRaw to Hugin and it produces a panorama which
> I can view with GIMP and image viewer

I have to digress here, sorry: Hugin tries to find out the shooting
angle for every image you feed it. In order to be able to do this, it
tries to find points in image A that correspond to points in image B.
This is called "control point detection" and this procedure can go
totally haywire. There is some really nifty math involved that totally
eludes my understanding, but it is not magic: Every so often, control
points are misplaced to a degree that a human observer could identify
easily. And this is where _you_ come into play: You are expected to
delete all control points that obviously don't make sense. I normally
use the View->Conreol point table (available in advanced or expert
Interface only) to hunt for control points with large distances an
remove them.

Now, why could it be that two raw converters produce output that results
in different control point detection by hugin? The control point
detection algorithms may look like pure magic to a mathematically
challenged being like me, but they use water to cook, too, in the end.
Different sharpening, different contrast, different resolution or
different colors may lead to different control points being found.

, but does not turn up in ASP when
> I right click -> Open with ASP.

In order to remove the alpha channel, I normally use the command line
convert in.tif -alpha off out.tif
or
convert in.tif -background white -flatten +matte out.tif

Both commands have to be issued from a terminal (command line) and
actually work only if ImageMagick is installed. I'm sure that there is a
plethora of other applications available that can be used for this purpose.

> length multiplier required by hugin manually. Failing to do so may
> actually lead to "funny looking panoramas". But in order to confirm
> this
> to be a problem in your case, you'd have to follow Brunos advice and
> either publish your tiffs or, at least, their metadata as mentioned
> in [1].
>
>
> Where would you like me to publish these images and which ones? The
> three created by ASP, the three created by UFRaw or the final image
> created by Hugin from the UFRaw conversion, that I cannot see in ASP?

Well, you have to understand that I can not help you with ASP issues in
this context: All I care here are hugin related problems. Therefore, I'd
like to see are
o the tiff files (from ASP) that result in the "nothing but green" pano
o the pto you actually have used for creating this pano

Depending on if I find out why hugin is not able to create a decent
panorama from this input, I may ask you for the raw files at a later
point in time.

Regarding the means to get these images to us/me:
o try to send them to this mailing list if copyright rules
allow to do this: Whatever you send here is in the open
and possibly could be snatched by whoever is interested in
the content. And obviously, I don't have a clue
about the rules for attachments on this list ;) You may have
to send each image in a separate email in order to circumvent
any size limitations possibly in place.
o you could try to send the images directly to my email address.
As far as I know, all emails not exceeding 1 GBytes are accepted
here, but because this changes daily nowadays, I can not guarantee
reception. You may want to send one email per image in order to
not trip any attachment size limitation in place.
o you may have an online representation like a homepage or
blog where you could put the files.
o finally, there are services like "you send it" (http://yousendit.com)
or dropbox (https://www.dropbox.com/) that allow you to share
large binary files.

If none of the options above work for you, please contact me privately,
I may be able to rig up something along these lines.

With kind regards

Stefan Peter

[Mark McIntosh]

Stefan,
It looks like the command line Alpha off works well with the .tif created by using UFRaw.
Thanks for that tip. Now at least I can send a tif back to ASP for processing.

Now to sort out what is going on with the pano created by the images converted to tif via ASP.

Regards

Macr

[Mark McIntosh]

I don't know what happened to my other post, but I have now got a nodal system and as you can see from the preview image, it has stitched well, but alas it still produces crap when I create the pano.

My process was
Convert images to tif using ASP
Load images in Hugin
Align images (Said results were good)
Send batch to processor
run batch
create panorama

That is all I did. No other functions were played with.

Operating System: Linux 3.11.4-101.fc18.x86_64 x86_64
Architecture: 64 bit
Free memory: 4989736 kiB

Hugin
Version: 2012.0.0.a94faa15c927
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Path to user lensfun database: /home/macr/.local/share/lensfun

Libraries
wxWidgets: 2.8.12.0
libpano13: 2.9.18
Boost: 1.50.0
Exiv2: 0.23.0

Any help will be greatly appreciated, as this is driving me to do stupid things, like install windows and move to PTGUI.

TIA

Mark 'Macr' McIntosh

[Terry Duell]

Hello Mark,

On Mon, 04 Nov 2013 19:29:21 +1100, Mark McIntosh <mac...@gmail.com>
wrote:

[snip]

> Any help will be greatly appreciated, as this is driving me to do stupid
> things, like install windows and move to PTGUI.

can you make your test images available...Dropbox or somesuch?

Cheers,
--
Regards,
Terry Duell

[Mark McIntosh]

I could use dropbox, but I must admit that I do not know how to do it. If you could explain it, then I will try and send them to you.

Regards
Mark

[Mark McIntosh]

Actually, I can send them straight to you through Google drive, but it will take a while.

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/t3vV_UX6ysc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/0b5d82a0-b5d7-4de6-a713-de4711535359%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Terry Duell]

Hello Mark,

On Tue, 05 Nov 2013 05:27:21 +1100, Mark McIntosh <mac...@gmail.com>
wrote:

> Actually, I can send them straight to you through Google drive, but it
> will take a while.

How big are the images?

>
>
> On Tue, Nov 5, 2013 at 5:10 AM, Mark McIntosh <mac...@gmail.com> wrote:
>
>> I could use dropbox, but I must admit that I do not know how to do it.
>> If you could explain it, then I will try and send them to you.

To use Dropbox, I think you have to go to their website and register, and
install the dropbox software.
Then you can put a file in your dropbox public dir, get a link to it, and
provide the link to whomever you want to have access to the file.


Have you had any success stitching any other set of images with this
version of Hugin?
Which version of Enblend are you using?

I see you are using Fedora 18.
You could try updating to the a prerelease version of Hugin 2013,
available here...
<http://repos.fedorapeople.org/repos/bpostle/panorama/fedora-18/x86_64/>
and see if that helps.

[Mark McIntosh]

Tduell,

You should now have the images. They are around 70MB, which I don't think is excessive. I don't even think D800e tif images should be considered excessive. If this is a panorama stitching program it shouldn't it  be able to stitch whatever size tifs are thrown at it? If not, I guess that would be a great goal for the developers.

I am currently updating enblend and Hugin from the links you sent me. I will give that a try.

As for other images, it really has been on and off. So far it has taken many attempts to get images to stitch. I want to be able to stitched 300dpi, Adobe 1998 RGB, tif images, to send back to ASP, so I can edit the image. I feel this is a reasonable ask.

Thanks for any help you can give and I will report back with my experiments with 2013, if I get it installed.

[Mark McIntosh]

Try loading hugin-base-2013.0.0-0.1.20130924hg.fc18.x86_64.rpm
Get this error
hugin-2012.0.0-1.fc18.x86_64 requires hugin-base = 2012.0.0-1.fc18
Try loading hugin-base-2012.0.0-1.fc18.x86_64.rpm
Get this error
The package hugin-base-2012.0.0-1.fc18.x86_64 is already installed
Try loading hugin-2013.0.0-0.1.20130924hg.fc18.x86_64.rpm
Get this
hugin-2013.0.0-0.1.20130924hg.fc18.x86_64 requires hugin-base = 2013.0.0-0.1.20130924hg.fc18

What gives? Looks like I am in a vicious circle!

[Mark McIntosh]

Ok, I had to remove all traces of Hugin, then using CLI, I managed to get hugin-2013.0.0-0.1.20130924hg.fc18.x86_64.rpm and enblend-doc-4.1.1-1.fc18.x86_64.rpm to install. I must say that I do prefer the new interface. Currently running the images through the system again. I will report back with the results.

Macr

[Mark McIntosh]

Different version, same crap output.
This is ridiculous!

[Terry Duell]

Hello Mark,

On Tue, 05 Nov 2013 20:22:08 +1100, Mark McIntosh <mac...@gmail.com>
wrote:

> Ok, I had to remove all traces of Hugin, then using CLI, I managed to get
> hugin-2013.0.0-0.1.20130924hg.fc18.x86_64.rpm

Did you install hugin-base-2013.0.0-0.1.20130924hg.fc18.x86_64.rpm?

> and enblend-doc-4.1.1-1.fc18.x86_64.rpm to install.

I think you really want enblend, and 4.1.2 is the latest version.
It doesn't look like Bruno has 4.1.2 built for fc18.

> I must say that I do prefer
> the new interface. Currently running the images through the system
> again. I will report back with the results.

I think it would be useful to check exactly what versions of the bits and
pieces you are running.

Try..
rpm -q hugin
rpm -q hugin-base
rpm -q enblend

Also, start hugin and go to file > preferences > programs and see what is
your enblend executable,
and let's know the results.

[Terry Duell]

Hello Mark,
On Tue, 05 Nov 2013 22:02:40 +1100, Mark McIntosh <mac...@gmail.com>
wrote:

> Different version, same crap output.
> This is ridiculous!

Don't give up. There will be an answer to this, and probably a simple one.
Hugin is (usually) very nicely behaved.
I'll have a look at a couple of your images.

[Terry Duell]

Hello Mark,

On Wed, 06 Nov 2013 08:37:56 +1100, Terry Duell <tdu...@iinet.net.au>
wrote:

> Don't give up. There will be an answer to this, and probably a simple
> one.
> Hugin is (usually) very nicely behaved.
> I'll have a look at a couple of your images.

I tried stitching your 0007 and 0008.tif in hugin-2013.1.0 (development
source) and they stitched OK using your .pto, but the result, when
displayed in "Gimp" (I think Gimp actually opened the image up in UFRaw)
looks very similar to what you showed. "Shotwell" also displayed the
result very poorly.
The result does display OK in "image viewer" (fedora), and "Darktable".
Your input images are 16 bit, and you have output set for tif in your
.pto, which means output is also 16 bit. The viewers which show the stitch
poorly cannot, or do not, handle 16 bit correctly.
If you set your output to jpeg (in the stitcher tab), you will get an 8
bit result (if that is OK for your purposes), and every image viewer
should display it OK.

It looks to me as though hugin is doing it's job correctly.

[David Benes]

Hi,

I can also confirm, that Hugin 2013.0.0 on Windows stich images just fine.

But Gimp 2.8.4 on Windows open stitched image also in proper way, just alert windows about supporting only 8bit/color.

Regards

David

2013/11/6 Terry Duell <tdu...@iinet.net.au>

--
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 this group and stop receiving emails from it, send an email to hugin-ptx+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/op.w53rr5oars0ygh%40localhost.

[Bruno Postle]

On 6 November 2013 01:01, Terry Duell <tdu...@iinet.net.au> wrote:

I tried stitching your 0007 and 0008.tif in hugin-2013.1.0 (development source) and they stitched OK using your .pto, but the result, when displayed in "Gimp" (I think Gimp actually opened the image up in UFRaw) looks very similar to what you showed. "Shotwell" also displayed the result very poorly.

 

The result does display OK in "image viewer" (fedora), and "Darktable".
Your input images are 16 bit, and you have output set for tif in your .pto, which means output is also 16 bit. The viewers which show the stitch poorly cannot, or do not, handle 16 bit correctly.

This is an old Gimp/ufraw problem, 16bit TIFF files get passed to the ufraw plugin even though the standard Gimp TIFF plugin handles them properly.

A solution is disable 'automatic detection' when using Gimp File->Open; with Gimp 2.6 there is an option to 'Select File Type', scroll down and pick the TIFF handler.

(my solution was to switch to Darktable and/or Rawstudio)

--

Bruno

[Mark McIntosh]

David,
If you didn't already know, GIMP is still retarded, so 8 bit is norm. Sorry if I told you to suck eggs.

What I have just done is run the remove alpha channel as suggested by Stefan and that appears to work on this image. Maybe there is a code issue with alpha channels.
I will try to answer all questions tomorrow, but atm, I am going to download photos from tonight's shoot and see if I can get a result.

Thanks for everyone's interest and help on this. Hopefully we can sort it and fix the issue in the next build.

Macr out.

[T. Modes]

Am Mittwoch, 6. November 2013 02:01:07 UTC+1 schrieb Tduell:

I tried stitching your 0007 and 0008.tif in hugin-2013.1.0 (development  
source) and they stitched OK using your .pto, but the result, when  
displayed in "Gimp" (I think Gimp actually opened the image up in UFRaw)  
looks very similar to what you showed. "Shotwell" also displayed the  
result very poorly.
The result does display OK in "image viewer" (fedora), and "Darktable".
Your input images are 16 bit, and you have output set for tif in your  
.pto, which means output is also 16 bit. The viewers which show the stitch  
poorly cannot, or do not, handle 16 bit correctly.
If you set your output to jpeg (in the stitcher tab), you will get an 8  
bit result (if that is OK for your purposes), and every image viewer  
should display it OK.

this sounds for me like a problem with the icc profile in the file.
 

 

[Mark McIntosh]

As I said last night, I ran the remove alpha channel command line and can open the image in GIMP, without it going back to UFRAW, but for the life of me, ASP won't recognise the file. It says it is processing 138 images and when it finishes it then says 134 images (I made a couple of variants of the original for testing purposes). The only thing that I haven't done is to reboot the computer, but I will check this afternoon when I get home.

We are getting closer to an answer, but we are not quite there yet.

Macr

--

A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---

You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/t3vV_UX6ysc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/001866fc-5b03-42a6-91ef-070193d788de%40googlegroups.com.