DDS: unsupported fourcc

[Krakean]

System.ArgumentException: FourCC: 808540228 not supported.
at Pfim.Dds.Create(Stream stream) in d:_GIT\Csharp-nices\Pfim\src\Pfim\dds\Dds.cs:line 94

and

System.ArgumentException: FourCC: 111 not supported.
at Pfim.Dds.Create(Stream stream) in d:_GIT\Csharp-nices\Pfim\src\Pfim\dds\Dds.cs:line 94

Files (a lot): https://nofile.io/f/cXYHORMfcVq/fourcc.rar

[Krakean]

@nickbabcock
Good progress on issues solving! :)
Curious, what you can say about #15? Have you look into it?
There is some formats withih archive that even internal Total Commander viewer can't support (using 'imagine', for example), so curious whether you could make them work in Pfim...
Also, curious, will you release new version with tga/dds fixes with, may be, updated benchmarks*?
About benchmark. Can you please note in your webpage, in benchmark section:
a) Whats versions of libraries are used
b) Make a note somewhere - what is better - lower throughput or higher.

[nickbabcock]

A 111 FourCC is a legacy format. While a robust DDS reader would support legacy formats, it's not high on my priority list.

I'm currently looking into supporting 808540228 (DX10) images. I have realized that a lot of the DX10 formats don't have analogous formats in WinForms. This means that while Pfim could decode these formats, it'd be up to the client to convert the format that can be meaningfully used, as Pfim is frontend and backend agnostic. I've made the WinForms sample viewer show a messagebox when a non-supported format is encountered.

I'll update Pfim to 0.5 when I get through enough of the DDS files. I'm unsure if 0.5 will contain DX10 DDS files or BC6/7. It depends on the amount of work needed.

After 0.5 is released I'll update the benchmarks with your suggestions.

[Krakean]

@nickbabcock

This means that while Pfim could decode these formats, it'd be up to the client to convert the format that can be meaningfully used, as Pfim is frontend and backend agnostic. I've made the WinForms sample viewer show a messagebox when a non-supported format is encountered.

Curious, what if you will rewrite your WinForms example to WPF? It uses DX11 (since .NET 4.6, if I remember correctly). So I suppose any image that DX10/DX11-hardware is support will be rendered in Wpf picturebox.

[nickbabcock]

Curious, what if you will rewrite your WinForms example to WPF?

There are two example projects, one in WinForms (the default) and one in WPF (hasn't been updated to support the latest formats). The WPF project uses PixelFormats (instead of WinForm's PixelFormat), but it runs into the same problems. Every dds encoding isn't represented, so it'll be up to the client to convert into another compatible format. That said, it should be possible allow the user to opt in to convert any format to rgba32 / 64 at the cost of performance

[Krakean]

@nickbabcock
Oh, I see. Got it. Thanks for your work on Pfim.
Also, just in case, https://nofile.io/f/8ouBDtJOySg/DDSFileExamples.7z - there is 117 different dds files for you to test Pfim :)
Most of them you already have I suppose, since I used them in dds bug reports.
Same for tga - https://nofile.io/f/SoeZFCYWkGe/TGAFileExamples.7z

After 0.5 is released I'll update the benchmarks with your suggestions.

And, I suppose, after bunch of fixes and some formats support enhancements, it should be v1.0, not v0.5 :)

[Krakean]

@nickbabcock

but it runs into the same problems.

Then, if WPF is not an option... Well, may be this suggestion will be kinda "overkill", but since your library will be used for gamedev purposes for sure, I suggest you take a look to this repo - https://github.com/EnoughTea/dades/ - specifically take a look please on DadesOglExample which uses OpenGL to display dds as textures.
You can just take code of this example, clean unneded shit out, and adapt it to Pfim as new example, besides WinForms/Wpf?

[nickbabcock]

And, I suppose, after bunch of fixes and some formats support enhancements, it should be v1.0, not v0.5

Maybe. Ideally, I'd like there to be time to grow confidence. To me, 1.0 kinda signifies a proven product, yet I believe there will always be gaps in Pfim (from someone's perspective). By committing to a v1.0, I'm committing to not breaking the API. Adding another variant to the ImageFormat is considered a breaking change. We'd be up to Pfim v8.0 by now ^{(is that even a bad thing?)} .

You can just take code of this example, clean unneded shit out, and adapt it to Pfim as new example, besides WinForms/Wpf?

Yeah it's very possible to create additional example projects (eg. create a webserver to display tga and dds images in the browser). But I'm not looking to flesh out fully featured tga and dds image viewers across all platforms 😄

[Krakean]

@nickbabcock
Its not about all platforms. Just Windows solution based on OGL. If someone want - he will recompile it easily to OSX under .NET Core, its not a problem. Main purpose - to be able to see how fast (and how much memory its consume) pfim is when working with API like OGL (or DirectX, whatever is easier, but in case of OGL - most of code is already written for you in DadesOglExample) in scenario most closely to game-like behaviour (loading times and memory consumption is too vary between WinForms & OGL -- especially check on BigUnitsA_HQ.dds from my archive), besides WinForms example which is more closely to "picture viewer for Windows" scenario.
Just my two cents :)

P.S. Plus it will be easier/handy to test - no need to depend on what pixel formats WinForms is support, it all be on videocard support, which is support a much more formats than WinForms can display.

[nickbabcock]

I've released Pfim 0.5. Still left to be done:

• BC 6/7 DDS
• DX10 DDS
• Improved colormap abstraction

Since I don't have an estimate on these features, I decided to get a version out the door, as it contains important bug fixes too 👌

[Krakean]

Nice! Congrats with release! Looking forward to these todos :)

…

On Mar 18, 2018, 17:36, at 17:36, Nick Babcock ***@***.***> wrote: I've released Pfim 0.5. Still left to be done: - BC 6/7 DDS - DX10 DDS - Improved colormap abstraction Since I don't have an estimate on these features, I decided to get a version out the door, as it contains important bug fixes too 👌 -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #15 (comment)

[Krakean]

@nickbabcock
https://github.com/Microsoft/DirectXTex
Just in case, may be it will save you some time. DDS implementation from Microsoft (in C++, though), with BC1-7 implementation, SRGB/HDR support, and all other things related to DDS.

[nickbabcock]

I'm working out color spaces. UNORM is great, it maps directly to the WinForms Bitmap class. I was investigating sRGB files and looking into how to incorporate them. The official Data Conversion Rules didn't give too much help. DirectXTex uses a DirectXMath function, which uses a series of matrix / vector operations to convert sRGB to RGB. I could write these operations by hand, but it'd be slow and may take a couple iterations for correctness. The other option would be to incorporate something like Math.NET, but that seems like a rather large dependency for sRGB to RGB conversion 🤔

Just thought I'd give an update.

[Krakean]

@nickbabcock

I could write these operations by hand, but it'd be slow and may take a couple iterations for correctness. The other option would be to incorporate something like Math.NET, but that seems like a rather large dependency for sRGB to RGB conversion

Yeah, Math.Net would be surplus.
But, what if you implement some kind of "math interface"?
I.e. like a IPfimMath, with some matrix/vector methods that you need. And your implementation (for tests/demos, for example) of this interface.
So, developer can provide his own implementation for math functions that Pfim require in case if he didn't satisfied with your implementation.
What you think about this idea?

Just thought I'd give an update.

Thanks for letting know!

P.S. Hope to see BC7 support :)

[nickbabcock]

But, what if you implement some kind of "math interface"?

I hadn't thought about that before. I think that is a good idea. I'll need to track all the performance sensitive math operations and see what needs to be extracted!

P.S. Hope to see BC7 support :)

DX10 is turning out more complicated than I thought 😆

[nickbabcock]

Closing this in favor of the main thread on BC6/BC7: #16