Rick Brewster

Administrators
  • Content Count

    16,019
  • Joined

  • Last visited

  • Days Won

    128

Everything posted by Rick Brewster

  1. Okay I don't have Outlook 2010 so I can't debug this directly What we can do however, is this: 1) Download "Clipboardic" from https://www.nirsoft.net/utils/clipboardic.html 2) Extract it to a folder, maybe on your desktop 3) Open it up, you'll see a window like this: 4) Go back to Outlook and Copy the item that's causing the problem (NOTE: make sure it's something you're willing to let me look at! the kittens are a good image to use) 5) In the folder where you extracted the app, you should see some *.CLP files. Zip up the newest one and send it to me in a private message Once I have this file, I should be able to use the same program to import the data into my clipboard and then I can inspect it and see what's going on.
  2. @xpclient If you really need HEIC support then I really think your best bet is to just upgrade to Windows 10. Windows 7 is going to be end-of-life soon, and it'll be a very bad idea to stick with it. https://forums.getpaint.net/topic/114255-reminder-please-upgrade-to-win10-microsoft-ending-win7-support-january-2020/
  3. @Rene Slijkhuis This plugin is using reflection on the Stream that's passed to it to access a private field ("stream") and extract the file name. That's very bad. Do not do that. I guarantee that this will break soon.
  4. Just make sure to NOT disable the updater, and to then install 4.2.1 when it's offered.
  5. I'm able to reproduce the error with that image you put on DropBox 👍 I'm hoping to put out 4.2.1 "soon", by the end of next week maybe.
  6. It sounds like your "RawTherapee" program is emitting a weird bit of metadata that WIC is interpreting as a "vector of variants" (4108 = 0x100C = VT_VECTOR | VT_VARIANT). Anyway thanks for reporting this. I should be able to fix this easily for the 4.2.1 update by skipping over the metadata. Whatever that metadata entry is, it will likely not be preservable, but we'll see
  7. If you rename it to another format then Paint.NET will be able to load the image but not the metadata.
  8. I wouldn't "blame" Microsoft. They implemented it this way intentionally. In code, when you open an image with WIC you give it a "stream," not a file name. It doesn't even know the file extension of what you're working with. It must be able to detect the image type, usually from the first few bytes, and route the request to the given decoder.
  9. Can you recreate this with an image you're willing to share? I can't debug this without being able to look at the image. My guess is that this is related to https://forums.getpaint.net/topic/114711-error-opening-a-file-with-wrong-ext/ In other words, the image is one type of image but is being saved with the wrong file extension. Paint.NET will then load the pixels just fine but there's a glitch in reading the orientation (rotation) metadata because the file extension is wrong. Or maybe not the first part (wrong file extension), but certainly something goofy with the rotation.
  10. However, worth noting, is that if you have an image with the wrong file extension, the metadata will not be parsed correctly. I can't guarantee that things will work.
  11. If it's a bmp then it should have the .bmp extension ... not .jpg This was essentially a bug in older versions, an accidental features due to the way GDI+ was gracious about things. The file type system in PDN isn't set up to identify files and parse them regardless of the extension. However, my intention with 4.2 was to preserve this behavior, even if I didn't really like it. GDI+ is a wrapper around WIC, but now PDN is using WIC directly, and WIC does support this behavior. When you* open an image with WIC you can tell it to force a specific container format (e.g. BMP, PNG, ...) or you can say "just figure it out". And it looks like I missed a spot and PDN's BmpFileType is say "only use BMP" instead of "just figure it out". I'll fix this for 4.2.1, it's easy. * as in "the developer writing the code"
  12. I'm sure I'll improve the L/C tool at some point, it's just not at the top of the list right now. These things take time.
  13. You accidentally clicked to set it to inches ("in"). Just set it back to pixels like @toe_head2001 pointed out
  14. Not really a bug. You're just drawing white on white. Technically, yes, this niche corner case could be fixed up -- but the performance cost isn't worth it.
  15. so I guess we can rename this thread to "Paint.net WILL open" ... ? And we tried to help. You didn't give us any information to work with. We're not psychic. But hey, at least it works.
  16. Well, we found the solution at least ¯\_(ツ)_/¯
  17. It's on GitHub, you should now have access. If not let me know.
  18. It's not random. It's fitting it to the window. Press Ctrl+0 to zoom to 100%. You can also use Ctrl+B to toggle Fit to Window.
  19. Maybe read about it? A ton has changed under the hood. https://blog.getpaint.net/2019/07/13/paint-net-4-2-is-now-available/ And @toe_head2001 is right. The bug is in your code and file naming, not in Paint.NET.
  20. No it's not. Not even remotely close.
  21. How much would it cost to fund development of that? At least half a million dollars, probably more. I'm dead serious and not joking. It would be an enormous amount of work and would require hiring Linux developers with expertise in UI and desktop software development. Your best bet is to light a fire under the WINE team to get them to fix whatever is preventing Paint.NET 4.2 from working on it. Last I heard their Direct2D support still needed a lot of work, but I'm sure they also have incomplete support for WIC, DXGI, Direct3D, and UIAnimation. There's approximately 0% chance of porting Paint.NET natively to Linux unless the Windows business itself goes bankrupt and is discontinued by Microsoft. It will have to be emulated through something like WINE. I bet you could do a Docker container too with a Windows image, but I haven't ventured into that territory.
  22. This is a big update that focus on adding HEIC file format support, fixing performance with very large images, and upgrading and modernizing the functionality of many existing file types (JPEG, PNG, BMP, GIF, and TIFF). Many other quality of life issues have also been addressed or fixed. If you’re using the Windows Store release, you should get the update automatically within the next 24 hours. You can also force an update check by following these instructions. For the Classic release, you should be offered the update automatically within the next week or so. You can get the updater soon by going to ⚙ Settings → Updates → Check Now. You can also download and install it directly from the website. It's important to note that HEIC file format support requires two things: 1) you must be using Windows 10 v1809 or newer, and 2) you must install Microsoft's HEVC Video Extensions from the Microsoft Store which costs $1. This is necessary due to HEVC being mired in licensing and patent royalty costs. If you want to find some HEIC images, look no further than your recent iPhone (7 or newer). Many newer Android devices also support it. Most of the other built-in file types -- BMP, GIF, PNG, JPEG, and TIFF -- have been internally upgraded from using GDI+ to being built on top of WIC (Windows Imaging Component). BMP can now save 32-bit images with alpha transparency, while JPEG and PNG can now load and save much larger images, and TIFF now supports saving at 24-bit and 8-bit color depths ("Auto" is also now included). On the performance side, I've rebuilt the data structures inside of the rendering engine that are used for keeping track of invalidation regions. These hold information about what parts of the image need to be rendered and then redrawn on the screen, either because the image has been changed (like with drawings or effects) or because of scrolling and zooming. In previous versions you couldn't really work with very large images, starting around 32,000 x 32,000 pixels. Zooming in and out would result in a lot of slow performance, lag, and even complete hangs of the app for seconds -- or more (at 60,000 pixels it could hang for 30-60 seconds or more!). Now this should all be completely fluid 😁 Please note that a previous beta, 4.2 build 7121, included functionality that would automatically apply an image's embedded color profile, thus converting the image to the sRGB color space and "fixing" its colors. The complexity of color management was much higher than expected, and thus it has been removed for now. It may come back in a future update but in a more substantial form. Check out Jeffrey Friedl's excellent Digital-Image Color Spaces article for a good read on this subject. Here is the complete list of changes since the 4.1.6 release: New: Support for loading and saving HEIC images (Windows 10 v1809+ and codec installation is required). Please note that the "Quality" slider when saving is limited to a value of 90 (out of 100) while Microsoft investigates and fixes a crash in their codec. New: Keyboard shortcuts for changing the current layer. You can see these in the Layers menu with the "Go to ..." commands. Alt+PgUp/PgDown will go to the layer above/below, and Ctrl+Alt+PgUp/PgDown will go to the top/bottom layer. Fixed: Optimized rendering engine to remove huge lag spikes (30+ seconds) when zooming or panning very large images (e.g. 32K x 32K pixels). Improved: BMP now supports saving in 32-bit (with alpha!) and 8-bit indexed. Improved: Added DIB and RLE file extensions to the BMP file type. Improved: PNG, JPEG, and TIFF now support loading and saving of much larger images. New: PNGs can now be saved as "interlaced". Improved: JPEG now has configuration for the chroma subsampling mode (4:4:4, 4:2:2, and 4:2:0). The default is now 4:2:2 instead of the unconfigurable 4:2:0 of older versions. This may result in larger file sizes, but higher quality, as compared to previous versions. Improved: TIFF now supports saving at 24-bit and 8-bit color depths. Improved performance of saving for file types where "Auto" bit-depth is supported but is not the current choice. Improved temporary memory usage when saving images at 8-bit color depth. Improved: TGA images now load about 4x faster (thanks @null54!) Fixed: 8-bit TGA images should now load correctly (thanks @null54 for the fix!) Fixed: Some 32-bit TGA images were showing up as completely transparent due to their use of an obscure alpha channel type (thanks @null54 for the fix!) Improved: Added error reporting to the Save Configuration dialog. Instead of just saying "Preview: (error)", you'll also get the standard error dialog that includes the exception which can used for troubleshooting. Fixed a number of performance issues in the Save Configuration dialog. Especially with large images, it should now be much faster to change options and to click OK/Cancel. Fixed flickering in the Save Configuration dialog when changing options. Fixed: Windows Explorer thumbnails for some image types (PDN, DDS, TGA) were not rendering their alpha (transparency) correctly, resulting in color skew. You may not see the effect of this fix for a particular image until that image is resaved or you clear Explorer's thumbnail cache. Fixed: Mouse cursors now scale appropriately for non-integer UI scales (e.g. 125% or 175%) Fixed: AltGr should now work correctly with the Text tool. It will not trigger shortcuts like File -> Save All, or Edit -> Paste into New Image. (thanks @Bruce Bowyer-Smyth for the fix!) Changed: Image->Resize supports Super Sampling again, and favors this over Fant when using Best Quality. Fant is still available, but is no longer chosen automatically. Changed: Holding Ctrl when starting to move a selection with the Move Selected Pixels tool will no longer leave behind a copy of the selected area Fixed: Bicubic resampling in the Move Selected Pixels tool was not correctly handling the alpha channel in some cases. This fix has required a reduction in performance. Improved: When using Edit->Copy, a 32-bit BGRA bitmap in the DIBV5 format is now placed onto the clipboard so that other apps can read the alpha channel. Improved: When using Edit->Paste, DIBV5's are now supported if they have an alpha channel. If they don't, then the regular DIB loader is used which has some heuristics for detecting an incorrectly defined alpha channel and correcting for it. Improved: When using Edit->Paste, PNG is now the highest priority format. This maximizes the ability to maintain alpha/transparency, but it does mean that images coming from Microsoft Office apps will appear larger than they used to. This is either a bug or a feature of Microsoft Office. For some reason it places PNGs on the clipboard that are 25%+ larger than the DIB/DIBV5 bitmap that it also places on the clipboard (but which don't have alpha/transparency). Fixed: DIBV5 bitmaps should now work with Edit->Paste, which improves alpha channel handling. (thanks @null54 for the fix!) Fixed: Top-down DIBs should now work correctly with Edit->Paste. (thanks @null54 for the fix!) Improved CPU usage for thumbnail updates (layers and image tabs) in many cases. Improved: Slightly increased the size of the Settings dialog to reduce the need for scrolling in a few important situations Fixed: Simple message boxes can now be closed with the ESC key Fixed: Magic Wand now works on very large images (e.g. 65535 x 65535 pixels) without an error. New: Plugins that use IndirectUI can now use a UriProperty with a LinkLabel control (thanks @null54!) New: Effect plugins can now more easily make use of the clipboard via the IClipboardService. It will handle all of the tricky clipboard issues such as threading, native data marshaling, and avoiding security vulnerabilities that exist in the standard WinForms and WPF clipboard APIs. New: FileType plugins can now specify separate lists of extensions for loading and saving. Blocked the WebP FileType v1.1.0.0 plugin due to instability. An update is already available. Blocked the ImAgif FileType v0.12.0.1084 plugin due to incompatibility. An update will hopefully soon be available.