1. how many RAM do you use?
2. under autopano giga 3.0.3 -> Settings -> General -> Memory used:

"outputsize can not be larger than xxxxx(xx) pixels."
(depending on Cache division settings above used...)

if I (with 16GB RAM) change the default 1MB Cache = 65536 pixels change to 36MB Cache than pixel limit raises to 2097152 (with drawback that antighost will be unavailable with more than 105images/row)

(I'm optimist and assume this values tells us the width and not the total number of pixels in pano...)

Georg

Last edited by gkaefer (2013-01-17 11:59:47)

Hi Georg,
I´m just having 8GB of RAM (now 5GB free) and it says outputsize can not be larger than 524.288px
cache is set to auto.
Tried to change to 32MB Cache (2.097.380px) but doesn´t change the max rendersize of 300.000px in psb

Maw. wrote:

Hi Georg,
I´m just having 8GB of RAM (now 5GB free) and it says outputsize can not be larger than 524.288px
cache is set to auto.
Tried to change to 32MB Cache (2.097.380px) but doesn´t change the max rendersize of 300.000px in psb

hm. 8GB.... i see just dark clouds arising...
see the calculation from Hans:
http://www.kolor.com/forum/p87033-2011- … -58#p87033

step 1: lets try it with 150 x 100 images a 10 megapixel * 4 = 480000 MB = 468 GB scretch Harddisk needed
step 2: 8 GB Ram : 468 GB HD = ratio of 1:58

Hans assumes that up to 1:4 a render will succeed, very slow but with success 1:4+ it may succeed but ultra slow (days...)

I would say 1:58 is wasting time to try it.

I recently upgraded from 8 to 16GB ram (most 5years old motherboards can handle 16GB ram if you bought them with 8GB...) and this is a huge step. but this size of pano I would never try even with 16GB....

with this setup I would try: http://www.kolor.com/forum/p109335-2012 … 21#p109335
(this still does not solve the problem with psb....)

Georg

Last edited by gkaefer (2013-01-17 13:46:14)

Maw. wrote:

thank you Georg. Hoping my ordered new iMac (32GB and SSD) will arrive soon
but I will take a look to the kroutils.

if your mac takes too long, send the project over in dropbox and I will render it for you, for free!

Maw. wrote:

Hello Hans,
that´s a really nice offer. But this is just a test-project so it´s not necessary to render. But maybe I will come back to you

That's no problem, I like to be tested, even with a test-project ;-)
Anytime ;-)

klausesser wrote:

HansKeesom wrote:

Maw. wrote:

Hello Hans,
that´s a really nice offer. But this is just a test-project so it´s not necessary to render. But maybe I will come back to you

That's no problem, I like to be tested, even with a test-project ;-)
Anytime ;-)

IF it´s a matter of dimensions (a x b) and not a matter of data-size a way might (!) be to raise the dpi in the rendering. This way the dimensions (a x b)(!) of the rendering
decrease - but of course the numbers of pixels keep the same.

Let´s say instead of 500.000px width @72dpi it´s then 250.000px width @150dpi. If (!) it´s a matter of dimensions and not a matter of the overall pixel-amout=datasize in the data
it should work perhaps - i never tried it with such big dimensions.

Using KRUtil leads to be able to load and save more than 300.000px width (if i´m right) that wouldn´t let you edit the image in PS still if it´s more than 300.000x300.000px.

best, Klaus

Always nice to see dpi passing by. I don't think autopano is really worried about inches or even DPI's. It is just one attribute that is added to the psb. All that counts are the dots or in this case pixels.

DPI is where publishers and computerpeople often clash ;-) Also mac and pc people ;-)  Always fun ;-)

gkaefer wrote:

HansKeesom wrote:

klausesser wrote:

IF it´s a matter of dimensions (a x b) and not a matter of data-size a way might (!) be to raise the dpi in the rendering. This way the dimensions (a x b)(!) of the rendering
decrease - but of course the numbers of pixels keep the same.

Let´s say instead of 500.000px width @72dpi it´s then 250.000px width @150dpi. If (!) it´s a matter of dimensions and not a matter of the overall pixel-amout=datasize in the data
it should work perhaps - i never tried it with such big dimensions.

Using KRUtil leads to be able to load and save more than 300.000px width (if i´m right) that wouldn´t let you edit the image in PS still if it´s more than 300.000x300.000px.

best, Klaus

Always nice to see dpi passing by. I don't think autopano is really worried about inches or even DPI's. It is just one attribute that is added to the psb. All that counts are the dots or in this case pixels.

DPI is where publishers and computerpeople often clash ;-) Also mac and pc people ;-)  Always fun ;-)

Marc did not specify the final use of his pano. So if he wanna print it than Klaus approach of changing in apg the dpi from 72 to 300 will give him smaller dimensions and maybe lower than 300.000x300.000 pixels than also will allow him to save as psb. if he wanna go online with 72dpi than using kro and panotour pro is the road (where he than can export cubes and postprocess them too) kroutils also allows creating slices for postprocessing. but I really doubt kroutils will work propper and can finish such a pano with 8gb RAM. My biggest one not failing with kroutils on a 8GB RAM PC was a 9 GB psb file.

Georg

The render dialog from APG shows my point. You can change the dpi whatever you want, the output size in MB will be exactly the same as will the nr of pixels. And more appropiately in this context, it will not help to get this baby render. The only thing that will helpis reduce the number of pixels horizontally and vertically.

And then, if you really want to print to a certain size in inches, which the OP did not indicate at all, you can make life a bit easier for these output people that freak out if a graphical file is not the right DPI's or right inches.

Wait a minute, am I trying to explain this logically to a publisher? to a mac-user?  ;-)

The problem of the OP has nothing to do with the size in inches, it has to do with the size in MB's. Therefore we need  to talk about size in MB's
When you say size of output, you speak of the size in inches. I am talking about the size in MB's.

It might came as a shock but there are smaller units then DPI and PPI, they are called dots, inches and pixels.

Your explanation is exactly a demonstration of  what I said : creative/publishing/mac people think that DPI is something on it's own, an groundunit while for computer people it is not, it is the result of a calculation. The P in the middle of DPI should tell you enough ;-)

As I said before, try not to explain this to creative/publishing/mac people, so I will leave it here.

indeed, if you only change DPI you will only see the dimension in inches change. And that in itself has no effect on APG being able to render the pano.

HansKeesom wrote:

indeed, if you only change DPI you will only see the dimension in inches change.

That´s what i said.

HansKeesom wrote:

And that in itself has no effect on APG being able to render the pano.

MY GOD, Hans!!!! OF COURSE NOT!!!

The only reason is to trick Photoshop in terms of the dimensions of a x b - how many times of repeating would it take untill you read what i write??

Klaus

Sorry - but i´m really pissed . . .

Last edited by klausesser (2013-01-17 16:42:03)

Hans,

re-reading #11 from Klaus and your answer in #12 I really dont understand how you can construct such a drama about "publishers and computerpeople" including all following replies.
Sorry.

HansKeesom wrote:

George, I am also surprised by the drama the debate on DPI can give sometimes. But I do reject the notion of constructing it. I can't be blamed that that the idea DPI=D/I turns out to be too much for some.
I am sorry I shared my annedotical experience on it here as it turned out not everyone is able to read the smileys or see the yoke of it. Now I could make a yoke here but nah, lets not do that ;-)

I say you construct this nonsens discussion. nonsens not because of topic, but because in Klaus #11 nothing is written about DPI=D/I or whatever you do interprete

he is so vague as possible with x ?:

IF it´s a matter of dimensions (...) and not a matter of data-size a way might (!) be to raise the dpi in the rendering. (...)

ok its not a matter of dimension, its a matter of filesize. finished.

(...) If (!) it´s a matter of dimensions and not a matter of the overall pixel-amout=datasize in the data it should work perhaps - i never tried it with such big dimensions.

its not a matter of dimension...
finished.

no DPI contra D/I, no phytons or whatever involved. sorry for acting like in a soap here...
Georg

Last edited by gkaefer (2013-01-17 22:33:50)