John J Scott

Thanks all! It's validating a filetype plugin for hardware compressed textures. In C++: 1. Load in PNG 2. Compress to BC1 (aka DXT1) 3. Save as DDS 4. Save in my custom format. 5. Load my custom format and make sure it's the same (including all mips) 6. Decompress DDS with DirectXTex and save as PNG In C#: 1. Load DDS 2. Load my custom format in C# and make sure it's the same 3. Decompress custom format to BGRA as part of the filetype plugin 4. Compare my BGRA to the decompressed PNG to make sure they are the same. Similar process with ETC, but using KTX images not DDS. ASTC and PVRTC are on the radar, but that's about it. All this is external to Paint.NET - I just use it as my viewer. As such, I don't have access to services for IPngFileType. Even if I had a Document, I seem to need to set each pixel individually, which seems inefficient BitmapLayer layer = ( BitmapLayer )document.Layers[ 0 ]; for( int32 x = 0; x < layer.Width; x++ ) { for( int32 y = 0; y < layer.Height; y++ ) { reference_bgra[x + ( y * layer.Width)] = ( int32 )layer.Surface[x, y].Bgra; } } In the end, I opted for LoadFromWICFile: private static int32[] LoadPNGImage( string fullPNGPath ) { ScratchImage scratch_image = TexHelper.Instance.LoadFromWICFile( fullPNGPath + ".png", WIC_FLAGS.NONE ); Image image = scratch_image.GetImage( 0 ); int32[] reference_bgra = new int32[image.Width * image.Height]; Marshal.Copy( image.Pixels, reference_bgra, 0, image.Width * image.Height ); return reference_bgra; } I'm all ears for better approaches Cheers John

I added System.Drawing.Common as a dependency to my project so I could load PNG files. However, this causes loading my Paint.NET filetype plugin to crash with a System.ExecutionEngineException exception. (Net7-Windows) I suspect there's a clash between System.Drawing.Common for Net7 and System.Drawing for Net4.8. What is the preferred way to load a PNG file in Net7? There seem to be several third party libraries, but a recommendation from the horses mouth would be a great place to start without following several dead ends. Can the Paint.NET API be leveraged to do this simply? Cheers John

The latest Paint.Net release on December 1st to 5.0.12 made the problem go away. Well, until Microsoft repeat the problem anyway. Cheers John

Probably - just looking for a workaround from a responsive team. No replies from MS as yet. They are not in source control, just referenced by the csproj files and VS makes a local copy for reasons that are known only to Microsoft. The only limitation with this is that Paint.NET needs to be installed to the default location ("C:\Program Files\paint.net") for that 'just works out of the box' experience. Cheers John

I've written a container format for compressed texture formats used in graphics hardware (think DDS format but with extra features). Part of the suite is that these can be loaded directly into Paint.NET for viewing. The general test process in C++ is: Load PNG Add mip maps, convert to a compressed texture format (e.g. BC1/DXT1), and save as DDS. Convert to my format and save. Load in my format and make sure it matches the DDS. Then the test process in C#: Load PNG Load my format version Use the Paint.NET file type code to decompress my format to RGBA and make sure it matches the PNG. As I've been working on this for a while, I tend to be a bit too succinct 😃 Is that a suitable explanation? Cheers John

The error:"The active test run was aborted. Reason: Test host process crashed : Process terminated. MVID mismatch between loaded assembly 'System.Private.Xml' (MVID = {4007EC53-119A-4580-9B7F-C8A4BBCDB0E0}) and version of assembly 'System.Private.Xml' expected by assembly 'PaintDotNet.Data' (MVID = {405DEE27-471D-48E3-8C64-1D8278CF1FDD})" I'm not sure whether this is a problem for Paint.NET or Microsoft, but finding a workaround on these forums seems plausible. Unit tests have been working fine for a long time, but yesterday I updated Visual Studio 2022 to the latest version, and apparently this updated the Xml assembly used in the test adapter to a different one that is used in Paint.NET. (That's how I'm reading it anyway). Why this crashes is anybody's guess. I speculate that a recompile of Paint.NET would fix the issue? In the meantime, is there a workaround? Some form of assembly forwarding? Is there a way to make Paint.NET (or MS test adapter for that matter) less strict on the required assemblies? Cheers John