 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Also if you don't have enough memory to load the entire image, you can't
use it at all.
--
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Cook wrote:
> Christoph Hormann wrote:
>
>> No. you can already use that large images right now - your OS
>> swapping and address space permitting. You don't do this though
>> because the performance loss makes it unfeasible. This isn't different
>> with 'on-demand' reading of image data from disk (except parsing might
>> be a bit faster in the latter case).
>
>
> No, I literally don't have any software that can read such a large
> image. ^^; Paint Shop Pro, GIMP, Photoshop, and so forth, can't read
> images larger than a certain size
Actually GIMP should be able to deal with large images without problems
with its tile cache:
http://www.gimp.org/unix/howtos/tile_cache.html
(at least if it is built with large file support which is default with
current versions i think).
And there are various other programs able to process large image files
- one was mentioned in p.g. in reply to you:
Subject: Re: Callling all Earth renderers - Blue Marble "next generation"
Date: Sat, 22 Oct 2005 04:41:30 EDT
From: PM 2Ring <nomail@nomail>
Newsgroups: povray.general
And as noted in
http://www.imagico.de/pov/earth_bm.html
GDAL is also predestinated for this - after adding an appropriate ppm
header to the raw data:
P6
86400 43200
255
Finally the 500m images are also available in 21600x21600 tiles.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Cook <z99### [at] bellsouth net> wrote:
> No, I literally don't have any software that can read such a large
> image. ^^; Paint Shop Pro, GIMP, Photoshop, and so forth, can't read
> images larger than a certain size, I think around 32768 for either
> dimension, which the 500 m/pixel set definitely exceeds, horizontally...
Just tried to copy-paste a 3500 pixels wide image in MS-Paint (XP-prof)
today:
No warnings, just a nice crash :-) repeatable on other systems as well...
(that's with 1.5GB of memory) On the other hand, the new notpad in XP will
load files larger than 64kb (it will take an hour or so, and actually using
it after that is next to impossible.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Cook" <z99### [at] bellsouthnet> wrote in message
news:4378ee2b$1@news.povray.org...
> Christoph Hormann wrote:
> > No. you can already use that large images right now - your OS swapping
> > and address space permitting. You don't do this though because the
> > performance loss makes it unfeasible. This isn't different with
> > 'on-demand' reading of image data from disk (except parsing might be a
> > bit faster in the latter case).
>
> No, I literally don't have any software that can read such a large
> image. ^^; Paint Shop Pro, GIMP, Photoshop, and so forth, can't read
> images larger than a certain size, I think around 32768 for either
> dimension, which the 500 m/pixel set definitely exceeds, horizontally...
The maximum image size supported by Photoshop is 300 000 x 300 000 pixels. The
maximum file size is 4 GB for PSD and TIFF files, and 100 GB for PSB
(Photoshop's new "large document" format). Obviously RAM will be a limiting
factor here, in terms practicality. It's possible to get Photoshop to use
around 3 GB of RAM on 32-bit XP, and more on 64-bit XP (though Photoshop limits
the amount of RAM it uses to around 4 GB, and if you have a system with more RAM
than that then it will use it for cache data before writing to the Photoshop
scratch disk files). If you don't have a lot of RAM, the HDD access is going to
slow things to a crawl.
There's some information about this here:
http://www.adobe.com/support/techdocs/320005.html
and here:
http://www.adobe.com/support/techdocs/331372.html
However, this is assuming you have Photoshop CS2. And unless you're rendering
to very large output sizes, having the higher resolution maps may make no
noticeable difference to the result anyway.
By the way, nice image, I think I can see my house from here :)
Lance.
thezone - thezone.firewave.com.au
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Cook spake:
> Stefan Viljoen <spamnot@ wrote:
>> I'm impressed! NASA maps?
>
> Yup. The new Blue Marble dataset...5400x2700 version, June. I'd really
> like to play with the 500m/pixel set, but don't have any way of doing
> so. Would be nice if POV 4 were able to use very large images without
> loading the whole thing into memory...by that time there'll probably be
> 1m/pixel dataset available hehe.
Hmm - are you rendering in Windows?
IMHO if you try Linux Pov you might have better stability and performance
when memory gets tight - in my inexperienced opinion (Christoph should know
more about this) Linux is more reliable than Windows when you start to page
lots of RAM to disk (such as when working with something that takes up all
available RAM, and more).
I have once or twice managed on my older PC's to use about 1.5 times
physical RAM in Pov when rendering - no problems, while on XP it got
incredibly slow and crashed regularly for the same .POV file... but that
was long ago on older architecture (400 MHz machine with 128MB).
Anyway! If your Windows rendering experience gets crappy when using all RAM
or close to it, try Linux.
--
Stefan Viljoen
Software Support Technician / Programmer
Polar Design Solutions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stefan Viljoen <spamnot@ wrote:
> I have once or twice managed on my older PC's to use about 1.5 times
> physical RAM in Pov when rendering - no problems, while on XP it got
> incredibly slow and crashed regularly for the same .POV file... but that
> was long ago on older architecture (400 MHz machine with 128MB).
Hmm...well I guess I might be able to do it after all, then...HOLY CRAP
the 500 m dataset is 65 GB?! Barely have enough hard drive space for
that...*fear*
Anyhow my hope was to make an animation, from surface-to-space...or the
other way 'round...
--
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch wrote:
> The maximum image size supported by Photoshop is 300 000 x 300 000 pixels.
...
> However, this is assuming you have Photoshop CS2. And unless you're rendering
> to very large output sizes, having the higher resolution maps may make no
> noticeable difference to the result anyway.
Er...must be a new ability, I have an older version of PS and it wasn't
able to make the 21600x21600 hemisphere image of the first BM version
43200 wide so I could add the other hemisphere to it...
--
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmm, and it's 21600x21600 chunks, too...how do I make an isosurface that
applies an image as a radius modifier to a section of a sphere so that
the entire image maps to a 45x45-degree segment?
The code I have for the entire image to the whole sphere is
#include "functions.inc"
#declare fn_EarthPigm1=function{
pigment{
image_map{
jpeg "srtm_ramp2.world.5400x2700.jpg"
map_type 1
once
interpolate 4
}
}
}
#declare EarthIso=isosurface{
function{f_sphere(x, y, z, 0.633)-(fn_EarthPigm1(x,y,z).red*0.006)}
contained_by{sphere{0,0.7}}
texture{pigment{rgb 1}}
scale <-1,1,1>
rotate <90,0,-90>
}
...I'm guessing there's a way to apply fn_EarthPigm1 to only part of the
sphere? But how?
--
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Cook wrote:
>
> Hmm...well I guess I might be able to do it after all, then...HOLY CRAP
> the 500 m dataset is 65 GB?!
That's wrong. One full data set is exactly 3x86400x43200=11197440000 bytes.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Cook wrote:
> Hmm, and it's 21600x21600 chunks, too...how do I make an isosurface that
> applies an image as a radius modifier to a section of a sphere so that
> the entire image maps to a 45x45-degree segment?
Just map it accordingly - using a mapping warp or manually using the
f_th()/f_ph() functions:
#local fn_Spherical=
function {
fn_Flat(1-(f_th(x,z,y)+pi)/(2*pi), f_ph(x,-z,y)/pi, 0)
}
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
