File-size .psb

[Maw.]

File-size .psb

by Maw. » Thu Jan 17, 2013 11:25 am

Hello,
I´m having a GigaPixel Test-pano with a file-size of 550.000x150.000px in AutoPano Giga 3.
If I want to render as .psb it says that maximum render-size is 300.000x300.000px

I thought I can render more then 300.000 but just photoshop can´t open files over 300.000?

Regards,
Marc

[gkaefer]

by gkaefer » Thu Jan 17, 2013 11:57 am

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 on Thu Jan 17, 2013 11:59 am, edited 1 time in total.

[con]

by con » Thu Jan 17, 2013 12:05 pm

you can then render it as kro file that will allow +300k px size.

Of course what you're going to do with a kro file of that size is another matter, as PS doesnt handle kro files AFAIK

[Maw.]

by Maw. » Thu Jan 17, 2013 12:08 pm

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

[mediavets]

by mediavets » Thu Jan 17, 2013 12:50 pm

you can then render it as kro file that will allow +300k px size.

Of course what you're going to do with a kro file of that size is another matter, as PS doesnt handle kro files AFAIK

See: http://www.bigmike.it/kroutils/

[gkaefer]

by gkaefer » Thu Jan 17, 2013 1:45 pm

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-08-11-11-53-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-12-27-13-19-21#p109335
(this still does not solve the problem with psb....)

Georg

Last edited by gkaefer on Thu Jan 17, 2013 1:46 pm, edited 1 time in total.

[Maw.]

by Maw. » Thu Jan 17, 2013 1:53 pm

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

[HansKeesom]

by HansKeesom » Thu Jan 17, 2013 2:00 pm

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.]

by Maw. » Thu Jan 17, 2013 2:06 pm

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

[HansKeesom]

by HansKeesom » Thu Jan 17, 2013 2:14 pm

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]

by klausesser » Thu Jan 17, 2013 2:31 pm

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

[HansKeesom]

by HansKeesom » Thu Jan 17, 2013 2:39 pm

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]

by gkaefer » Thu Jan 17, 2013 3:24 pm

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 ;-)

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

[HansKeesom]

by HansKeesom » Thu Jan 17, 2013 3:46 pm

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? ;-)

[klausesser]

by klausesser » Thu Jan 17, 2013 3:53 pm

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.

Hans - you completely misunderstood what i wrote, sorry. Being a photographer i definitely know about dpi/ppi very well . .
But i´m afraif you oversee what the render-dialog tells you too:
raising the dpi decreases the SIZE of the output - while keeping the absolute pixel-amount OF COURSE.

My point was to "trick" Photoshop by giving it the full pixel-amount - but on a smaller dimension. In earlier Photoshop days (vers. 3 as example) that was a common
"trick".

I´m suprised you could misunderstood that

best, Klaus

[HansKeesom]

by HansKeesom » Thu Jan 17, 2013 4:04 pm

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.

[gkaefer]

by gkaefer » Thu Jan 17, 2013 4:12 pm

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? ;-)

ok. understood. my fault. the dimensions is changing not the pixels value.
Georg

[HansKeesom]

by HansKeesom » Thu Jan 17, 2013 4:15 pm

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.

[klausesser]

by klausesser » Thu Jan 17, 2013 4:35 pm

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

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

Hans - i´m so tired to discuss these things over and over with non-pros and let them treat me like an absolute beginner -
i´m in this business for more than three decades . .

You don´t need to "explain" anything to me regarding this. Really.

DPI=Dots Per Inch
PPI=Pixel Per Inch

Klaus

And: no - there are NO "smaller units than dpi and ppi".

Last edited by klausesser on Thu Jan 17, 2013 4:48 pm, edited 1 time in total.

[klausesser]

by klausesser » Thu Jan 17, 2013 4:40 pm

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

That´s what i said.

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 on Thu Jan 17, 2013 4:42 pm, edited 1 time in total.

[HansKeesom]

by HansKeesom » Thu Jan 17, 2013 7:52 pm

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

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

Hans - i´m so tired to discuss these things over and over with non-pros and let them treat me like an absolute beginner -
i´m in this business for more than three decades . .

You don´t need to "explain" anything to me regarding this. Really.

DPI=Dots Per Inch
PPI=Pixel Per Inch

Klaus

And: no - there are NO "smaller units than dpi and ppi".

Bummer, I warned everyone not to try to explain it logically to creative/publishing/mac people and still I did. Well, your response shows precisely why, let it be a lesson to everyone.

As I do care about you, Klaus, please relax, don't take it this personally, it never was ment to be personall.

[gkaefer]

by gkaefer » Thu Jan 17, 2013 8:27 pm

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]

by HansKeesom » Thu Jan 17, 2013 9:24 pm

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 ;-)

[gkaefer]

by gkaefer » Thu Jan 17, 2013 10:19 pm

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 on Thu Jan 17, 2013 10:33 pm, edited 1 time in total.

[HansKeesom]

by HansKeesom » Thu Jan 17, 2013 10:34 pm

You know what, I am not even gonna bother. Too many panoramas have been uploaded to me this evening, lot's of work to be done and money to be made!

Last edited by HansKeesom on Thu Jan 17, 2013 10:34 pm, edited 1 time in total.