null54

Paint.NET was not a community developed project it is Rick's project that he made source code available for. Unfortunately as @Ego Eram Reputo mentioned certain individuals would publish rip-offs ('backspaceware'), see the following posts on the Paint.NET blog. https://blog.getpaint.net/2007/12/04/freeware-authors-beware-of-“backspaceware”/ https://blog.getpaint.net/2009/11/06/a-new-license-for-paintnet-v35/

It may be a caching issue on my end, but the download link for the classic version on the Paint.NET homepage still says 4.0.17.

Added. After thinking about it some more, I am not convinced that arbitrarily disabling plugin functionality based on the type of Paint.NET install is a good idea. My original reasoning was that allowing the user to add search directories would not make sense as there is no guarantee that two systems would have the same folders, but the current "portable" installs already have that issue and if a folder does not exist or gets deleted when the effect is executing my code would still have to handle that case (to quote Raymond Chen "You just have to accept that the file system can change"). Another reason was to reduce the number of writes to disk if the Paint.NET User Files is stored on a flash drive. The reason I compile against 3.5.x is that I do not want to prevent users on older OSes from using my plugins, and supporting multiple versions is too much work. The DX10 DDS file type only supports 4.0.17 and later.

The site is down, but the Internet Archive has saved a copy of the plugin. https://web.archive.org/web/20130309145843/http://pgciarlo.interfree.it/Plugins/PowerStretch10.zip Perhaps one of the Mods could attach it to the first post and remove the broken links.

This is a hack that is probably not relevant to 99% of plugins, but it may be useful for plugins that allow the user to select folders containing brushes or other data files outside of the Paint.NET User Files. I wanted to have a way to disable the selection of external plugin folders in PSFilterPdn when Paint.NET is running in portable mode. To maintain compatibility with 3.5.11 the following code reads the value of the IAppInfoService InstallMode property via Reflection. There probably is a better way to detect portable mode when referencing the 3.5.11 DLLs, but if there is I have not found it.

Allow creating mipmaps for image sizes that are not a power of 2. The mipmap generation had been silently ignoring images that are not a power of 2 until I came across the following post (strangely the DDS reference on MSDN makes no mention that non power of 2 mipmaps are supported). Report progress when saving the uncompressed formats. File version updated to 1.6.0.0.

Added support for saving the R8G8B8A8 and B4G4R4A4 formats. File version updated to 1.5.0.0.

Paint.NET should preserve all the metadata it receives when the file is loaded. The JPEG loading and saving uses the GDI+ library that is built-in to Windows. Paint.NET does not have any control over what it does with metadata when an image is loaded or saved.

If the load time is 45 to 75 seconds then it sounds to me like disk I/O may be a big part of the issue. Perhaps the list of 8bf filters should be stored in the EffectConfigToken, at least that way it only scans the disk the first time it is opened. Or the filter information could be serialized to disk and used across Paint.NET sessions, this is what GIMP's PSPI plugin does. I never anticipated PSFilterPdn would be used with that many filters. I am surprised that the Windows Forms TreeView works with that many items. Regarding your pull request, I am surprised that the TreeView sorting is such a bottleneck. I have not decided if I will be merging it, accepting 3rd party contributions would restrict me from changing to a different open source license.

The search speed would depend on the number of folders in the Search Directories tab and the number of 8bf files located in those folders. That would not surprise me. Each time PSFilterPdn is launched it searches the folders and gathers the information it needs from every 8bf file it finds.

No, it is not. Rick is stating that the UI thread is one of the threads that uses STA mode and that any clipboard access must be performed from a STA thread. In the example I posted the SetClipboardImage method creates a new STA thread when it accesses the clipboard. The following line configures the thread to use STA mode. t.SetApartmentState(System.Threading.ApartmentState.STA);

Even if you set the SingleThreaded flag your Render method will be called multiple times.

Added support for loading Unreal Engine 2.5 DDS files that only set the dwFourCC field in the DDS_PIXELFORMAT structure, see the following thread for details. Convert the sRGB formats to linear RGB when loading. Reduced memory usage when saving. File version updated to 1.4.0.0.

bool firstRun = true; void Render(Surface dst, Surface src, Rectangle rect) { if (firstRun) { SetClipboardImage(src.CreateAliasedBitmap()); firstRun = false; } ColorBgra CurrentPixel; for (int y = rect.Top; y < rect.Bottom; y++) { if (IsCancelRequested) return; for (int x = rect.Left; x < rect.Right; x++) { CurrentPixel = src[x,y]; dst[x,y] = CurrentPixel; } } } void SetClipboardImage(Bitmap bitmap) { try { // Accessing the clipboard requires STA apartment state. System.Threading.Thread t = new System.Threading.Thread(() => Clipboard.SetData(DataFormats.Bitmap, bitmap)); t.SetApartmentState(System.Threading.ApartmentState.STA); t.Start(); t.Join(); } catch { } } Note that this method will not preserve transparency.

Improved error handling when loading DDS files. Added support for planar and typeless DDS formats. Fixed a conversion bug when saving the X8R8G8B8, A1R5G5B5 and R5G6B5 formats. File version updated to 1.3.0.0.

Interesting link. I did not notice any quality difference during my testing, but I was using photographs instead of game textures. One thing I did notice is that the DirectCompute based BC7/BC6H encoder is significantly faster than the software encoder. The software encoder processes a 1024x768 image in around 25 seconds, the DirectCompute encoder processes the same image in around 5 seconds.

Corrected the name of the 32-bit DLL in the P/Invoke signatures. Changed the 32-bit DLL to use SSE instead of of SSE2. File version updated to 1.2.1.0.

Added support for saving the BC6H compressed format (RGB, 16-bit floating point). Show progress when saving. File version updated to 1.2.0.0.

Significantly improved the performance when saving the BC7 format by using DirectCompute when it is available. File version updated to 1.1.0.0.

See the following post on the Paint.NET blog for details on the portable mode in 4.0.17. https://blog.getpaint.net/2017/07/21/portable-mode-in-paint-net-4-0-17/

Paint.NET has had built-in support for DDS since the 3.10 release in 2007 (based on a plugin written by @Dean Ashton). This plugin only adds support for the new formats introduced with DirectX 10.

A DDS FileType plugin that allows Paint.NET to open and save the the some of formats introduced in DirectX 10 and later. Compatibility: Paint.NET 5.0+. This plugin is bundled with Paint.NET 4.2.2 and later. If you need the features from a newer version you can still install the plugin. The plugin will override the bundled version if it has higher version number. The supported formats include the BC1 (DXT1), BC2 (DXT3), BC3 (DXT5), BC4, BC5, BC6H and BC7 compressed formats and the A8R8G8B8, X8R8G8B8, A8B8G8R8, X8B8G8R8, A1R5G5B5, A4R4G4B4, R5G6B5, R8G8B8, R32 Float, L8, A8L8 and V8U8 uncompressed formats. Note that the BC6H and BC7 compression may be slow on large images. Cube maps must use the horizontal or vertical cross layout, see the Cube Maps page on GitHub for more information. Installation: 1. Close Paint.NET. 2. Place DdsFileTypePlus.dll, DdsFileTypePlusIO_ARM64.dll and DdsFileTypePlusIO_x64.dll in the Paint.NET FileTypes folder which is usually located in one the following locations depending on the Paint.NET version you have installed. Classic: C:\Program Files\Paint.NET\FileTypes Microsoft Store: Documents\paint.net App Files\FileTypes Portable: <Paint.NET folder>\FileTypes 3. Restart Paint.NET. Download: DDSFileTypePlus.zip Source Code: https://github.com/0xC0000054/pdn-ddsfiletype-plus

I was able to load one of the X100F RAW samples from http://www.photographyblog.com/previews/fujifilm_x100f_photos/ using dcraw 9.27, but the image appeared darker than the sample images on the same page possibly due to dcraw not having color data for the X100F. You could use the Adobe DNG Converter to convert your X100F raw images to DNG which is supported by dcraw.

You have to download the plugin from the following thread.

Use static linking to remove the Visual C++ runtime dependency for the EA Fsh, JPEG 2000 and WebP filetypes. Update the installer to use @BoltBait's latest version, the new features are detailed in the following quote.