DDS file reader/writer...

[Hradec]

I'm thinking on add a dds reader/writer to cortex... As I'm using
cortex more and more here at Radical in our game pipeline, I realize
that would be so much better to have a native way to read and write
our textures.

I think it would be a good starting point for me to get my head around
the C++ code and start to contribute back to the project.

Also, as DDS is a hardware aware texture compression, meaning that the
texture stays compressed in memory and the GPU is able to work with it
compressed, its a huge gain in GPU memory management, which I think
would be extremely beneficial regarding IECoreGL.

For example, instead of storing an EXR buffer in an uncompressed RGBA
buffer, one would be able to convet on the fly to an RGBE DXT5 DDS
buffer, which would allow for almost the same high dinamic range
visual feedback in a fraction of the memory space, at the cost of a
few and small artifacts.

So my question is: is that something would interest you guys? Can I
start work on it?

PS: I'm also planning on add FBX read/write support on cortex, but I
think DDS would be way simpler for me, specially because I have a lot
of resources around me here at radical. I'll leave FBX for later.

[John Haddon]

Hi Roberto,

That sounds interesting. I don't know much about this DDS format but it
sounds useful. In terms of integrating it into IECore I presume the
loader would return an IECoreGL::Texture? I'm guessing there's no point
in returning an IECore::ImagePrimitive as then you've done a load of
unecessary decompression which should be happening on the graphics card
anyway. Is that right? That would mean that you couldn't derive from
IECore::Reader as they always return IECore::Objects, so I imagine the
DDSReader would be more of a standalone class in IECoreGL. What about
writing? Are you envisaging a DDSWriter which takes an ImagePrimitive
and performs the compression before writing to disk? That class could
derive from IECore::Writer I think.

Like I said I don't know much about this subject but if we can figure
out where it fits into Cortex then i'd love to see it...

Cheers...
John

[Hradec]

Reader:

DDS has a bunch of different compression formats, all of then
supported by GPU hardware decode. BUT, theres also uncompressed format
as well... you can store up to 4 channels of 32bit float uncompressed.
So, in theory, if the DDS stores uncompressed data, you could read it
to an ImagePrimitive....

So, I'm not sure... I suppose makes more sense to return an
IECoreGL::Texture by default, but would be also interesting to be able
to convert IECoreGL::Texture to ImagePrimitive after reading, if
necessary... in this case, a Conversor could take care of
uncompressing the data on the fly, if necessary...

What about derive IECoreGL::Texture to a IECoreGL:DDSTexture class,
and then I could add a toImagePrimitive method ?

Using this DDSTexture class approach would also be interesting to do
DDS compression on the fly straight from an ImagePrimitive buffer
without having to rely on dds files. I think this can be really
usefull, specially in film to "squeeze" more EXR textures into GPU
memory!

Writer:

My idea was exact that... derive from IECore::Writer and take an
ImagePrimitive as input.


My plan:

I think I'll start with an DDSTexture backend class that will provide
all the functionality to IECoreGL::DDSTexture, Reader and Writer.

what do you think?

[Dan Bethell]

Fwiw I noticed this subject discussed recently over on the OIIO list
too.
http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2009-November/002059.html

As an aside, have there been any thoughts for/against using OIIO as
the image i/o backend in cortex?

[John Haddon]

Dan Bethell wrote:
> As an aside, have there been any thoughts for/against using OIIO as
> the image i/o backend in cortex?
>

I've only briefly looked at the OIIO stuff, but my initial impression is
that it's superior to what we have in cortex. The cortex ImageReaders
are pretty much geared to loading whole images at a time, whereas OIIO
seems to be much better in terms of maintaining a cache of recently
requested tiles etc. On the other hand, what we have suits Image
Engine's needs reasonably well for the moment so we don't have any plans
to rejig things ourselves just yet - but maybe someone else is
interested in having a look?
Cheers...
John

[Hradec]

I'm geared towards add DDS support to cortex... so I'll have a look at OIIO and see... if they have it working already, maybe would be the same amount of work to integrate OIIO to cortex, instead of just adding DDS support... if so, I could do it...

--
You received this message because you are subscribed to the "cortexdev" group.
To post to this group, send email to cort...@googlegroups.com
To unsubscribe from this group, send email to cortexdev-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cortexdev?hl=en

--
Hradec
Sent from Vancouver, BC, Canada