It is currently Mon, 25-09-17, 11:33 GMT

All times are UTC




Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun, 12-02-12, 16:49 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4496
Location: Hamburg, Germany
Hi all,

China's space agency has released an amazingly detailed map of the entire lunar surface this week. The new moon map is made up of many high-resolution photos snapped by China's second lunar probe — the Chang'e 2 orbiter —and stitched together into a complete equirectangular map.

The Chang'e probe is currently stationed at the Sun-Earth L2 Lagrange point
http://lunarscience.nasa.gov/articles/c ... s-l2-point

Image

Note that Chang'e is a Chinese goddess of the Moon...

++++++++++++++++++++++++++++++++++++++++
Of course, all this is a clear signal to start working on an adaptation for Celestia(.Sci).
++++++++++++++++++++++++++++++++++++++++

This thread will contain a detailed description of my approach along with status reports and a discussion of possibly appearing problems. Once I am ready and content with the resulting texture, I'll offer it for download, here.

The link to the chinese server site, was first brought to my attention by Hungry4info over at shatters.net. Thanks for that, Hungry!

http://www.shatters.net/forum/viewtopic.php?f=7&t=16801

To get tuned into what is at stake, here is a tiny example of the amazing amount of detail that we can hope for: A zoomed-in view of the wall of the Tycho crater!
[Click on image by all means!]
Image

The original texture file is simply HUGE!

Size: 213.4k x 106.6k
Color: grayscale

We can't possibly just include such a huge map into Celestia ;-), hence what is required is a proper VT tile set matched to another VT set with highest-quality normalmap tiles. Moreover, it has to be properly cleaned of remaining artefacts.

That's where the work starts. Of course, much of it is done with my superfast F-TexTools/Nmtools that may be downloaded here from Celestial Matters.

Another "speciality" is that the original moon map is offered in lossless JPEG2 (.jp2) format, and hence we first need to use some dedicated software to convert it e.g. to lossless PNG format. Most familiar conversion tools like ImageMagick's convert or XnView nConvert will fail for such a big filesize!

The only software that has a chance of handling such big files during the conversion is gdal_translate, a command-line tool that is part of the FWTools,

http://fwtools.maptools.org/

The FWTools work in principle for all popular OS (Windows, MacOS and Linux).
Installation is trivial.

Unfortunately, the Windows version seems considerably less stable and the memory management less sophisticated than the Linux version. For Linux I encountered no problems in converting the .jp2 original to PNG using the simple console command:

Code:
gdal_translate -of png  Global-50m-sc.jp2 Global-50m-sc.png


As I wrote already in shatters.net, the resulting .png file is huge (8.5 GB) and the conversion took about 4 hours! The texture size is also forbiddingly large:

218527 x 109166!!

Moreover, it's neither a 2:1 aspect ratio nor a power-of-two size, which is required for VT tiling.

Hence (for now) I adopted a modified approach, exploiting additional command options in gdal_translate. I decided to use the scaling option that allows to rescale the original xsize and ysize separately already during the .jp2->.png conversion. So I rescaled the original precisely to a proper 65536 x 32768 size. The required command reads

Code:
gdal_translate -outsize 29.989887% 30.016672% -of png  Global-50m-sc.jp2 moon_64k.png


(You may also use the desired pixels and lines directly instead of percent:
-outsize 65536 32768)

This command takes much less time than the original conversion and left me with an error-free 64k, 2:1 moon texture, which is still "monstrous". There are various arguments why this looks like a good maximum size:

Using my tx2half F-TexTool command twice in a pipe:

Code:
png2bin < moon_64k.png| tx2half 1 65536| tx2half 1 32768 | bin2png 1 16384 > moon_16k.png,


I quickly generated first a 16k texture that I could still load as a whole into Celestia, in order to inspect the image quality and the alignment quality wrto the 64k LRO-WAC normalmap. It became obvious that a considerable amount of "destriping" is necessary and also quite some brightening of the original albedo range. The original moon is far too dark. Moreover, I wanted to computer colorize the texture using a true-color template. The destriping I do with the corresponding ISIS3 routines.

Due to these required operations, a map much larger rhan 64k seems asking too much (for now)... Moreover, 64k would fit well to the best existing normalmap (LRO-WAC).

Unfortunately, the matching with the LRO-WAC normalmap is not perfect with my present strategy. Presumably related to the original NON 2:1 aspect ratio...I will have to experiment here for the best compromise.

Once the matching has been optimized, my F-TexTools are eager to produce an optimized VT tile set. On the one hand, directly, with highest-quality DXT output format and once as PNG format. The result will be offered for download here at Celestial Matters.

If anyone has good arguments for including further considerations/modifications, please let me know before all work is completed...

So far so good...

Fridger


Last edited by t00fri on Mon, 13-02-12, 23:28 GMT, edited 2 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Mon, 13-02-12, 21:03 GMT 
Offline
User avatar

Joined: Fri, 29-02-08, 17:58 GMT
Posts: 86
Beautiful texture! It took several hours in my Core2 notebook in Windows to convert to 64k png (0.9GB). It already made me discover the beautiful crater Atlas, which I didn't know. I will have to photograph it.

_________________
Guillermo Abramson
Bariloche, Argentina


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 13-02-12, 22:44 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4496
Location: Hamburg, Germany
abramson wrote:
Beautiful texture! It took several hours in my Core2 notebook in Windows to convert to 64k png (0.9GB). It already made me discover the beautiful crater Atlas, which I didn't know. I will have to photograph it.


Good you succeeded also within Windows. I guess the secret is to use the

-outsize 65536 32768

scaling option in gdal_translate that limits the output to 64k "only".

Another successful road I explored is to first remain within .jp2 format and just use gdal_translate for a reduction in size, e.g. to 128k or 64k. This is pretty fast (minutes!)

Therafter, I use the isis3 command std2isis to convert the resulting moon_64k.jp2 to an isis3 cub file. This has many advantages. Since isis3 works well with big-sized textures,

you can destripe the texture (dstripe), adjust the brightness, display it (qview) and then convert it to binary format (for my F-TexTools -> VT tiles) or to PNG.

This road is altogether pretty fast!

Unfortunately, after examining several recent normalmap data sets, LRO-WAC, LOLA, Kaguya,..., I found regions of misalignment in most cases so far. For instance around the big Schroedinger crater.

Below, I'll compare the two best-matching sets: LOLA March 2011 (32kVT) and LRO-WAC Nov 2011 (64k VT as adapted by John Van Vliet).

Here is a small image (equirectangular map) from an experimental 16k version that is already computer colored (using the UVVIS 500m texture as template).

Image

And finally, 4 more screenshots from my 16k experimental Chang'e 2 texture as displayed in Celestia(.Sci). The used normalmap is LRO-WAC Nov 2011, as adapted by John Van Vliet to 64k VT tiles.
http://www.celestiamotherlode.net/catal ... on_id=1586

Image

[Click on image by all means ]
Image
[Click on image by all means ]
Image

Image

Fridger


Last edited by t00fri on Tue, 14-02-12, 11:33 GMT, edited 4 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue, 14-02-12, 2:24 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4496
Location: Hamburg, Germany
Find below various views of my colored, experimental 16k Chang'e 2 texture of the moon surface, together with the official 32k LOLA normalmap VT set of March 2011 (deliberately without any modifications):

http://www.celestiamotherlode.net/catal ... on_id=1549

Among all examined NormalMaps, the official 32k LOLA VT release of March 2011 shows by far the best matching with Chang'e 2! Second is the LRO-WAC Normalmap adapted by JohnVanVliet (64k VT). The older 32k March 2010 normalmap VT set by LOLA shows however significant misalignment e.g. around the Schroedinger crater! In addition, this older release still shows considerable systematic artefacts visible at high zoom.

In my opinion the LOLA release of March 2011 gives an VERY appealing display together with my 16k colored Chang'e 2 surface texture. The VT tiles of the LOLA release were obtained with my Nmtools.

I am looking forward now to making colored 64k (32k?) VT tiles of the Chang'e 2 moon surface in highest possible quality!

Fridger

[Click twice (!) on images by all means!]

ImageImageImage


Last edited by t00fri on Tue, 14-02-12, 19:01 GMT, edited 2 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue, 14-02-12, 15:35 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4496
Location: Hamburg, Germany
For those of you who want to experiment a bit, I have collected here some hints about using GDAL routines, notably gdal_translate, from the FWTools package as well as some ISIS3 programs. Unfortunately, the ISIS3 suite has not been ported to Windows.

As I noted already, the FWTools package installation is almost trivial in all OS (Windows, MacOS, Linux). Just read the respective instuctions. Of course, I need to assume here a basic familiarity with using command-line programs.

Two commands are very useful:
  • Code:
    gdal_translate --formats


    With this command, you get a listing of all supported formats along with either read-write (rw) or read-only (ro) specifications.

    As an example:
    with gdal_translate, you may read an ISIS3 .cub file, but you cannot create one (ro!) e.g. from the initial Global-50m-sc.jp2 file.
  • If you just want to reduce the size of the huge initial Global-50m-sc.jp2 file, but still stay within the .jp2 format (that later ISIS3 tools can handle), you would use this command line for generating a 64k .jp2 moon texture:

    Code:
    gdal_translate -of JP2KAK  -outsize 65536 32768 Global-50m-sc.jp2 moon_64k.jp2

    The format designation JP2KAK means that you want JPEG2000 format as provided by the built-in Kakadu library.

    If you have the ISIS3 suite installed (Linux!), you then use first the std2isis routine (GUI) for converting the moon_64k.jp2 file to a ISIS3 .cub format. The respective command-line is
    Code:
    std2isis from=moon_64k.jp2 to=moon_64k.cub

    The output moon_64k.cub can then be further processed with the various ISIS3 tools (all having a GUI!). The GUI cub-viewer is called qview and handles even 64k .cub files surprisingly fast. You may adjust various parameters (brightness, contrast, stretching) within qview as well. Finally one uses either isis2raw or isis2std to export to either binary format for my F-TexTools (VT tile generation) or to PNG format, respectively. All isis3 tools work with VERY big filesizes and are really fast.

    The isis3 suite uses the cross-platform Qt library that also Celestia employs for its graphical interface.
  • At all stages one can get detailed info about the used files with the command
    Code:
    gdalinfo <file>

    e.g. for <file> = moon_64k.jp2, one gets the output:

    Code:
    Driver: JP2KAK/JPEG-2000 (based on Kakadu)
    Files: moon_64k.jp2
    Size is 65536, 32768
    Coordinate System is:
    PROJCS["sc",
        GEOGCS["GCS_Moon_2000",
            DATUM["unknown",
                SPHEROID["unnamed",1737400,0]],
            PRIMEM["Greenwich",0],
            UNIT["degree",0.0174532925199433]],
        PROJECTION["Equirectangular"],
        PARAMETER["latitude_of_origin",0],
        PARAMETER["central_meridian",0],
        PARAMETER["false_easting",0],
        PARAMETER["false_northing",0],
        UNIT["metre",1,
            AUTHORITY["EPSG","9001"]]]
    Origin = (-5461989.407011999748647,2729076.540000000037253)
    Pixel Size = (166.722869873046875,-166.574096679687500)
    Corner Coordinates:
    Upper Left  (-5461989.407, 2729076.540) (179d52'30.49"E, 89d59'57.03"N)
    Lower Left  (-5461989.407,-2729223.460) (179d52'30.49"E, 90d 0'14.47"S)
    Upper Right ( 5464360.593, 2729076.540) (179d47'48.98"W, 89d59'57.03"N)
    Lower Right ( 5464360.593,-2729223.460) (179d47'48.98"W, 90d 0'14.47"S)
    Center      (    1185.593,     -73.460) (  0d 2'20.75"E,  0d 0'8.72"S)
    Band 1 Block=2048x128 Type=Byte, ColorInterp=Gray
      Overviews: 32768x16384, 16384x8192, 8192x4096, 4096x2048, 2048x1024


    For the generated 64k moon_46k.png file gdalinfo moon_64k.png gives:
    Code:
    Driver: PNG/Portable Network Graphics
    Files: moon_64k.png
    Size is 65536, 32768
    Coordinate System is `'
    Corner Coordinates:
    Upper Left  (    0.0,    0.0)
    Lower Left  (    0.0,32768.0)
    Upper Right (65536.0,    0.0)
    Lower Right (65536.0,32768.0)
    Center      (32768.0,16384.0)
    Band 1 Block=65536x1 Type=Byte, ColorInterp=Gray

Hope these remarks are somewhat useful.
Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 15-02-12, 18:25 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4496
Location: Hamburg, Germany
Today, I have completed a 32k Chang'e 2 VT set. It offers quite good views together with the matching 32k LOLA normalmap VT set of March 2011.

Still testing...

In the meantime, here is a cute snapshot with the Chang'e moon in the foreground, next the Earth, in the background the bright M4 and the dimmer NGC 6144 globular clusters and --embedded in nebulosity-- bright redish Antares...
Image

Enjoy,
Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 16-02-12, 17:35 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4496
Location: Hamburg, Germany
... and now for the bad news:

After 1.5 days of testing and experimenting, I am afraid that the new Chang'e 2 surface map of the moon is NOT the best option for Celestia(.Sci)!

Instead, my recommendation is to use the 64k LRO-WAC surface VT set, as adapted by John Van Vliet from the Nov 2011 data:

http://www.celestiamotherlode.net/catal ... on_id=1108

If I had a wish free about JohnVV's VTs, I'd love to see the mares in higher contrast (i.e. darker), and a computer-colored surface using the UVVIS 5 band colored moon imaging as a template...

Anyway, the LRO-WAC surface texture is throughout in beautiful alignment with the official 32k LRO-LOLA normalmap VT release of March 2011!

http://www.celestiamotherlode.net/catal ... on_id=1549

Only after I had created the high-resolution 32k Chang'e 2 surface map yesterday and carefully inspected the maps for misaligned regions etc. it became obvious that the LRO-WAC surface data are preferable for Celestia. While both surface maps are very valuable in general, they do have different key features, as reviewed recently by Phil Stooke

http://www.planetary.org/blog/article/00003372/

For rendering with Celestia, a perfect matching of surface map and normalmap at high resolution has high priority, though. Therefore my preference.

Let me just illustrate a couple of issues.

  • Misalignment of Chang'e 2 versus LRO-WAC:
    Here is a overview shot over the remarkable Mare Orientale. In this smaller zoom view, both surface textures do well when combined with the LRO-LOLA normalmap. Here is JohnVV's LRO-WAC texture, as an example:

    [Click twice (!!) on image by all means!]
    Image

    But now let me zoom in and look at the alignment of individual craters:

    Chang'e 2
    ========
    Image

    LRO-WAC
    ========
    Image

    While I kept the same size for both images, one clearly observes a considerable disturbing misalignment in case of the Chang'e 2 surface texture! The LRO-WAC image beautifully cooperates with the LRO-LOLA normalmap. Note that the apparently inferior surface quality of the Chang'e 2 image is mainly due to the lower resolution used here (32k for Chang'e 2 compared to 64k for LRO-WAC).
  • Another issue are remaining stripes in Chang'e 2 (dark mare regions!).
    ==================================================
    Image

    While these stripes may be eliminated in principle by combining a low-pass and a high-pass filter, it's not so straightforward for >= 32k texture sizes. Here ISIS3 .cub files exceed the hard 2GB size limit and the powerful destriping routines of ISIS3 cease to work.



So, altogether: despite spending already a considerable amount of time on this project, I decided to stop further work on the Chang'e 2 surface texture for the time being. Sigh...

If anyone is interested to do some further experiments with the 16k or 32k Chang'e 2 textures, let me know. I am happy to offer them for download, if there is demand.

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 16-02-12, 19:35 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 991
Location: NE PA, USA
EDIT
Quote:
China's space agency has released an amazingly detailed map of the entire lunar surface this week. The new moon map is made up of many high-resolution photos snapped by China's second lunar probe — the Chang'e 2 orbiter —and stitched together into a complete equirectangular map.


Sorry, I missed that. But where did you see that? I couldn't find any details./EDIT

I just started looking into this and couldn't find any details of how the change2 map was created. Main thing is what projection they used. The LRO map may be using a different projection?

ISIS3 can redo do the projection with map to map. I think there is also a way to remap the change2 map using the lro shape model in ISIS3. This may correct the misalignment problems.

It's been years since I used these programs or had a computer to use them. Still stuck with a laptop using Window 7. So.........

Anyhow someday soon I hope to start using Linux again.

cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 16-02-12, 22:44 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4496
Location: Hamburg, Germany
Hi Steve,

nice to read you again after a while!

cartrite wrote:
EDIT
Quote:
China's space agency has released an amazingly detailed map of the entire lunar surface this week. The new moon map is made up of many high-resolution photos snapped by China's second lunar probe — the Chang'e 2 orbiter —and stitched together into a complete equirectangular map.


Sorry, I missed that. But where did you see that? I couldn't find any details./EDIT


Well, here is one source from which I borrowed some of my introductory sentences.
http://www.space.com/14536-china-moon-m ... mages.html

And sure enough you need to be fluent in Chinese to exploit this site
http://159.226.88.30:8080/CE2release/cesMain.jsp
which has a very handy browsing feature...and many details I cannot understand ;-)

But if you google with chang'e 2 moon you find a LOT of info about Chang'e 2. Notably also the report that Chang'e 2 has reached the Sun-Earth L2 Lagrange point in fall of 2011. Hungry4Info first displayed the link to the Change'e 2 data archive at shatters, etc.

Then of course, there is Phil Stookes comparison of Chang'e 2 with LRO-WAC
(see my discussion above this post)

Quote:
I just started looking into this and couldn't find any details of how the change2 map was created. Main thing is what projection they used. The LRO map may be using a different projection?

I wouldn't have claimed it to be in equirectangular projection in this thread without authoritative confirmation ;-) . The huge original .jp2 texture Global-50m-sc.jp2 comes with an accompanying .xml descriptive file. It is read out with gdalinfo as you will remember:

> gdalinfo Global-50m-sc.jp2

Code:
Driver: JP2KAK/JPEG-2000 (based on Kakadu)
Files: Global-50m-sc.jp2
       Global-50m-sc.jp2.aux.xml
Size is 218527, 109166
Coordinate System is:
PROJCS["sc",
    GEOGCS["GCS_Moon_2000",
        DATUM["Moon_2000",
            SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],
        PRIMEM["Reference_Meridian",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Equirectangular"],                 <=====================
    PARAMETER["False_Easting",0.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Central_Meridian",0.0],
    UNIT["Meter",1.0]]
Origin = (-5461989.407011999748647,2729076.540000000037253)
Pixel Size = (50.000000000000000,-50.000000000000000)
Corner Coordinates:
Upper Left  (-5461989.407, 2729076.540) (179d52'30.49"E, 89d59'57.03"N)
Lower Left  (-5461989.407,-2729223.460) (179d52'30.49"E, 90d 0'14.47"S)
Upper Right ( 5464360.593, 2729076.540) (179d47'48.98"W, 89d59'57.03"N)
Lower Right ( 5464360.593,-2729223.460) (179d47'48.98"W, 90d 0'14.47"S)
Center      (    1185.593,     -73.460) (  0d 2'20.75"E,  0d 0'8.72"S)
Band 1 Block=2048x128 Type=Byte, ColorInterp=Gray
  Overviews: 109264x54583, 54632x27292, 27316x13646, 13658x6823, 6829x3412, 3415x1706, 1708x853, 854x427, 427x214, 214x107


In the output I marked the specified projection with a long arrow: <==============

Quote:
ISIS3 can redo do the projection with map to map. I think there is also a way to remap the change2 map using the lro shape model in ISIS3. This may correct the misalignment problems.

Not required, see previous paragraph.

Quote:
It's been years since I used these programs or had a computer to use them. Still stuck with a laptop using Window 7. So.........

Anyhow someday soon I hope to start using Linux again.

cartrite

I seriously hope we'll be lucky seeing more of you here, these days...

Cheers,
Fridger


Last edited by t00fri on Fri, 17-02-12, 22:35 GMT, edited 2 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri, 17-02-12, 10:24 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 991
Location: NE PA, USA
Hey Fridger,
Sorry I haven't been active lately. I'm either too busy or when I got the time, I don't have the equipment to really get back in the game.

I never downloaded this file but I suspected there would be an xml file with some of the details. I overlooked that gdal output you posted. Sorry about that.

Anyhow, I hope I didn't overlook this too. Did you know why this file is not a power of 2? Is there any duplication of data columns? ISIS may be a better way of reducing the file. That way it could crop out any duplicate data before resizing. That is if there is any duplicate data. It seems an odd size.

cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Fri, 17-02-12, 11:37 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4496
Location: Hamburg, Germany
cartrite wrote:
Hey Fridger,
Sorry I haven't been active lately. I'm either too busy or when I got the time, I don't have the equipment to really get back in the game.

I never downloaded this file but I suspected there would be an xml file with some of the details. I overlooked that gdal output you posted. Sorry about that.

Anyhow, I hope I didn't overlook this too. Did you know why this file is not a power of 2? Is there any duplication of data columns? ISIS may be a better way of reducing the file. That way it could crop out any duplicate data before resizing. That is if there is any duplicate data. It seems an odd size.

cartrite


Indeed, the Chang'e 2 file size is a bit of a mystery. Apart from NOT being a power of two, the texture has a strange aspect ratio as well. This could well be a reason for the partial mismatch with the LRO-LOLA normalmap. Unfortunately, most of the info on the Chang'e web site is in Chinese...

Isis3 has its limits for really big size textures: 2GB for a RGB cub file is not much in this game. I was trying to offer a colorized (RGB) texture using the UVVIS-500m, 5 band images as color template. Expanding from a grayscale .cub to a rgb .cub already exceeds 2GB for a 32k texture size.


Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Fri, 17-02-12, 11:52 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 991
Location: NE PA, USA
Here is something I seen at the ISIS support forum.

Quote:
Hi Brian,

The maximum file size in ISIS2 is 2GB.

In ISIS3 there is certainly some limit imposed by the operating ofr file system. I know of people who have created over 120GB images in ISISI3.

Jeff


https://isis.astrogeology.usgs.gov/Isis ... ml#msg8027

I still think I remember there being a limitation on file size when converting a .cub file to std (isis2std). But a work around for that would be to cut up the main .cub file and convert them in sections. Still there is much I forgotten. I haven't worked with ISIS for some time now.

EDIT If I remember correctly, :wink: I don't think there is a file size limit on the isis2raw program. That way you could use your tools to convert to png. /EDIT

cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Fri, 17-02-12, 12:56 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 991
Location: NE PA, USA
t00fri wrote:
While these stripes may be eliminated in principle by combining a low-pass and a high-pass filter, it's not so straightforward for >= 32k texture sizes. Here ISIS3 .cub files exceed the hard 2GB size limit and the powerful destriping routines of ISIS3 cease to work.


I'm not sure why this would happen. But I did see in the ISIS support forum that file sizes can be set in ./ISIS/ISISPREFRENCES or something to that effect. Maybe this is why?

I can remember doing a lot of HiRISE images in color which were well over 2 GB and I can't remember having any problems running hipass or lowpass. I believe I did work on them 1 band at a time though? Not sure now.

But this is in the ISIS docs.
Quote:
Please note: there is currently a 2GB filesize limit on the output image. This limit does not apply to output JPEG2000 files. JPEG2000 files can be output as 8-bit, signed 16-bit, or unsigned 16-bit files.


cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Fri, 17-02-12, 16:17 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4496
Location: Hamburg, Germany
Steve,

cartrite wrote:
t00fri wrote:
While these stripes may be eliminated in principle by combining a low-pass and a high-pass filter, it's not so straightforward for >= 32k texture sizes. Here ISIS3 .cub files exceed the hard 2GB size limit and the powerful destriping routines of ISIS3 cease to work.


I'm not sure why this would happen. But I did see in the ISIS support forum that file sizes can be set in ./ISIS/ISISPREFRENCES or something to that effect. Maybe this is why?

Indeed, now that you reminded me of it: I read that the 2GB value may be modified.
Thanks, I'll investigate...

Incidentally, my last IRIS3 activities are also from quite a while ago. Do you happen to remember, how to make certain stretch adjustments (brightness, contrast) in qview permanent such that they may be exportet?
Quote:
I can remember doing a lot of HiRISE images in color which were well over 2 GB and I can't remember having any problems running hipass or lowpass. I believe I did work on them 1 band at a time though? Not sure now.

But this is in the ISIS docs.
Quote:
Please note: there is currently a 2GB filesize limit on the output image. This limit does not apply to output JPEG2000 files. JPEG2000 files can be output as 8-bit, signed 16-bit, or unsigned 16-bit files.


cartrite


When I got an error from working with too large a texture, the wording sounded as if there was a hard limit, since some library (forgot which) was unable to handle 6GB sized files...

Fridger


Last edited by t00fri on Fri, 17-02-12, 22:36 GMT, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri, 17-02-12, 16:49 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 991
Location: NE PA, USA
t00fri wrote:
Incidentally, my last IRIS3 activities are also from quite a while ago. Do you happen to remember, how to make certain stretch adjustments (brightness, contrast) in qview permanent such that they may be exportet?

Wow, I think can remember making something permanent but I don't think it was stretch values. I think I was able to change special pixels, null, his, lis, etc. to a value and then there was an option to save the changes.

I think there was a way of viewing the image and manually setting the stretch values but these were not saved. This would give you an idea of the results. But I just noted the final values and used the values manually in isis2std.

I can't remember if I ever did anything bigger than 6gb. Not sure. That's close though. Could be why I never had a problem? But I am pretty sure I didn't work with more than a band at a time. Multi band images were combined as a last step.

I think I also remember reading something at the ISIS forum that some qt libs want to load the entire image into ram during some program runs. So it may depend on how much ram your computer has.

A lot of the work I did on larger files was via scripts. This may be the reason I never had a problem. I think the qt libs are called when using the gui's? but not command line scripts?

cartrite


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

All times are UTC


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:  
Powered by phpBB® Forum Software © phpBB Group