batch panorama with same params

[M Verberne]

Hi all,

I create interval images and made a project with 2 cams on a fixed position.

as a result i have 2 series of images, one in a folder [left] the other in a folder [right]

images in both folders are named: IMG_0001.jpg, IMG_0002.jpg etc.
overlap is only 150px.

as a result i created a few control points by hand and after alingning and adjusting the cutout i have one panorama image.

since lighting, leaves and other things change not all control points will be available on all images.

Is there a way  can batch process all images in those 2 folders with the same set of corrections that hugin used for the first one i corrected by hand?

if not, is it possible to use the same control point for all other images in the folders?
or am i thinking all wrong about this?

all help is really appreciated :)

Maarten

[Bruno Postle]

Hi Maarten, you can use an existing Hugin PTO project as a template to
stitch further panoramas that have the same arrangement of photos.

On the command-line or in a script you can specify replacement input images:

nona -o temp_ project.pto left/IMG_0001.jpg right/IMG_0001.jpg

..this will create two temporary remapped images, called temp_0000.tif
and temp_0001.tif, use enblend to blend them into a single image:

enblend -o panorama_0001.jpg temp_0000.tif temp_0001.tif

--
Bruno

[M Verberne]

i do not understand where i can enter those command, i did not see a teminal field in the gui and windows command prompt says it does not know nona.

however, Bruno did help me out with some tips that gave me an idea for a solution with creating a new template via apply template without the control points.

i was hoping to end up with an example windows script that i could recycle for my purpose.

but my current solution is using that pto file as a text document and filling in all imag numbers, rename the output from txt to pto, open it with the gui batch processor and run.

it might not be as efficient as i was hoping for,
so if you know of a more elegant solution and want to share that, i'm interested :)
Maarten.

Op maandag 4 juli 2022 om 11:26:39 UTC+2 schreef bruno...@gmail.com:

[Maarten Verberne]

Hi,
i'm just making my first steps and made 2 landscape panorama's from sets
of 2 cam jpgs, one as tiff one as jpg.

and i must say, the tiff has more contrast and looks a bit sharper, but
it is 15x the file size and since i want to use it for batches it is a
bit too much.
so then i thought maybe i can get a bit more out of the jpg by using
high dynamic range.

but unfortunately all but
exposure corrected, low dynamic range
is alvailable.

if i mark it at the stitcher tab under combined stacks it is again
undone when i go to the preview and use create panorama.

is it that the jpg are not hdr to start with or am i missing a setting?

[johnfi...@gmail.com]

On Monday, July 4, 2022 at 2:51:54 PM UTC-4 mpgve...@gmail.com wrote:

> i do not understand where i can enter those command, i did not see a teminal field in the gui and windows command prompt says it does not know nona.

You use some form of windows command prompt and you do something to fix the PATH to include the directory where nona.exe etc. are installed.

There are various ways to create an icon and/or a right click menu choice that will open all that easily from then on (vs typing the command to change the PATH  each time you start a cmd prompt to work on this).

You could also use control panel to permanently change PATH so Hugin related exe's are always on your path.  I use my computer for too many different things and hate PATH pollution, so I wouldn't do that myself.  But if using Hugin is a significant fraction of the purpose of the whole computer, then including it in the permanent PATH is the simpler choice.

There are multiple (better) alternatives to the basic cmd prompt and multiple ways to set up each to have a customized launch for specific purpose.  So too many choices: which usually means just do it some simple obvious way while knowing that if it is worth trouble to make it better, you can.

On Monday, August 1, 2022 at 1:06:37 PM UTC-4 mpgve...@gmail.com wrote:

and i must say, the tiff has more contrast and looks a bit sharper, but

That is a sub-topic I'd really like to understand, since I'm fighting many situations in which the tiff is very fuzzy compared to jpg.

I have seen about as many situations in which the colors look better when viewing a tiff vs. jpg as the opposite.  Each viewer has its own rules for the non linear translation from 16 bit intensities to 8 bit intensity for display on your monitor.  They don't seem to be just throwing away the low bits.   Depending on the photo and the viewer, that mapping can make the picture look much better, including increasing the contrast between two colors that are adjacent and look better with more contrast.  A big advantage of working in 16 bits is the ability to adjust the final mapping to 8 bit AFTER stitching.  Maybe that is all you mean by "more contrast" and "sharper".

It might also be possible that the jpg compression is actually blurring edges etc compared to raw.  But that is opposite to my own experience (thus a subject I'd like to be told more about).

it is 15x the file size and since i want to use it for batches it is a
bit too much.

Disk space is cheap.  So while I have some similar objections myself to keeping around lots of tiff files, I think my own use pattern is odd and most other people should not care about that waste of disk space.  Am I missing something?  Maybe that is another subtopic I'd appreciate having explained.

so then i thought maybe i can get a bit more out of the jpg by using
high dynamic range.

but unfortunately all but
exposure corrected, low dynamic range
is alvailable.

I hope one of the experts explains some of that here.

I have never had any decent mental model (despite rereading Hugin documentation many times) of what high vs. low dynamic range actually means as a concept in Hugin's processing.  Of course, I understand what it in photography,  but that doesn't tell me what selecting it in Hugin actually causes Hugin to do differently.

[David W. Jones]

JPG isn't HDR to start with. It uses 8-bits per color channel (red, green, blue). So you can't get HDR out of a JPG. You need to start with an HDR image, typically your camera's raw image format.

TIFF can use lossless compression (LZW is common) but not necessarily by default. LZW typically halves the file size vs uncompressed TIFF.


--
David W. Jones
gnome...@gmail.com
exploring the landscape of god
http://dancingtreefrog.com

Sent from my Android device with F/LOSS K-9 Mail.

[Maarten Verberne]

thanks, John, David,
the first problem from an older post is solved by using my office
program to create the files i need.....works for me.

tiff vs JPG, fair enough, it could be this specific example, so i'll
make some more and also test them in a different program.

as for disk space, well it's not that i don't have enough of it...but
still for me to archive 15x is definately pushing it.

Alas for that same reason i do not like to shoot in raw.
And i did use LZW, so you are writing i'm lucky that it was only 15x the
JPG size :)

I'll accept the default jpg settings.

Maarten

[David W. Jones]

Hi, Maerten!

I shoot RAW files with my Sony A58. I process those into 16-bit/channel
TIFF files. I use the TIFF files in Hugin to make my panorama and have
Hugin output it as 16-bit/channel TIFF. Then I pull that into Luminance
HDR to produce my final JPG image. Luminance HDR does tone mapping from
16-bit to 8-bit JPG. I save my final JPG at 100% quality.

When it's all done, I keep the original RAW files, the PTO file,
Rawtherapee's settings file for each image, and the Luminance HDR
settings file. I put them all into a single folder, then use 7zip to
compress them into an archive file. The archive file goes onto my file
server, then eventually migrates to external or optical storage.

One difference between JPG and other image file formats is JPG has a
quality setting. The lower the quality setting, the smaller the
compressed file. How a particular quality setting may affect a
particular image is dependent on that image.

Ever seen an image with sharp-edge text on it, compressed it using JPG
at less-than 100% quality, and viewed the edges of the text? JPG
compression produces artifacts in such situations. Similar things can
happen when an image with blown highlights gets mapped to 8-bit,
producing an area of solid white surrounded by areas that aren't as
bright. The edge of areas can develop artifacts.

Default JPG quality depends on the program making the JPG. Some default
to 90% quality, some to 80%. Some hide image quality behind selections
like "For Web", "For Print" or "For Email".

I have panoramas that were about 2GB as 16-bit TIFFs that became about
600-700MB as 100% quality JPGs. So what quality setting are your JPGs at
to give you a 15x difference?

--
David W. Jones
gnome...@gmail.com

wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.

[johnfi...@gmail.com]

On Monday, August 1, 2022 at 5:44:47 PM UTC-4 GnomeNomad wrote:

I have panoramas that were about 2GB as 16-bit TIFFs that became about
600-700MB as 100% quality JPGs. So what quality setting are your JPGs at
to give you a 15x difference?

My results are somewhere between those.  I guess 100% quality JPGs cost a lot of space.

I don't know what the Sony alpha 7 III's "extra fine" quality for JPG means (in more portable terminology).  My 4Kx6K photos are 17.5 to 18.8 Mb as JPGs produced by the camera and are always 145,449,341 bytes as tif files produced by conversion programs from the arw.  So that is about an 8 to 1 difference.  The tif file holds a 144,000,000 byte image plus various metadata.  The jpg represents half that much data, apparently getting 4 to 1 compression without any visible loss of quality.

I rarely have blown highlights.  I avoid shooting that way because I assume it would be harder to fix.  So the problems are at the opposite end.  Some sections are too dark and I typically hope to mask and selectively brighten after stitching.  The jpg version is always slightly lacking in content in the dark areas, so I would need a separate shot with intentionally blown highlights if I were working just with jpg (and then my expertise as a hugin user is lacking for the problem).  Working from raw, the dark areas areas are sometimes far better than in the jpg copy and no second shot would be needed.  But when I'm not using a tripod (so getting a decent second shot is harder) tends to be when the raw is too noisy in dark areas and thus worse than the jpg.

 

[David W. Jones]

Hmm, bringing up detail in underexposed areas while dealing better with
noise seems to me to be one of the strong points of shooting and
processing from raw format.

My A58's 20-megapixel RAW files run 19.7-19.8 MB in size from the
camera. I convert them to uncompressed 114MB TIFFs. There's no loss of
image quality, etc. I can address issues like shadows being too dark,
etc, in the original image when converting from raw to the TIFF. I can
also adjust noise much more specifically - like I said, a noise setting
that works on one image might not be enough on another, or might be too
much.

Using TIFF also gives Hugin more information when it comes to
calculating photometrics. (That might also help with handling dark areas.

Anyway, I guess I don't worry about disk space as much. My laptop has a
2TB SSD in it, with 744GB of free space, and I have 6 or 8 TB of storage
in the file server. Plus a collection of external drives that add
another 2TB of storage.

We'll see if I feel the same way the day after I finally get to replace
the A58 with an A7R IVA. :)