(patch proposition) nvcompress, DirectDrawSurface, adding support for DDPF_LUMINANCE

[GoogleCodeExporter]

This is patch against revision 1102 to add support for DDPF_LUMINANCE flag.

As described on this MSDN document
(http://msdn.microsoft.com/en-us/library/bb943991%28VS.85%29.aspx),
luminance images contain only the uncompressed 'red' channel.

I added a '-lumi' flag to the compressor to enable this.

This addition would allow nvcompress to handle more of the uncompressed
pixel formats available in DDS files, the changes are localised, and should
be break existing behaviour.

What do you think ?

Original issue reported on code.google.com by nicolas....@gtempaccount.com on 1 Jun 2010 at 12:52

Attachments:

• luminance.patch

[GoogleCodeExporter]

That looks good. It would also be good to have support for luminance/alpha 
images, but 
that can be left for a future patch.

Original comment by cast...@gmail.com on 1 Jun 2010 at 5:56

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Thanks, I thought too about 'luminance with alpha', and 'alpha only' images, 
but I 
don't have real-world test data for them, so I prefered to stay on my track. I 
note 
your request though, for some spare time :)

Original comment by nicolas....@gmail.com on 1 Jun 2010 at 6:22

[GoogleCodeExporter]

This issue was closed by revision r1104.

Original comment by cast...@gmail.com on 1 Jun 2010 at 7:05

• Changed state: Fixed

[GoogleCodeExporter]

Well, I modified your patch to simply set the alpha flag for both RGB and 
luminance 
images when the number of alpha bits is greater than zero. Hopefully that 
should just 
work.

Original comment by cast...@gmail.com on 1 Jun 2010 at 7:10

[GoogleCodeExporter]

Yes I saw that, that's what I had in mind, I also suppose it should just work.

Another change I thought about would be to properly tag images (read through 
formats
other than DDS) as Grey when possible. But I saw that you only have Format_RGB &
Format_ARGB for images.

Do you think this would imply some refactoring other that checking a new 
Format_Grey
enum value here and there ?

Also, more generally, do you prefer patches on 'trunk' or on the '2.0' branch ?

Original comment by nicolas....@gtempaccount.com on 2 Jun 2010 at 8:07

[GoogleCodeExporter]

That sounds good, but might require a bit of testing, since there are many 
different
image loaders.

For small patches the 2.0 branch is fine, but most of the development is now 
focused
in trunk towards the 2.1 release. A larger change like that would probably fit 
better
in trunk.

Original comment by cast...@gmail.com on 2 Jun 2010 at 8:20