 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here is a new feature request:
Reading the HiRISE format.
HiRISE
This special format is used by orbiting Mars probes, and has a fantastic
resolution, far better than any other topographic 3D format file that is
currently available for Martian surfaces.
POV-Ray
The HiRISE images can be used to create an accurate heightfield that is
also correctly textured. POV-Ray understands already various image
formats and knows how to sample pixel colors from given coordinates of
images. HiRISE is important to be understood by POV-Ray, the more as
POV-Ray is up to today the only render engine that was been used in
space by an astronaut on the ISS (and got special heat-avoiding features
by its developers). Let's continue to make POV-Ray a render engine for
the future.
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.06.2018 um 02:48 schrieb Sven Littkowski:
> Here is a new feature request:
>
> Reading the HiRISE format.
>
> HiRISE
> This special format is used by orbiting Mars probes, and has a fantastic
> resolution, far better than any other topographic 3D format file that is
> currently available for Martian surfaces.
>
> POV-Ray
> The HiRISE images can be used to create an accurate heightfield that is
> also correctly textured.
Um... no, they can't.
- The HiRISE images are just that: Images. The spacecraft /per se/ does
not make measurements of topography.
- The HiRISE camera takes images in the ~500 nm, ~700 nm and ~900 nm
bands; that's blue-green, red, and infrared. That's /not/ RGB and
therefore /cannot/ capture the true surface colour.
I guess what you mean are HiRISE DTM (Digital Terrain Models)
/generated/ from the HiRISE data proper. From what I could find, the DTM
format is a "32-bit [...] PDS standard raster file format."
If you really want this to be implemented, you can help a lot by digging
on the internet for a detailed description of the file format;
unfortunately I don't have the time for that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16-6-2018 9:58, clipka wrote:
> I guess what you mean are HiRISE DTM (Digital Terrain Models)
> /generated/ from the HiRISE data proper. From what I could find, the DTM
> format is a "32-bit [...] PDS standard raster file format."
>
> If you really want this to be implemented, you can help a lot by digging
> on the internet for a detailed description of the file format;
> unfortunately I don't have the time for that.
>
I remember that, more than 20 years ago, I modelled height_fields
derived form DEM (Digital Elevation Model) GIS data I got from the USGS.
The data had to be converted first using an application provided by
USGS, iirc.
It seems that DTM is also GIS-based; see for instance:
https://gisgeography.com/dem-dsm-dtm-differences/
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degroot org> wrote:
> I remember that, more than 20 years ago, I modelled height_fields
> derived form DEM (Digital Elevation Model) GIS data I got from the USGS.
> The data had to be converted first using an application provided by
> USGS, iirc.
I've tried to dabble a bit with it, with mixed success.
There are too many data formats, and too little exaplanatory text for
identifying what they are, and not enough short, clear, concise documentation
for loading the data into software so it can be used.
It's all very confusing.
Apparently Christoph Hormann is a bit of a wizard with this stuff. Perhaps if
he still visits here, he could chime in with some advice.
I have GRASS GIS 7.0.4 and OSGeo4W, which I suppose is what I used to get the
heightfield data for the New River bridge WIP I did a while back.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/06/2018 19:12, Bald Eagle wrote:
> I've tried to dabble a bit with it, with mixed success.
I didn't even get the mixed success.
> There are too many data formats, and too little exaplanatory text for
> identifying what they are, and not enough short, clear, concise documentation
> for loading the data into software so it can be used.
What I remember about it. Was that it involved a fair bit of converting
formats a couple of times in different programs.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
From: Sven Littkowski
Subject: Re: FEATURE REQUEST: Reading HiRISE Format
Date: 16 Jun 2018 15:56:43
Message: <5b256b7b@news.povray.org>
|
|
|
| |
| |
|
|
I will try to get information on HiRISE DTM, and also try to contact ESA
and NASA. On previous contact attempts (not related to the file format
structure), however, I never got any answer from both organizations.
I will do my best!
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This might be useful. Explanations (pages 14 and following):
https://hirise.lpl.arizona.edu/pdf/HiRISE_RDR_v12_DTM_11_25_2009.pdf
Besides that, I contacted Jet Propulsion Laboratory and the University
of Arizona and wait now for their answers.
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I got today the first answer in regards to the internal structure of the
HiRISE DTM format (I believe), the University of Arizona sends me this link
:
https://www.uahirise.org/specs/
I am still waiting for more answers.
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
