What's wrong Hugin tiff implementation?

[AlekseyM]

When I try to use 16-bit tiff, created by DPP, Hugin says there are
some errors. However it opens them correctly. On the other hand, when
I try to open the resulting tiff (which I assume to be 16-bit, same as
input) with Capture NX 2, the latter does not recognize it as image at
all. Some other standard Windows programs open them OK though.

[Erik Krause]

DPP includes a small 8 bit preview image. Hence some programs (like f.e.
enblend) treat those TIFFs as multi layer images and produce an error
since the bit depth for both "layers" is not the same.

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

[AlekseyM]

Thanks, that's interesting. But more important to me is the second
question - why tiff, produced by Hugin, can not be opened in Capture
NX 2? It seems to be a 16 bit tiff and some other programs can use it.

My goal is to be able to produce the panorama from unedited 16bit tiff
files and then adjust the complete picture.

Thanks,
Aleksey

[Stefan Peter]

On 25.04.2012 14:20, AlekseyM wrote:
> Thanks, that's interesting. But more important to me is the second
> question - why tiff, produced by Hugin, can not be opened in Capture
> NX 2? It seems to be a 16 bit tiff and some other programs can use it.

What size did your test image have? Could it be that NX2 has a maximum
image size restriction that does not allow you to open complete
equirects? I know for sure that BibblePro is limited in this regard.


Regards

Stefan Peter

--
In theory there is no difference between theory and practice. In
practice there is.

[AlekseyM]

I realized that Hugin creates a 64-bit tiff, while the input files are
48 bits. Captue NX2 only understands 48 bits. I looked into enblend
options and it appears that I can specify the --depth option, but the
documentation says it only available for some builds. In my case it
ignores the parameter. Maybe someone could help me pointing to the
place where to get one with working --depth option?

[Bruno Postle]

On Thu 26-Apr-2012 at 12:11 -0700, AlekseyM wrote:
>I realized that Hugin creates a 64-bit tiff, while the input files are
>48 bits. Captue NX2 only understands 48 bits.

These would still be 16bit per channel, a 'normal' RGB image would
have 16+16+16 = 48bits, whereas RGBA output from enblend has
16+16+16+16 = 64bits.

You could try removing the alpha channel with ImageMagick or
similar. Something like this, but don't be surprised if I have this
wrong:

mogrify -background black -flatten +matte project.tif

--
Bruno

[AlekseyM]

Right! So the Capture NX 2 does not support any RGBA tiffs and the
enblend --depth option actually works. Strange that there is no option
to remove this channel. On the other hand, is it a serious
disadvantage of Capture NX 2.

[AlekseyM]

What library Hugin uses to create tiff files? Maybe it is possible to
add some options to specify different tiff format?

[Bruno Postle]

On Tue 01-May-2012 at 03:35 -0700, AlekseyM wrote:
>What library Hugin uses to create tiff files? Maybe it is possible to
>add some options to specify different tiff format?

It would be possible, but the alpha channel in the enblend TIFF
output is useful since a lot of panoramas have transparent areas.

--
Bruno

[Isaac Gouy]

On Tuesday, May 1, 2012 12:16:20 PM UTC-7, Bruno Postle wrote:

It would be possible, but the alpha channel in the enblend TIFF
output is useful since a lot of panoramas have transparent areas.

I've encountered a similar problem with DxO Optics Pro 8, which will produce 48bit TIFF as output that is accepted by Enfuse or Hugin, but will not accept the TIFF produced by Enfuse or Hugin as valid input.

The response from DxO is that the Enfuse and Hugin files don't comply with TIFF standard.

[Carlos Eduardo G. Carvalho (Cartola)]

2013/6/11 Isaac Gouy <igo...@yahoo.com>

I've encountered a similar problem with DxO Optics Pro 8, which will produce 48bit TIFF as output that is accepted by Enfuse or Hugin, but will not accept the TIFF produced by Enfuse or Hugin as valid input.

The response from DxO is that the Enfuse and Hugin files don't comply with TIFF standard.

Funny, I am having problems sometimes with the jpg generated by enblend at the end of the stitching process. It opens ok in GIMP and can be converted ok with imagemagick, but some viewers, like xzgv and the xfce default viewer don't open them. In those cases I just convert them with imagemagick and it gets ok.

Carlos E G Carvalho (Cartola)
http://cartola.org/360
http://www.panoforum.com.br/

[Bruno Postle]

On Jun 11, 2013 12:27 PM, "Carlos Eduardo G. Carvalho (Cartola)" wrote:
>
> Funny, I am having problems sometimes with the jpg generated by enblend at the end of the stitching process. It opens ok in GIMP and can be converted ok with imagemagick, but some viewers, like xzgv and the xfce default viewer don't open them. In those cases I just convert them with imagemagick and it gets ok.

This is the libjpeg-turbo arithmetic coding bug, you need to get your distribution to apply a patch for older enblend when used with this new jpeg library. There is an enblend bug report in launchpad you can use as reference.

--
Bruno

[Bruno Postle]

It would be nice to know the exact nature of the problem, hugin/enblend use vigra and this uses libtiff which is the reference tiff implementation.

--
Bruno

[Isaac Gouy]

On Tuesday, June 11, 2013 5:15:30 AM UTC-7, Bruno Postle wrote:

> I've encountered a similar problem with DxO Optics Pro 8, which will produce 48bit TIFF as output that is accepted by Enfuse or Hugin, but will not accept the TIFF produced by Enfuse or Hugin as valid input.
>
> The response from DxO is that the Enfuse and Hugin files don't comply with TIFF standard.

It would be nice to know the exact nature of the problem, hugin/enblend use vigra and this uses libtiff which is the reference tiff implementation.

I'll let you know if I manage to isolate the problem.

I can tell you that although ACDSee Pro 6 versin 6.2 (Build 212) does allow the same files to be viewed at 100%, any attempt to edit or export creates a trashed image.

The problem is not image size - the same thing happens with a 529x796 3MB image.

[Isaac Gouy]

On Tuesday, May 1, 2012 12:16:20 PM UTC-7, Bruno Postle wrote:

While I agree that it's useful to support alpha channel (and I've used that masking capability with Enfuse), It seems that image processing software intended for photographers tends not support alpha channel TIFF even when it does support 48bit TIFF.

Image processing software intended for a broader audience, intended for illustrators, is more likely to support alpha channel TIFF.

For example, the free to use,  Serif Photo Plus Starter Edition, opened all the problem TIFFs and allowed them to be exported as 24bit or 32bit TIFF.

DxO Optics Pro wouldn't open the converted 32bit TIFF but did open the converted 24bit TIFF.


Unfortunately it seems very unlikely that the makers of software for photographers will be persuaded to support alpha channel TIFF.

I understand that the conversion is possible with ImageMagick but as-well-as my reluctance to install all that stuff on my Windows install, even Ubuntu now shows a warning that ImageMagick cannot be authenticated (whatever that means).

Perhaps the better approach would be yet-another-utility-program, based on libtiff, which strips the alpha channel and could be used after Enblend or Enfuse?

[Greg 'groggy' Lehey]

Based on my experience with DxO "support", this is an unfounded
claim. It seems that the software makes assumptions that have nothing
to do with the standards, and when it fails, they blame the creator of
the file. I had a similar problem with raw input files where I had
added an Author: to the EXIF data. The EXIF processing routines
failed, and it was apparently my fault. But it would certainly be
interesting to see if they can back up their claims.

Greg
--
Sent from my desktop computer.
Finger gr...@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua

[Gnome Nomad]

Hmmm, Rawtherapee opens Hugin TIFFs with no problems or complaints. GIMP
only complains about them being 16-bit per channel. Haven't tried
opening one in Bibble 5/Aftershot Pro, but that is software intended for
photographers.

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

[Frederic Da Vitoria]

2013/6/12 Gnome Nomad <gnome...@gmail.com>

Gimp 2.8.4 on Windows does not complain at all, as far as I can see.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

[Gnome Nomad]

On 06/11/2013 10:02 PM, Frederic Da Vitoria wrote:
> 2013/6/12 Gnome Nomad <gnome...@gmail.com <mailto:gnome...@gmail.com>>

Same version I have here, although I run it on Linux, not Windows.

Does it tell you that the input file has 16-bits per channel, GIMP only
supports 8-bits per channel, so it is dropping the other 8 bits per
channel? That's the GIMP "complaint" I'm referring to. GIMP doesn't
support 48-bit (3 16-bit channels). That's scheduled for GIMP 3.

[Frederic Da Vitoria]

2013/6/12 Gnome Nomad <gnome...@gmail.com>

I know that currently GIMP is still limited to 8 bits / channel. I only meant that GIMP does not complain about the bit depth when loading a 48-bits image. Actually, I have looked everywhere for a mention of the bit depth in Gimp but have been unable to find any. Gimp is very quiet about this :-)

[Isaac Gouy]

On Wednesday, June 12, 2013 12:58:18 AM UTC-7, GnomeNomad wrote:

GIMP only complains about them being 16-bit per channel.

I think GIMP (like Photoshop) is intended for a broader audience than just photographers.

("Full suite of painting tools including Brush, Pencil, Airbrush, Clone, etc.")

[Frederic Da Vitoria]

2013/6/12 Isaac Gouy <igo...@yahoo.com>

This may be part of the reason why Gimp has still this limitation. But I think the broader audience does not forbid high bit depth, it only means that a smaller proportion of users feels the need for it. Sure, high bit depth makes calculations slower and means images will use more space in memory, but the drawbacks of low bit depths are often visible even to occasional users. Even on JPEG images, 48 bits calculations should bring sometimes better results.

[Gnome Nomad]

On 06/11/2013 11:08 PM, Frederic Da Vitoria wrote:
> 2013/6/12 Gnome Nomad <gnome...@gmail.com
>
> On 06/11/2013 10:02 PM, Frederic Da Vitoria wrote:
>
> 2013/6/12 Gnome Nomad
>

GIMP has stated that GIMP 3 will have full 48-bit color support,
including for all effects, filters, etc.

Photoshop has had 48-bit support for a long time now, since 48-bit color
is the professional photography standard.

The problem with transparency and digital photographs has been around a
long time. When JPG standard was defined, it didn't include
transparency. I think it's because the joint "photographic experts" take
"transparency" to mean a type of film image, not an attribute of a
photograph. ;-)

Does anyone know why we receive what look like TWO slightly different
list sigs like this at the bottom? Maybe someone could combine the two
and reduce the extraneous line count a bit?

> You received this message because you are subscribed to the Google
> Groups "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
>
> ---
> 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+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Bruno Postle]

On Wed 12-Jun-2013 at 09:23 -1000, Gnome Nomad wrote:

> Does anyone know why we receive what look like TWO slightly different
> list sigs like this at the bottom? Maybe someone could combine the
> two and reduce the extraneous line count a bit?

Google seem to have grown it over the years. I've just tried
trimming it, though it's still quite long:

[Bruno Postle]

Tried again:

[Gnome Nomad]

No more line containing the list address to post to? But it's a whole
lot shorter!

[Isaac Gouy]

On Thursday, April 26, 2012 12:30:04 PM UTC-7, Bruno Postle wrote:

You could try removing the alpha channel with ImageMagick or
similar.

Any suggestions for a small standalone program that will remove the alpha channel to give 24bit and 48bit TIFF?