Author Topic: 32-bit channels in jpeg 2000  (Read 18287 times)

Offline lwmusings

  • Pixlet
  • *
  • Posts: 17
  • infiniMap User
32-bit channels in jpeg 2000
« on: February 07, 2008, 04:38:06 AM »
I notice 16-bit has been asked for in the other thread. What can I say 32-bit would be even better for the same reason. When using infinimap for high resolution displacement maps. For example when pulling in a DEM file into lightwave via Marvin Landis's DEM imported the images come in at 32-bit resolution. It would be nice to even just be able to store those massive DEMs as a 32-bit greyscale jp2.

On the subject of a custom displacement plugin that would make better use of the scalabilty, that would be awesome. Although I think in the situations I'm looking at, even if it can currently discard the image information for parts that are entirely off screen it would be awesome.

Offline lightwolf

  • infiniMap / exrTrader / shaderMeister developer
  • Administrator
  • Tera Pixel Renderer
  • *****
  • Posts: 1556
  • Obfuscated SDK Hacker
    • db&w GbR
Re: 32-bit channels in jpeg 2000
« Reply #1 on: February 07, 2008, 03:29:08 PM »
I notice 16-bit has been asked for in the other thread. What can I say 32-bit would be even better for the same reason. When using infinimap for high resolution displacement maps. For example when pulling in a DEM file into lightwave via Marvin Landis's DEM imported the images come in at 32-bit resolution. It would be nice to even just be able to store those massive DEMs as a 32-bit greyscale jp2.
We've got something coming up. Not using JPEG2000 though (the library we use is limited to roughly 28 bit or so anyhow).
On the subject of a custom displacement plugin that would make better use of the scalabilty, that would be awesome. Although I think in the situations I'm looking at, even if it can currently discard the image information for parts that are entirely off screen it would be awesome.
I keep thinking about it. The problem is it would need to work hand in hand with the subdivision in LW - the amount of subdivision would need to adapt to the amount of displacement - ans that isn't really possible at the moment.

Cheers,
Mike
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)

skype: lupus_lux
Visit us on facebook: http://www.facebook.com/dbw.finest.plugins

Offline lwmusings

  • Pixlet
  • *
  • Posts: 17
  • infiniMap User
Re: 32-bit channels in jpeg 2000
« Reply #2 on: February 11, 2008, 08:37:15 PM »
Quote
I notice 16-bit has been asked for in the other thread. What can I say 32-bit would be even better for the same reason. When using infinimap for high resolution displacement maps. For example when pulling in a DEM file into lightwave via Marvin Landis's DEM imported the images come in at 32-bit resolution. It would be nice to even just be able to store those massive DEMs as a 32-bit greyscale jp2.

Interesting, 28-bit. That would seem like the other 4 bits are doing something because if your using a float or a double aren't those by nature 32-bit or 64-bit in a 64-bit system? (Just pondering on the matter with my limited C++ experience)

Quote
On the subject of a custom displacement plugin that would make better use of the scalabilty, that would be awesome. Although I think in the situations I'm looking at, even if it can currently discard the image information for parts that are entirely off screen it would be awesome.

So here's the question. I'll try to verify it with some tests, but might as well ask too  :). If I understand correctly even with the current infinimap there is some advantage to using displacement maps through infinimap because it disregards information outside of the camera's view. For example if you are zoomed in on just a section of terrain that is part of a much larger terrain.

If such is the case the  limitation in my eyes  is that 8-bits does not create a very smooth displacement, especially in the arena of DEM files which band considerably when reduced to 8-bit. The adjusting resolution of the images for displacement isn't as critical if it can at least not load the parts of the displacement image that are not visible to the camera.





Offline lightwolf

  • infiniMap / exrTrader / shaderMeister developer
  • Administrator
  • Tera Pixel Renderer
  • *****
  • Posts: 1556
  • Obfuscated SDK Hacker
    • db&w GbR
Re: 32-bit channels in jpeg 2000
« Reply #3 on: February 11, 2008, 09:39:21 PM »
Interesting, 28-bit. That would seem like the other 4 bits are doing something because if your using a float or a double aren't those by nature 32-bit or 64-bit in a 64-bit system? (Just pondering on the matter with my limited C++ experience)
floats are 32bit, doubles 64bit regardless of the system (32vs. 64bit).
As for the 28 bit limit, that is apparently inherent to the SDK we use. Also, JPEG 2000 can use a variable number of bits and isn't limited to 8, 16 or 32 (per component).
So here's the question. I'll try to verify it with some tests, but might as well ask too  :). If I understand correctly even with the current infinimap there is some advantage to using displacement maps through infinimap because it disregards information outside of the camera's view. For example if you are zoomed in on just a section of terrain that is part of a much larger terrain.
Actually it doesn't ... because that information may still show up in a reflection for example.
Which also means... if LW queries an infiniMap image for displacements it will always get a decent value, whether within the camera view or not.
It would be up to the displacement to decide if it actually needs a value or not.
In the case of terrain, the mesh subdivision, displacement and height map evaluation have to work hand in hand - that would be possible in LW but would also require a custom plugin.
If such is the case the  limitation in my eyes  is that 8-bits does not create a very smooth displacement, especially in the arena of DEM files which band considerably when reduced to 8-bit. The adjusting resolution of the images for displacement isn't as critical if it can at least not load the parts of the displacement image that are not visible to the camera.
DEMs are usually 16bit integers, which is enough to store roughly 32k different values half that if you allow for negative numbers). In general DEMs use integers, no floats.

I've got some ideas on rendering terrain within LW - especially since infiniMap doesn't handle that case adequatly at all (as I said, subdivision/displacement/elevation evaluation need to work together tightly for it to work as expected).

What you can do to fake it is parent a manually subdivided mesh to the camera (more subdivisions closer to the camera, less further away) and push it through a world coordinate projected infiniMap elevation image used to displace it. (does that makes sense?)

Cheers,
Mike
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)

skype: lupus_lux
Visit us on facebook: http://www.facebook.com/dbw.finest.plugins

 

anything