hugin_executor.exe ignores the compression parameter

87 views
Skip to first unread message

Bernd D

unread,
Nov 2, 2016, 9:35:03 AM11/2/16
to hugin and other free panoramic software
Hi,
I want that hugin_executor.exe produce an uncompressed TIFF image. But this program ignores the given parameters and make a LZW compressed output. Is this a known issue or do I have to set the parameters differently?

c:\Program Files\Hugin\bin\hugin_executor.exe --stitching --prefix=T03 d:\Daten\Stage\T03\gautoptim2.pto

============================================

Stitching panorama...

============================================

 

Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition

Version: 2016.2.0.be8da0221960 built by Thomas

Working directory: d:\Daten\Stage\T03

Output prefix: T03

 

Blender: enblend 4.2

ExifTool version: 10.20

 

Number of active images: 9

Output exposure value: 0.0

Canvas size: 1964x1963

ROI: (1, 0) - (1964, 1963)

FOV: 0x0

Projection: Rectilinear(0)

Using GPU for remapping: false

 

Panorama Outputs:

* Exposure corrected, low dynamic range

 

First input image

Number: 0

Filename: d:\Daten\Stage\T03\T03-001-001.tif

Size: 1000x1000

Projection: Normal (rectilinear)

Response type: custom (EMoR)

HFOV: 0

Exposure value: 0.0
...

 

 

The relevant lines in autoptim2.pto:

# hugin project file
#hugin_ptoversion 2
p f0 w1964 h1963 v0
.1964 E0 R0 S1,1964,0,1963 n"TIFF c:NONE r:CROP"
m g1 i0 f0 m2 p0
.00784314
# image lines
#-hugin  cropFactor=1
i w1000 h1000 f0 v0
.1 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX0.000828696623649729 TrY0.00084058338918635 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 n"T03-001-001.tif"
#-hugin  cropFactor=1
i w1000 h1000 f0 v0
.1 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX-4.83874559421933e-06 TrY0.000837865641352501 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 n"T03-001-002.tif"
#-hugin  cropFactor=1
i w1000 h1000 f0 v0
.1 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX-0.000839531138142659 TrY0.000835625804640078 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 n"T03-001-003.tif"
#-hugin  cropFactor=1
i w1000 h1000 f0 v0
.1 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX0.000835086218058352 TrY2.00426893447669e-06 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 n"T03-002-001.tif"
#-hugin  cropFactor=1
i w1000 h1000 f0 v0
.1 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX0 TrY0 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 n"T03-002-002.tif"
#-hugin  cropFactor=1
i w1000 h1000 f0 v0
.1 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX-0.000833864094425705 TrY-2.32464077037218e-06 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 n"T03-002-003.tif"
#-hugin  cropFactor=1
i w1000 h1000 f0 v0
.1 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX0.000840858719618807 TrY-0.00083607953624036 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 n"T03-003-001.tif"
#-hugin  cropFactor=1
i w1000 h1000 f0 v0
.1 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX5.2532996703037e-06 TrY-0.000838301163175256 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 n"T03-003-002.tif"
#-hugin  cropFactor=1
i w1000 h1000 f0 v0
.1 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0 p0 y0 TrX-0.000827650797361962 TrY-0.000840492112200727 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 n"T03-003-003.tif"
#hugin_optimizeReferenceImage 4
#hugin_blender enblend
#hugin_remapper nona
#hugin_enblendOptions
#hugin_enfuseOptions
#hugin_hdrmergeOptions
#hugin_verdandiOptions
#hugin_outputLDRBlended true
#hugin_outputLDRLayers false
#hugin_outputLDRExposureRemapped false
#hugin_outputLDRExposureLayers false
#hugin_outputLDRExposureBlended false
#hugin_outputLDRStacks false
#hugin_outputLDRExposureLayersFused false
#hugin_outputHDRBlended false
#hugin_outputHDRLayers false
#hugin_outputHDRStacks false
#hugin_outputLayersCompression NONE
#hugin_outputImageType tif
#hugin_outputImageTypeCompression NONE
#hugin_outputJPEGQuality 100
#hugin_outputImageTypeHDR exr
#hugin_outputImageTypeHDRCompression NONE
#hugin_outputStacksMinOverlap 0.7
#hugin_outputLayersExposureDiff 0.5
#hugin_optimizerMasterSwitch 0
#hugin_optimizerPhotoMasterSwitch 0


Bernd D

unread,
Nov 3, 2016, 12:04:19 PM11/3/16
to hugin and other free panoramic software
Hi,
I found out, that the newest enblend.exe version 4.2 ignores the --compression=none parameter. The previous version 4.1.5 works correct.

Thanks

  Bernd

Gnome Nomad

unread,
Nov 3, 2016, 2:11:24 PM11/3/16
to hugin and other free panoramic software

Hmm, TIFF uses lossless compression. So why are you wanting to use no compression?


--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/62a7d9d6-0dcd-4704-9a18-93e9ced0ab13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Frederic Da Vitoria

unread,
Nov 3, 2016, 3:45:49 PM11/3/16
to hugin-ptx
2016-11-03 19:11 GMT+01:00 Gnome Nomad <gnome...@gmail.com>:

Hmm, TIFF uses lossless compression. So why are you wanting to use no compression?


AFAIK, TIFF can use no compression, lossless compression and lossy compression.

--
Frederic Da Vitoria
(davitof)

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

Gnome Nomad

unread,
Nov 3, 2016, 3:49:59 PM11/3/16
to hugin-ptx

True, it can use no compression or lossy; one of the benefits of TIFF IMHO. Only reason I can think of for using no-compression TIFF is when some other tool in the chain can't handle compressed TIFF. So wondered why OP needed no compression specifically.


--
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+...@googlegroups.com.

Stefan Peter

unread,
Nov 3, 2016, 6:15:22 PM11/3/16
to hugi...@googlegroups.com
On 03.11.2016 19:11, Gnome Nomad wrote:
> Hmm, TIFF uses lossless compression. So why are you wanting to use no
> compression?

This should not be the question. If an option is presented, this option
should be usable.

So, either enblend _can_ and _will_ do uncompressed tif output in this
case, or it should bail out with an error message indicating the reason
why this option is invalid in the current situation.

But just doing something different then the user has requested
definitely is not ok.

Can we have a closer look at this issue? I definitely will do so for the
Ubuntu packages I maintain in the next couple of days.


With kind regards

Stefan Peter



--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
(See https://en.wikipedia.org/wiki/Posting_style for details)

Gnome Nomad

unread,
Nov 3, 2016, 6:55:29 PM11/3/16
to hugi...@googlegroups.com
Oh, I agree that enblend 4.2 should support compression=none since 4.1 supported it. Sounds like a regression in enblend. Is there a bug report on it?

--
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+...@googlegroups.com.

Terry Duell

unread,
Nov 3, 2016, 7:16:17 PM11/3/16
to hugi...@googlegroups.com
On Fri, 04 Nov 2016 09:55:15 +1100, Gnome Nomad <gnome...@gmail.com>
wrote:

> Oh, I agree that enblend 4.2 should support compression=none since 4.1
> supported it. Sounds like a regression in enblend. Is there a bug report
> on
> it?
>
> On Thu, Nov 3, 2016, 12:15 Stefan Peter <s_p...@swissonline.ch> wrote:
>
> On 03.11.2016 19:11, Gnome Nomad wrote:
>> Hmm, TIFF uses lossless compression. So why are you wanting to use no
>> compression?
>
> This should not be the question. If an option is presented, this option
> should be usable.
>
> So, either enblend _can_ and _will_ do uncompressed tif output in this
> case, or it should bail out with an error message indicating the reason
> why this option is invalid in the current situation.
>
> But just doing something different then the user has requested
> definitely is not ok.
>
> Can we have a closer look at this issue? I definitely will do so for the
> Ubuntu packages I maintain in the next couple of days.
>

I see Thomas has made a fix a few hours ago...

Changeset: 1488 (882d3ccba621) Fixes handling of uncompressed output file …

this might have fixed the problem, not sure, I haven't tested.

Cheers,
--
Regards,
Terry Duell

Bernd D

unread,
Nov 4, 2016, 4:44:14 AM11/4/16
to hugin and other free panoramic software
The issue has broken my toolchain. That's the only reason I noticed it.

I am a software developer, so I know that user feedback is important.
Thanks a lot, especially to Thomas, for the quick reaction. I'm excited!

Rogier Wolff

unread,
Nov 4, 2016, 6:27:03 AM11/4/16
to hugi...@googlegroups.com

On 03.11.2016 19:11, Gnome Nomad wrote:
> Hmm, TIFF uses lossless compression. So why are you wanting to use no
> compression?

Depending on the computer and workload, compression and less-IO can be
faster or slower than no compression and more IO.

(on modern computers, the consensus seems to be that the CPU is so
much faster than IO that decompression with less IO is faster. However
if you have hardware doing the DMA to get things off disk and the CPU
is already pegged at 100%, the uncompressed scenario will win.
Similarly, compression may be slower than decompression, and for stuff
that needs to be stored once and read back only once or twice (like
for example temporary files in a "worflow"), the compression may slow
things down to be not useful overall.....)


Roger.

--
+-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 --
- Datarecovery Services Nederland B.V. Delft. KVK: 30160549 -
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!
Reply all
Reply to author
Forward
0 new messages