zbigi wrote:

The source images are accessible here:
http://fotopano.pl/testfiles/ap_error/source_images.zip

This URL does not appear to be valid?

Issue 597 opened

Thanks for suggestions concerning panorama size.

But I probably do not understand everything from the explanation correctly. I have supposed, that the width of panorama is the value calculated by Autopano based on size of pictures used to stitch them into panorama, therefore I should not choose it arbitrarily by hand.
Am I wrong?

Last edited by zbigi (2011-02-21 23:22:45)

zbigi wrote:

It seems to me that somewhere I read about it (maybe even on this forum), but now I can not find it.

In version 2.0.9 Autopano there was no problem with connecting the left and right edges of the panorama. After generating the relevant files to the player it was not possible to notice the place where the left and right edges are joined together.

Yesterday I lost whole day on trying many times to generate only one panorama with Autopano Giga 2.5. I inform You just now, that I have already stitched a number of panoramas using the version of AP Giga and have not noticed that phenomenon, which I describing below. I made many attempts, because every time on the place where left and right edge of equirectangular panorama it was very clear to see the tone difference in the color of the sky, which should be exactly the same on left and right side of the line, along which the edges have been joined together.

For test purposes I have stitched the same images (nearly the same way) with Autopano Giga 2.0.9. As a result I have obtained the equirectangular picture, which have not containing that error.

I attach the screenshots from the preliminary test panorama with DevalVR player.

The panoramas prepared for the krpano player are located here:
http://fotopano.pl/testfiles/ap_error/pano_AP2.5.html - version made in the Autopano Giga 2.5 - the lens flares are retouched, but the error have looked out exactly the same before retouching flares,
http://fotopano.pl/testfiles/ap_error/pano_AP2.0.9.html - version of Autopano Giga made in 2.0.9 - completely not retouched, the erroris  invisible.

Probably previously made with 2.5 Autopano panorama also contained the same error, but did not throw it in the eye.

Has anyone come across this prolemem? Or maybe you know how to remove it?

I am allowing to download also pano file saved with Autopano Giga 2.5. It is here: http://fotopano.pl/testfiles/ap_error/G … mages.pano

The source images are accessible here:
http://fotopano.pl/testfiles/ap_error/source_images.zip

Hi!
Sorry, i didn´t read it all - but:

Looks like you simply have one darker and one brighter end of the equirectangular image. Did you work it over in Photoshop or so?
A way might be: convert it to cube-faces and see where the line occurs. Then retouch the face so that there´s no borders of lighter/darker areas where the two ends meet.

best, Klaus

P.S.: use ColorCorrection to equalize darker and brighter areas.

Last edited by klausesser (2011-02-22 12:24:06)

zbigi wrote:

. . but I only would like to signalize the Autopano developers, that not everything is OK with the newest version of the blender.

I doubt that´s the point here. I use it every day - the only time i had such an ussue was when i accidently had the left end darker than the right end by retouching lights and shadows.
I converted the equi to cubefaces and retouched the one with the seam - worked perfectly.

But of course the best way is to strictly avoid darkening/lighting at the borders after (!) rendering. Always keep a distance from the borders of the image.
To do equalization in color or brightness use CC in the stich-editor and not afterwards.

I always work on the rendered images - therefore i know the issue in your picture very well . .

Klaus!

In one place You wrote

klausesser wrote:

I always work on the rendered images - therefore i know the issue in your picture very well . .

Few minutes after:

klausesser wrote:

I doubt here very much - otherwise other users would report the same issue...

Perhaps my not sufficient lauguage knowledges are the reason, that I am not sure are You met the defect in working of blender or not.

As I have written: the blender of Autopano 2.0.9 (Smaltblend) did not puting out the pictures wit such unequvalence of tones on the left and right edge.

I You have ageed with that error, OK.
But in my oppinion the error is existing in new version of Autopano (containing ne blender) and did not exist in older version (containing Smartblend).

Thank You for Your interest. Best regards!

The dimension matter in fact. Do the rendering with a 8000 pixels width and it won't happen. We have found patch and it will be available in v2.5.1.

If you round the size at the next multiple of 128, it should work too : 7504 / 128 => 58.625. Then do 58 * 128 = 7424. This value should be okay too.

again: take care your image isn´t of different density on both ends. This issue isn´t a bug.

best, Klaus

Last edited by klausesser (2011-02-25 21:53:56)

By density he means that your 1st & last exposure value should be same if they differ then this border line effect comes due to blending the dark & light areas.

This often happens if you take images on auto exposure mode but the bug you describe has been noticed by me too but i didn't spend much time on that as it was a test pano only.

hermer-blr wrote:

Even with the definition you give, there is obviously a bug : while different exposures anywhere else in the panorama will be correctly corrected, different exposures at left/right border would not ! Unacceptable.

I did now some dozens of panos using 2.5 - NEVER had this issue even with clear blue skies. I definitely doubt it´s a 2.5 bug.

best, Klaus

Oops! I just realized you´re talking of AP and not APG. Sorry.

Last edited by klausesser (2011-02-27 15:35:10)

There is a new version, i.e. Autopano Giga 2.6 final released (on 15.12.2011).
During the time ad all Beta and RC versions, starting from my first post concerning blending errors on the left and right edges of panorama, observed by the version 2.5 the error is still existing. Also in that final version. it seems to me, that t\Kolor is satisfied because ot that quality. what for me is -  unfortunately - absolutely not acceptable.
Please work on that problem seriously and solve it.

Last edited by zbigi (2011-12-18 23:45:13)