Hi Macr

On 16.10.2013 10:12, [email protected] wrote:
> 
> On Wednesday, October 16, 2013 7:57:48 AM UTC+11, Stefan Peter wrote:
>     Hi Macr
> 
>     On 15.10.2013 22:07, [email protected] <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


-- 
"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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to