Jump to content

frio

Newbies
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

3

Recent Profile Visitors

57 profile views
  1. 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.)
  2. 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:\s
  3. 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.
  4. 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 ar
  5. 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
  6. 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
×
×
  • Create New...