frio

The Tweak Transprency plugin is a fairly bread&butter plugin for my uses, and using it with 0 blur but adjusting the min/max transprency values has very useful effects. I know I could achieve similar results with the Curves+ adjustment with alpha channel only, but you know, once you get used to a workflow and something seems amiss and happens in other places too...

Some blur effects cause a misplaced, garbled 16 pixel tall slice of the image to appear overlapping the top area of the image when used with 0 strength, instead just leaving the unblurred image in place. Where the garbled pixels come from changes often between different preview renders and the final render. The effects have other meaningful uses even when used with 0 blur strength. I think this may be a bug in PDN itself since it reproduces in effects by different authors from many years apart, maybe they call some kind of a built-in blur function? It did not happen before version 5.0. Plugins I've found to be affected are Gaussian Blur+ by BoltBait and Tweak Transparency v2 (and v1, which is apparently no longer available for download) by Red Ochre. Steps to reproduce: make any image of any size with enough distinct areas, a diagonal gradiant is fine. Apply one of the above effects at strength 0. Curtailed system info:

If I resize the window, the buttons stay overlapped exactly the same way, they don't adjust their relative layout along the size change. As for Win10... nah, I'm good until something absolutely mandatory starts requiring it -- yes, I've heard all arguments for updating to Win10 and they make sense, I don't want to get into the discussion why I still don't want to. A "sorry, just not supported anymore" is enough. Paint.NET is one of those absolutely mandatory things so... no rush making it Win10+ only if you ask me.

The OK button is mostly hidden behind the Cancel button, but both can still be clicked fine so it's more a nuisance than a deal breaker. Happens for both jpg and png options dialogs while saving. I know Windows 7 isn't supported anymore, but the buttons were placed just fine in the previous version. I use 125% DPI in Windows display settings (120 ppi); disabling DPI scaling for paint.net in compatibility options has no effect.

Tested, saves the files it used to previously stumble on with autodetect. Thanks! (And I have to take this opportunity to add: thanks for all these ~15 years paint.net has been an indispensable tool for my purposes, over all kinds of Photoshops and what have you.)

This can be reproduced as follows: make a transparent image and paint on it with < 256 colors without antialiasing, ensuring 1-bit transparency depth. If there is partial transparency or the number of colors is sufficiently high, this exception does not occur. Attached is an image that's been saved as 32-bit, trying to resave it as autodetect fails. Exception: System.ArgumentException: palette colors must be opaque (A=255), although 1 transparent color as the last entry is permitted at PaintDotNet.Imaging.PaletteMap..ctor(IEnumerable`1 colors) in D:\src\pdn\src\Framework\Imaging\PaletteMap.cs:line 27 at PaintDotNet.Imaging.ProximityPaletteMap..ctor(IEnumerable`1 palette) in D:\src\pdn\src\Framework\Imaging\ProximityPaletteMap.cs:line 46 at PaintDotNet.Data.WicFileTypeHelpers.Save(IBitmapSource`1 sourceBgra32, Vector2Double dpi, Metadata metadata, Stream output, ContainerFormat containerFormat, Nullable`1 preferredVendor, IMetadataTranscoder metadataTranscoder, IEnumerable`1 encoderOptions, SavableBitDepths bitDepth, IReadOnlyList`1 paletteForIndexed, Int32 ditherLevelForIndexed, ProgressEventHandler progressCallback, Object progressCallbackSender) in D:\src\pdn\src\PaintDotNet\Data\WicFileTypeHelpers.cs:line 290 at PaintDotNet.Data.PngFileType.OnFinalSave(Document input, Stream output, Surface flattenedImage, SavableBitDepths bitDepth, IReadOnlyList`1 paletteColors, Int32 ditherLevel, PropertyBasedSaveConfigToken token, ProgressEventHandler progressCallback) in D:\src\pdn\src\PaintDotNet\Data\PngFileType.cs:line 263 at PaintDotNet.Data.InternalFileType.FinalSave(Document input, Stream output, Surface scratchSurface, SavableBitDepths bitDepth, QuantizationAlgorithm quantizationAlgorithm, Int32 alphaThreshold, Int32 ditherLevel, ImageColorsAnalysis analysis, PropertyBasedSaveConfigToken token, ProgressEventHandler progressCallback, Double progressStart, Double progressEnd) in D:\src\pdn\src\PaintDotNet\Data\InternalFileType.cs:line 510 at PaintDotNet.Data.InternalFileType.GetSavableBitDepthFileLength(SavableBitDepths bitDepth, Document input, Surface scratchSurface, QuantizationAlgorithm quantizationAlgorithm, Int32 ditherLevel, Int32 alphaThreshold, PropertyBasedSaveConfigToken token, ProgressEventHandler progressCallback, Double progressStart, Double progressEnd) in D:\src\pdn\src\PaintDotNet\Data\InternalFileType.cs:line 454 at PaintDotNet.Data.InternalFileType.ChooseBitDepth(Document input, Surface scratchSurface, QuantizationAlgorithm quantizationAlgorithm, Int32 ditherLevel, Int32 alphaThreshold, PropertyBasedSaveConfigToken token, ProgressEventHandler progressCallback, Double progressStart, Double progressEnd, HashSet`1 allowedBitDepths, HashSet`1 losslessBitDepths, ImageColorsAnalysis analysis) in D:\src\pdn\src\PaintDotNet\Data\InternalFileType.cs:line 346 at PaintDotNet.Data.InternalFileType.OnSaveT(Document input, Stream output, PropertyBasedSaveConfigToken token, Surface scratchSurface, ProgressEventHandler progressCallback) in D:\src\pdn\src\PaintDotNet\Data\InternalFileType.cs:line 167 at PaintDotNet.FileType.Save(Document input, Stream output, SaveConfigToken token, Surface scratchSurface, ProgressEventHandler callback, Boolean rememberToken) in D:\src\pdn\src\Data\FileType.cs:line 261 at PaintDotNet.Dialogs.SaveConfigDialog.<>c__DisplayClass49_0.<UpdatePreviewAsync>b__0() in D:\src\pdn\src\PaintDotNet\Dialogs\SaveConfigDialog.cs:line 613 at System.Threading.Tasks.Task.Execute() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at PaintDotNet.Dialogs.SaveConfigDialog.<UpdatePreviewAsync>d__49.MoveNext() in D:\src\pdn\src\PaintDotNet\Dialogs\SaveConfigDialog.cs:line 632

Gotcha, luckily not a huge issue once you know that happens (and probably a non-issue for most people who even need alpha channels, anyway). Thanks for checking it out.

The autodetect bit depth is obviously convenient and works exactly as intended, but it would be nice if the bit depth it has chosen for the image was shown somewhere too. Working on texture resources for game engine purposes, my targets aren't happy if you give them a 8-bit png with 1-bit transparency instead of 32-bit -- the issues I've encountered is transparent pixel color info being lost and sometimes the end result is just a mess of colors with no transparency at all. That is to say, the resulting file is accepted by the engines but can end up having insidious glitches that aren't immediately apparent. Obviously I can just choose the correct bit depth manually, but it's easy to miss that your image ended up as 8 bits or less instead of 32. Also, saving something that has no transparency as 32-bit instead of 24-bit is also a bad move in many cases (alpha sorting being problematic for 3D engines) so I can't just leave that on.

I often work with game engine textures where the color data even on fully transparent pixels is important. If you resize or rotate something, all pixels become #00000000 instead of #00rrggbb. Not a pressingly big issue since generally it's fine to scale from high-resolution work version to the final size first, then apply final alphas, but it has caught me on a couple occasions. I checked the following: image resize always produces #00000000 regardless of chosen scaling method layer zoom/rotate, even at 90 degree angles, produces #00000000 image flip/turn (counter)clockwise or 180 work correctly layer flip/turn 180 work correctly selection resize/rotate produce #00000000 with bilinear/bicubic, work correctly with nearest neighbor selection moving works correctly with all modes Edit to add: Windows 7, paint.net version 4.2.14 if those make any difference

Was hoping 4.0.6 would fix this but no such luck. If you change the low output parameter in the levels adjustment, it won't be remembered and will be 0 again when you next do levels. However, the mid parameter will be fudged around in some not entirely sensible way by the low param. Example: Run levels 32 192 -> 64 192 @ 1.5 gamma Open levels again: the parameters have turned into 32 192 -> 0 192 @ 0.82 gamma