Image-stitching and virtual tour solutions My account Updates
It is currently Thu Oct 30, 2014 2:49 pm

All times are UTC + 1 hour




Post new topic Reply to topic  [ 36 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Color correction modes
PostPosted: Mon Feb 20, 2006 7:50 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
I need to ask autors of autopano to help me to understand color correction modes and stiching.

As I understand (I ignore possibility to use 'levels' tool):

A. No color correction
Autopano uses original colors from all images. To stich images, autopano finds 'borders' between images somewhere in overlapped areas of images, clip images to this borders (adding small additiobal space to blend images on borders), put clipped images to target and blend images in small zone near borders to make result smooth. The rest of overlapping areas outside of blending zone is ignored.

All operations made in floating numbers, but conversion to fliat is very simple - just convertion original 0..255 integer values to float format.

B. standart color correction
blending similar to 'no color correction', but diffirent method to handle colors. Color of 'anchor' images convertet to float similar to 'no color correction' - just convert of format. Other images need color mapping - brightness values is changed using difference between current and anchor (or, may be, previously converted neighbours?) images (if 'transfer' function used) and color balance is changed using something, that I can't understand. Back converion (to RGB/8 bits) is made reversing to conversion of achors.

2 questions:
1. What will be in extra brigtness information during conversion to RGB/8 bits? It is stripped?
2. How colors converted when 2 or more anchors used?

C. HDRI mode
In result of my expirements I found, then anchors is not used. It is correct? Brightness of source images is mapped to real using only explosure information from EXIF.
Images stiched by using another way, then in previous modes: all overlapped images information used to find better color of each pixels.
Question: is difference between float colors in 'no correction/standard' and HDRI? I thing, that extra brightness information in non-HDRI modes stripped when converting to float, and can not be used during operations (as example, in levels tool), but in HDRI mode - no.

I think, this text contains many mistakes, but it wrote is only to offer to describe color correction, as start :)

more questions:

why converting to HDRI decreases color space? Both in HDRI mode and when saving to HDR-file in another modes? I can not find way to map HDR-file (from standrd corection project) to RGB/24 bits to something, similar to RGB/24 bits, produced by autopano from this project.

I try to compare 8- and 16- bits PSD, made from stadard corerction project with high DR source (part of source images taken in dark shadows, part -on the sun, using auto explosure without AE lock), and did not find difference in color details. Why?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 20, 2006 8:31 pm 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
To clarify this explaination, let's separate the way picture are blended with the way pictures are color corrected. The blending is the fact of creating one picture using two pictures one on the top of another (like layer in photoshop). So as blending has nothing to do with color correction, let's ignore it. To illustrate this, go to option of the editor and put the "no blend" as default blender for the preview, you'll see what I'm talking about.

A. No color correction
APP use original colors. That's it. No correction. Smoothing between pictures comes from blending mode only. The fact that pixels are float doesn't really need here.

B. Standard color correction :
APP change pixels color according to anchor type per picture. You can have one or more hard anchor (in yellow) which says that this picture should not be affected by color equalization algorithm. This mode is to use when you don't have too much change in exposure (up to 2 or 3 IL).
You can use more than one hard anchors : APP will find a way to equalize the color correction between these constraints.

Note about float : The full process is done in float. After the first read of the input picture (jpeg, tiff, raw, etc), it is stored in float in memory and all calculation are done in float. Every format is used at maximum dynamic range possible (for example, raws gives at least 16bits). The level tools even if it shows a well known photoshop design, is in fact a float level (it's not only 0 to 255 values there). After every operations, stitching, projection, color correction, filter, level, there might be at the end of the process a reduction to 8bits or 16bits following the format you want as output. But during the full workflow, the maximum dynamic range is used.

C. HDRI mode :
You have big gaps in exposure, more than 2, 3-IL. It works the same way as "Standard Mode". Anchors do influence the results. EXIF is absolutely needed. In this mode, what is displayed on the preview can be really overburned. You have to use HDR level to set a window of display to show the true value of the HDR. Your screen has a 8bits dynamic range, but when using HDRI in APP you can easily achieve a 1,000,000 dynamic range (even from 3, 4 8bits files !). So, your screen need some help to be able to display such pictures. That's why tone mapper has to be used to solve this case, to transform a picture with values from 0 to 1,000,000 to a picture with value from 0 to 255 (High Dynamic Range Image to a Low Dynamic Range Image, HDRI to LDRI).

Look at the HDR tutorial here : http://wiki.autopano.net/en/tutorials/hdr-stitching
---
Quote:
I can not find way to map HDR-file (from standard correction project) to RGB/24 bits to something, similar to RGB/24 bits, produced by autopano from this project

You need a tone mapper or a software that does that. Photoshop CS2 can do that. Open the HDR file, you'll see that photoshop is working in 32bits mode, and just try to convert it to 8 or 16bits, it will call the tone mapper.

Quote:
I try to compare 8- and 16- bits PSD, made from standard correction project with high DR source (part of source images taken in dark shadows, part -on the sun, using auto explosure without AE lock), and did not find difference in color details. Why?

It depends on the inputs pictures and of the process. If you have exposure difference and use correction, you'll see an increase of dynamic range. If you just use jpeg as input and try to output then as 16bits PSD with no color correction, there will be no dynamic increase in the final panorama. I'll illustrate this concept in a new tutorial soon as it seems to be a hard to understand concept of the software.

Quote:
why converting to HDRI decreases color space? Both in HDRI mode and when saving to HDR-file in another modes?

I didn't understand theses. Could you develop a little :-)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 9:29 am 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
"which says that this picture should be affected by color equalization algorithm"
I think, you lost 'not': should NOT be affected


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 2:06 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
For this discussion I will think about only 1 anchor projects and forget about possibility to use 2+ with your euristic alghoritm to correct colors using 2+ anchors. 2+ will be theme of anothter topic :)

AlexandreJ wrote:
To clarify this explaination, let's separate the way picture are blended with the way pictures are color corrected.

OK. Good starting point to explain methods of blending :) Will try to do this?

As I understand blending modes:

none: find borders between images in overlapped areas, clip images to borders, create big image from clipped fragments. Overlapped parts of images is not used

linear: similar to 'none', but mix parts of neigbours images in small zone along borders to make smooth result. All overlapped information outside of blending zone is not used

multiband: use all overlapping information to find better color values for all points in overlapping areas. This method is best to get HDRI, because of it find correct color from the set of overlapping images.

AlexandreJ wrote:
The blending is the fact of creating one picture using two pictures one on the top of another (like layer in photoshop). So as blending has nothing to do with color correction, let's ignore it. To illustrate this, go to option of the editor and put the "no blend" as default blender for the preview, you'll see what I'm talking about.

I understand result without the expirement: visible borders on normal panoramas (where set of images is used to extend visible area). But for HDRI-projects (where set of overlapped images is used to extend DR) result will be another: DR extension will removed. Is correct? Therefore I attach blending to color correction (for HDRI-projects blending is important part of pixels color selection)

AlexandreJ wrote:
B. Standard color correction :
APP change pixels color according to anchor type per picture. You can have one or more hard anchor (in yellow) which says that this picture should be affected by color equalization algorithm. This mode is to use when you don't have too much change in exposure (up to 2 or 3 IL).
You can use more than one hard anchors : APP will find a way to equalize the color correction between these constraints.

Note about float : The full process is done in float. After the first read of the input picture (jpeg, tiff, raw, etc), it is stored in float in memory and all calculation are done in float. Every format is used at maximum dynamic range possible (for example, raws gives at least 16bits). The level tools even if it shows a well known photoshop design, is in fact a float level (it's not only 0 to 255 values there). After every operations, stitching, projection, color correction, filter, level, there might be at the end of the process a reduction to 8bits or 16bits following the format you want as output. But during the full workflow, the maximum dynamic range is used.

For example I illustrate this with digits. To simplify, I write integer values, but remember about float operations.

We have 3 images, with different explosure. Anchor - medium, one darker, and one lighter.
darker colors 1..255 will mapped to 1..255
anchor colors 1..255 - to 4..1020
lighter 1..255 - to 16..4080
(multiple values is random, only for example)

we make all operations (levels, stich) and map result back to 8x3 bits, 4..1020->1..255, stripping extra brightness information. Or, may be, 0..4080->0..255? (using of DR without stripping). I think, first idea is correct :)

For 16 bits output we write all range (if possible) to 16 bits, or strip extra ninfomation

For HDR-files - write all information

AlexandreJ wrote:
C. HDRI mode :
You have big gaps in exposure, more than 2, 3-IL. EXIF is absolutely needed.

Why it is important? May be 'standard' mode not uses EXIF and find explosure difference automaticly by analyzing overlapped areas, but HDRI mode - by EXIF? This, plus using HDR slider to change displaed picture and mindatory using of filters to do levels or saving to 8/16 bits is only differences from 'snadrard'?

AlexandreJ wrote:
It works the same way as "Standard Mode". Anchors do influence the results.

How anchors can do influence, if we use only 1 anchor and ALWAYS use all DR?

AlexandreJ wrote:
In this mode, what is displayed on the preview can be really overburned. You have to use HDR level to set a window of display to show the true value of the HDR.

But in 'standard' mode you can display useful image for DR project. Why don't do this in HDRI mode?


AlexandreJ wrote:
Your screen has a 8bits dynamic range, but when using HDRI in APP you can easily achieve a 1,000,000 dynamic range (even from 3, 4 8bits files !). So, your screen need some help to be able to display such pictures. That's why tone mapper has to be used to solve this case, to transform a picture with values from 0 to 1,000,000 to a picture with value from 0 to 255 (High Dynamic Range Image to a Low Dynamic Range Image, HDRI to LDRI).

But similar problem exist also in 'standard' mode!


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 2:13 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
Quote:
Quote:
I can not find way to map HDR-file (from standard correction project) to RGB/24 bits to something, similar to RGB/24 bits, produced by autopano from this project

You need a tone mapper or a software that does that. Photoshop CS2 can do that. Open the HDR file, you'll see that photoshop is working in 32bits mode, and just try to convert it to 8 or 16bits, it will call the tone mapper.

Your really thnink, that I am stupid? :) I try to do this by the way, that you wrote. But result is very different :(

Quote:
Quote:
I try to compare 8- and 16- bits PSD, made from standard correction project with high DR source (part of source images taken in dark shadows, part -on the sun, using auto explosure without AE lock), and did not find difference in color details. Why?

It depends on the inputs pictures and of the process. If you have exposure difference and use correction, you'll see an increase of dynamic range.

Be careful, please! I wrote, the use set of images that procues high DR project, because part of images was taken in shadow, part - on sun. I will attach samples later. 32 source images with fixed aperture and speed from 1/25 to 1/400. Thanks to polaroid filter - that decrease bright os sky :)

Quote:
If you just use jpeg as input and try to output then as 16bits PSD with no color correction, there will be no dynamic increase in the final panorama. I'll illustrate this concept in a new tutorial soon as it seems to be a hard to understand concept of the software.

I hope that our discussion will help us to write this tutorial :)

Quote:
Quote:
why converting to HDRI decreases color space? Both in HDRI mode and when saving to HDR-file in another modes?

I didn't understand theses. Could you develop a little :-)

See my examples below


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 3:52 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
About 'why converting to HDRI decreases color space' - this is continue of 'I can not find way to map HDR-file'. I alway got low contrast and bad colors green, blue - near to gray :) But I find way. For my example (URL will be later) I find settings: there is 'gamma' in explosure filter, and setting it to 2, with small changes of explosure and offset, will produces result, similar to 8x3 bits outpust from autopano


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 4:10 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
And continue - after short playing with 'explosure' tools in PS I convert HDR (made with anchor in light zone of photo) from image, similar to 8x3 bits output of autopano to image, similar to 8x3 bits output of project with anchor in dark shadow :)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 4:18 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
I think, autopano need to extend it's 'level' tools :)

At end of 'HDR problem' I found source of this mistake. If i use 'explosure' tools in photoshop and simple set gamma to 2, I see correct picture. After that I can convert in to 16 bits/cnahhel.

But before I try to use converting to 16 bits without 'explosure'. I thinked, thet no need to use 'explosure', because of mapper to 16 bits have explosure/gamma setting. Bit it works different - setting gamma to 2 in it get image, near to black & white :)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 10:05 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
source files of project http://dejavu.spb.ru/pano/a.zip (2MPixels images scaled down to 25% of original)

This is real HDR set (speed from 1/25 to 1/400 with fixed aperture).

result of setting anchor to shadow:
Image

to light area
Image

comparing 8- & 16-bit PSD, produced from this project (anchor in the light).

Image

to compare I load both to the PS, convert to 32-bits and use 'explosure' to make images lighter to +5. Do you see difference in details of shadow area? :) I am not!


Last edited by Panorama fanatic on Tue Feb 21, 2006 10:09 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 21, 2006 10:16 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
Blending error! Result of blending, using miltiband metod:

Image

See to bottom-right of light zone, to the up from border of shadow. What do you see? Why? On overpapped area of of source images this zone is overexplosured on bottom source, and correct on the top source (shadow is underexplosured on the top, and correct on the bottom). Autopano correct blend image in shadow, but incorrect - on the light.


Last edited by Panorama fanatic on Tue Feb 21, 2006 10:19 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 22, 2006 12:49 pm 
Offline
Member

Joined: Tue Dec 06, 2005 1:57 pm
Posts: 2946
Location: Grenoble
Alexandre wrote:
To illustrate this, go to option of the editor and put the "no blend" as default blender for the preview, you'll see what I'm talking about.

This setting is worth the test ! Before I saw your post, I never realized that Layer view should be named Source images view.

Because I often use lenses where distortion is high and because I misinterpreted what is seen in this view mode, I was frustrated. Now I understand that the lens distortion is corrected in the global preview (cursor out of image) while it's not corrected in the different layers (when rolling the mouse wheel.)

What is an evidence for the developer is not always evident for the user...

_________________
Georges


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 22, 2006 1:26 pm 
Offline
Member

Joined: Tue Dec 06, 2005 1:57 pm
Posts: 2946
Location: Grenoble
Alexandre wrote:
B. Standard mode : This mode is to be used when you don't have too much change in exposure (up to 2 or 3 EV).

Alexandre wrote:
C. HDRI mode : You have big gaps in exposure, more than 2or 3 EV. It works the same way as "Standard Mode". Anchors do influence the results.

May we conclude that - contrary to what should be done when using most stitchers - when shooting views for APP, one can leave the camera in auto-exposure mode (or use manual mode in his/her usual way) rather than using AE lock (and WB lock when available) ?
That is:
Camera AE lock --> APP mode: no color (and exposure) corrections (NONE - default)
Camera auto mode --> APP mode: standard color (and exposure) corrections (AUTO) <-- exposure difference less or equal to 3 EV
Camera manual mode --> APP mode: HDRI color (and exposure) corrections (HDR) <-- exposure difference higher or equal to 3 EV

_________________
Georges


Last edited by GURL on Wed Feb 22, 2006 1:27 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 22, 2006 2:52 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
I think, that explosure mode (manual/auto) is not important to select color correction mode. Only explosure difference is important. And (if I understand Alexandre correct) - important difference only between adjoinig images. If you have row of 10 images, with difference between neighbours +1 EV, and +9 EV from begin to end, it is good for AUTO correction. But +4 EV between neighbours needs HDRI.

Axelandre, it is corerct?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 22, 2006 5:44 pm 
Offline
Member

Joined: Tue Dec 06, 2005 1:57 pm
Posts: 2946
Location: Grenoble
Panorama fanatic wrote:
Only exposure difference is important.

Defining what is meant by exposure difference would help!

My question results from the usual advice to "lock everything" when shooting for panoramas: ISO, aperture, speed, contrast (if available), white balance (if available). I know (tested) this is not at all mandatory when using APP and some examples on APP website show that, but I believe this is not necessarily obvious for everybody and would like to know when variable exposures give better results and whether or not exposure time variations only are acceptable.

Panorama fanatic wrote:
[..]difference between neighbors +1 EV, and +9 EV from begin to end, it is good for AUTO correction. But +4 EV between neighbors needs HDRI.

Very interesting point, though a precise answer could be difficult...

_________________
Georges


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 22, 2006 6:27 pm 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
Quote:
But +4 EV between neighbours needs HDRI

True. I make the same panorama in hdri mode and the blend is perfect. If you allow the use of your picture, I'll add a full page to the wiki which explain all concept.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 22, 2006 9:32 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
Yes, you can use this images for example. This is one of famous places in the world: Wadi Qelt (and the Monastery of St. George)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 22, 2006 9:43 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
Defining something is very hard for my English. I can do it in Russian :)

For Autopano best practice is not lock explosure - this get maximum qality of image, with minimum overexplosured and underexplosured areas, and autopano will correct colors - make image similar to taken with AE lock.

Image

no color correction. Image part in shadow lighter, that part on the sun light :) Looks like taken with flash :)))) Compare to the expamples before - it made from one set of source images.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 22, 2006 10:35 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
Alexandre, I make panorama in HDRI mode, convert to RGB by autopano. Result

Image

:(


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 22, 2006 11:11 pm 
Offline
Member
User avatar

Joined: Fri Dec 02, 2005 4:32 pm
Posts: 122
Location: France, Chambéry
Was this zone burned in sources images ?

_________________
François Simond


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 23, 2006 12:20 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
Image Image

Only small part of overexplosured zone is not doubled in normal photo


Last edited by Panorama fanatic on Thu Feb 23, 2006 12:21 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 23, 2006 1:31 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
Summary of things, needs answer from Kolor:

1. Yes/No: the only difference between auto/HDRI color correction - is described before requirement to explosure gaps between adjoining images + method to map internal HDRI color to 8/16 bits ('auto' color correction have some default method, but HDRI correction require using of color filters)
2. Yes/No(describe) Default color mapping method of 'auto' correction is simply truncate DR of project, using range of anchor image. This make 'anchor' part of output equal to 'anchor' source image (if levels is not used), and another parts - over- or underexplosured, basing of anchor image.
3 If auto mode is HDRI inside, why do not use 'HDR' tools to preview image in 'auto' mode.
4 Please, describe filters. Better - with examples. It is impossible to understand without description, therefore using of filters is always expirement.
5 I think, that there is 3 possible inprovement:
- change HRDI preview selector to some, like 'scrollbar', where width of moving bar of this tools will reflect size of visible part of full DR.
- combine 'filters' and 'levels' in one tool to qiuckly see result of all changes
- allow using of 'levels' to map HDRI to 8/16 bits in HDRI correction mode


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 23, 2006 1:40 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
Possble design for combined tool:

Filters:
(*) none
( ) filter 1
( ) filter 2

area with tools for filters (changed where another filter selected)

standard 'level' tool


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 23, 2006 1:54 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
6. Why I can't find difference between color details in 8- and 16-bits output in example above?
7. If I correct understood, that HDRI to standard mapping in 'auto correction' is truncating, and you agree to use 'levels' as tool to map HDRI to standard, it can be better to display full DR in levels, and set default 'min' and 'max' values to the points, that you use now ti truncate. Possble enchancement is adding textareas to display size of select DR (in percents of standard) and offset to DR of anchor image


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 23, 2006 2:03 pm 
Offline
Member

Joined: Mon Dec 19, 2005 2:28 pm
Posts: 403
Location: St-Petersburg, Russia
8. Yes/No. Did i correct understand difference between blending modes? It is important answer to discuss about blending modes :)
9. Need example - how to map HDRI correction image of my project to image, similar to example before (example is pucture with acnhor in light area). I can do it only in PS, but want to do in autopano (to have layered output with source layers)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 23, 2006 5:11 pm 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
Here's a full page on this sample :
Advanced color correction

Image


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group