null54

Done. Release version 1.3.6, which updates LibRaw to the 202403 snapshot.

I am waiting for version 1.0 to be released, that way I won't have to repeatedly update the plugin for the libjxl API changes. I have no plans to make a jpegli plugin.

That is not a DDS file, it seems to be encrypted or some other format entirely.

Do you have a crashlog?

Based on the text in that image, it looks like those files may be some kind of 3D rendering configuration for the model. But I don't know for sure.

It sounds like you may be using an older version of the plugin. Version 1.3.5 is working with Paint.NET 5.0.13.

Release version 1.1.31, which updates AOM to version 3.8.2.

Release version 3.3.5, which updates G'MIC to version 3.3.5.

I think the poster has a newer PSD file that the plugin does not yet support. There are quite a few other posts in this topic with the same error message, and it is highly unlikely that all of those files would be corrupt.

@Pixey The error is occurring due to the plugin not supporting that PSD file.

Yes, the portable versions do not have automatic updates.

The only difference between those two formats is the file header value used to identify it. ATI2 is one of the legacy names for BC5, which some applications require instead of the BC5U value that the BC5 (Linear, Unsigned) format uses.

Release version 3.3.4, which updates G'MIC to version 3.3.4.

The plugin works for me in PDN 5.0.12, what error message are you getting?

I already replied in the GitHub issue linked to above, but I will post here as well. This issue is due to a bug in Firefox's AVIF decoder, it does not support tiled/grid images. The tile size warning is a red herring, libavif (which is used by Chrome) has no issue decoding tiles that are not a multiple of 64, and it also also ignores the multiple of 64 recommendation when writing grid images. Even grid images which use a tile size that is a multiple of 64 will fail to open in Firefox, e.g. animals_00_multilayer_grid_a1lx.avif from the official AVIF test suite.

Zip it and upload it to an external file hosting service (Dropbox, Google Drive, etc), then post a link here.

Release version 1.1.30, which updates AOM to version 3.8.1.

Release version 1.0.12, which updates RIOT to version 2024.1.

Paint.NET does not natively support custom brushes, but the Dynamic Draw plugin can load most Photoshop Brushes. For Photoshop Shapes, you can use Photoshop or this online converter to convert them to SVG. The SVG file can then be imported into the ShapeMaker plugin and exported as a Paint.NET shape file.

@LooneyTunerIan You already created a new thread for your question. There is no need to also bump a 4 year old thread, see Forum Rule #11. Closed.

Could that also be used as a workaround for this issue? So that instead of calling PDN's IImagingFactory.CreateBitmap, I have my own IBitmap<TPixel> class that ensures the bitmap has the correct stride.

That would make sense. Microsoft's encoder is probably GPU accelerated, and Heic FileType Plus is using a software encoder (x265). Looking at Microsoft's documentation for their HEVC video encoder, it only supports 4:2:0 at 8-bits-per-channel. What are the dimensions of the image you are trying to save?

The MS Store HEIC plugin only supports Chroma Subsampling 4:2:0.

Copy to 8bf filter loop: https://github.com/0xC0000054/PSFilterPdn/blob/4066ed29118dfff69994361d38bc0a0a45cdcf7e/src/PSApi/LoadPsFilter.cs#L1788 ImageRow load method: https://github.com/0xC0000054/PSFilterPdn/blob/4066ed29118dfff69994361d38bc0a0a45cdcf7e/src/PSApi/ImageRow.cs#L41

That was a bug, but unfortunately not the cause of this issue. Padding is a Photoshop API feature that its filters can use to virtually extend the canvas by the requested number of pixels, it was presumably intended to make writing convolution filters easier. Instead of adjusting the algorithm to handle the image edges a filter developer could have the host extend the canvas by replicating those pixels for n rows/columns.