How to run nona without any exposure change?

Asked by gzotti

Hello!

I have been using Hugin for years now, but cannot find the right command line switch for the trivial issue:
I have received a pano which is slightly curved, so I want to reproject it just with nona.
The pano is huge, over 48000 pixels wide, so I made an 8192x4096 version to work inside Hugin and find the correct geometric fit.
I have linked the pano image to a grid and optimized to find the 3 values yaw, pitch, rotation. No other corrections are required.

my .pto:
=================================
# hugin project file
#hugin_ptoversion 2
p f2 w6000 h3000 v360 E0 R0 n"PNG"
m g1 i0 f0 m2 p0.00784314
# BTW can anybody explain the p parameter in the m line?

# image lines
#-hugin cropFactor=1
i w8192 h4096 f4 v360 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er0 Eb0 r0.174130287671457 p0.38044865440883 y-0.154646062365405 TrX0 TrY0 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va0 Vb0 Vc0 Vd0 Vx0 Vy0 Vm5 n"curvedpano_8192.jpg"
#-hugin cropFactor=1
#i w8192 h4096 f4 v360 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er0 Eb0 r0 p0 y0 TrX0 TrY0 TrZ0 Tpy0 Tpp0 j0 a0 b0 c0 d0 e0 g0 t0 Va0 Vb0 Vc0 Vd0 Vx0 Vy0 Vm5 n"grid_8k.png"

# Point links and other lines deleted.
===============================================

The second "grid" image has been disabled after finding the r/p/y values. Also, following some online documentation for the pto file format, I deleted = marks. (Is there a difference or documentation on that?)
Now I tried running nona (additions like -p UINT8 and --ignore-exposure have been my later tries)
"c:\Program Files\Hugin_2018.0\bin\nona.exe" -v -p UINT8 --ignore-exposure straightened.pto -o straightened.png

Remapping and stitching
loading curvedpano_8192.jpg
remapping curvedpano_8192.jpg
blending curvedpano_8192.jpg
saving result straightened.png
Not recognizing known sRGB profile that has been edited

The image is a night sky image, so it's mostly dark, and the resulting image should likewise be mostly dark. I don't want any change in pixel RGB values, just a geometric distortion. Currently some auto-exposure returns a glaringly overexposed and burnt-out image. Whatever sRGB profile is in the file should not change exposure, right? Or how could I get rid of it or fix it? ImageMagick, exiftool, ... ?

As soon as that works, I want to replace the source image by the original, huge panorama. When I tried inside Hugin, I could use it in the preview, but trying to create the new pano crashed immediately. Is that only hugin GUI or is there a known size limit to command-line nona? Would running nona on Ubuntu help? (Windows10-Ubuntu comes with nona 2013.0.0, seems a bit old. I have an older PC with Ubuntu 18.04 but less resources.)

I have searched tens of online manpages and websites. Most docs are from 2007 or so, and further links to somewhere else lead to 404 land. Is there any available up-to-date self-contained documentation that explains every parameter in Hugin 2018.0? I know documenting may be boring, but is important. The p and m lines seem to have new parameters, but are not properly documented.

Kind regards,
Georg Zotti
Stellarium Team

Question information

Language:
English Edit question
Status:
Solved
For:
Hugin Edit question
Assignee:
No assignee Edit question
Solved by:
tmodes
Solved:
Last query:
Last reply:
Revision history for this message
tmodes (tmodes) said :
#1

>The p and m lines seem to have new parameters, but are not properly documented.
All recognized parameters are documented in doc/nona.txt

>Also, following some online documentation for the pto file format, I deleted = marks. (Is there a difference or documentation on that?)
That's a big difference. The = means take the value from image number after the = sign. Without the = the value is used as number. So this documentation is totally wrong.

>Remapping and stitching
>loading curvedpano_8192.jpg
>remapping curvedpano_8192.jpg
>blending curvedpano_8192.jpg
>saving result straightened.png
>Not recognizing known sRGB profile that has been edited

Is this the output of nona or added you the comment about the sRGB profile? A corrupt icc profile can explain some of the issues you observed. Normally a viewer should respect the icc profile for viewing.

Revision history for this message
gzotti (georg-zotti) said :
#2

Thanks a lot for clarifying the = issue!

doc/nona.txt and http://hugin.sourceforge.net/docs/nona/nona.txt explains only the m entries g and i. Is there another nona.txt?

It also refers to a "libpano13 Optimize.txt". If interested in the v lines, where would I find this?

The sRGB message seems to come from libPNG. But why would an image that looks fine and gets geometrically distorted by nona be converted to a totally overexposed nonsense, when any photometric business has been commanded off by giving Eev0 in the source (i) and E0 in the target (p) line, plus --ignore-exposure given to nona on the command line?

I will likely have to try harder to find a way to fix the ICC profile.

Revision history for this message
tmodes (tmodes) said :
#3

No, there is no other nona.txt. The other one were not read. They are remainings from older (test/development) versions.

Can yo provide a link to a small test image (and pto file) which shows the same issue?

Revision history for this message
gzotti (georg-zotti) said :
#4

Please try this example:
https://www.dropbox.com/s/f3kuv6vmacn0qzt/Nona_problem_brightness.zip?dl=0

There is not even a bad profile involved.

Revision history for this message
Best tmodes (tmodes) said :
#5

The overexposure is caused by wrong settings for white balance and vignetting correction: Change in the i line
Er1 Eb1 Va1
The value of 0 for these variables caused the overexposure. (Er and Eb can be set in the GUI, but Va can't be set to 1 in the GUI. So this seems to be done by your editing. You can also left these variables out of the list, then Hugin/nona is automatically using the default values.)

Revision history for this message
gzotti (georg-zotti) said :
#6

GREAT!

Thank you very much!

These may have been Va=0 etc when the file had 2 images, and maybe my editing away the = caused these troubles.

Revision history for this message
gzotti (georg-zotti) said :
#7

Thanks tmodes, that solved my question.

Revision history for this message
tmodes (tmodes) said :
#8

> These may have been Va=0 etc when the file had 2 images, and maybe my editing away the = caused these troubles.

That's the cause I recommend not to edit the pto directly. Instead use the command line tools to manipulate the pto file. This avoids such traps.

Revision history for this message
gzotti (georg-zotti) said :
#9

Hmm, unfortunately my 48k pano still does not work. Resulting file is empty, without warning (the processing lines remain as usual). Creating a 16k version works. Maybe a PNG size limitation?

Ha - it seems to work with TIFF :-) - I can live with that, and convert to PNG with convert.