taoyue

I've never seen this happen to the PSD Plugin, but I have seen it happen to other files. For some reason, Windows is unable to delete the Alternate Data Stream on the file. The easiest way to remove the ADS on a file is to pass it through a FAT32 filesystem. Delete Photoshop.dll from the FileTypes folder. Reboot. Make sure the file is really gone. Insert a USB flash drive, ideally 32 GB or smaller. Right-click on the drive and select Format. Change "File system" to FAT32. Click Start, and then OK when it finishes formatting. Using Internet Explorer, download a fresh copy of the PSD plugin and save it to the flash drive. (Chrome and Firefox will download the file without asking you where to save it.) Right-click Photoshop.zip and make sure that "Unblock" does not appear. If it does, unblock it and make sure it sticks. Extract the ZIP file on the flash drive. Right-click Photoshop.dll and make sure that "Unblock" does not appear. If it does, unblock it and make sure it sticks. Copy Photoshop.dll from the flash drive to C:\Program Files\paint.net\FileTypes If at any step you run into a problem, please take a screenshot that shows the problem, and post it here as an image attachment.

Please post screenshots of: File Explorer, set to View - Details, opened to the folder: C:\Program Files\paint.net File Explorer, opened to the folder: C:\Program Files\FileTypes The Properties page for Photoshop.dll File Explorer, opened to the folder: C:\Program Files\Effects These screenshots will provide additional information about your system configuration that may help to diagnose the problem. Please be sure to make the Windows Explorer window wide enough so that we can read all the columns.

The download is a ZIP file. "It" should not be placed into the FileTypes folder. You need to look inside the ZIP file and then copy PhotoShop.dll into the FileTypes folder.

PSB files are planned for the next version of the PSDPlugin.

Paint.NET does not have editable text layers. The PSD plugin simply loads the file into Paint.NET. Once it has been loaded in, it's treated no differently than any other Paint.NET document.

Version 2.4.1 of the Paint.NET PSD Plugin has been released: http://psdplugin.codeplex.com/ This version requires Paint.NET 4.0. Changes: Fixed: regression in 2.4.0 that caused loading failures for files created in earlier versions of the plugin. Handles null-terminators on Unicode alpha channel names, a quirk in Photoshop that does not apply to non-Unicode alpha channel names or to other strings. The Files with null blending ranges can now be saved out successfully. Please note: There is a performance regression in Paint.NET 4.0 when loading files with a large number of layers. If you regularly load files with more than 100 layers, you may wish to stay on Paint.NET 3.5.11 and delay upgrading until the problem has been fixed.

Version 2.4.0 of the Paint.NET PSD Plugin has been released: http://psdplugin.codeplex.com/ Changes: Multichannel images can now be loaded, with each channel showing up as a separate grayscale layer. More reliable loading of files with layer groups created in Photoshop CS5 and CS6. Faster loading of PSD files. Speed improvement of 1.1x to 1.5x on 8-bit images, and about 15% on 32-bit RGB images. More efficient RLE compression, with file sizes reduced by about 4% on average. The PsdFile class can now load and save most PSD files to be bit-for-bit identical with Photoshop, if the same Windows codepage is specified.

Unlikely to be caused by pressure-sensitivity. Most of the time, the lag is caused by flicks. Right-click the flicks icon in the system tray, then "Turn off flicks." See screenshot below.

You're welcome. :-) However, I cannot claim to have created the plugin. Frank Blumenberg created the plugin, and I've been maintaining it since 2010. At this point, I'd estimate that I'm responsible for about 50-60% of the code in the PSD plugin. (According to source control, 19.4% of the lines in the code have not been changed since 2010. Of the remaining 80.6%, subtract 20-30% for trivial changes such as renamed variables.) Also, thanks are due to you, the users, for reporting bugs and suggesting features. There are a lot of other open-source PSD libraries floating around, but very few of them have this kind of engaged userbase. There are tens of thousands of users exercising the PSD Plugin code everyday, loading all sorts of files with it.

Hi George, The PSD plugin can already read RLE-compressed alpha channels. Compression is handled independently of bit-depth. The problem is that there is no corresponding concept in a Paint.NET document. What Photoshop refers to as "alpha channels" are actually used as masks, as selections, or to designate spot color. They do not form part of any layer image, and are instead stored globally for the file. Although they show up on the "Channels" palette along with RGB, they behave quite differently. Paint.NET does not have saved masks, or saved selections, or spot color. I suppose I could have the PSD plugin load the "alpha" channels into hidden layers, as grayscale images. But then the question becomes -- what would you do with them?

Version 2.3 of the Paint.NET PSD Plugin has been released: http://psdplugin.codeplex.com/ Changes: Fixed load failure when two masks are present on a layer -- a raster mask and a vector mask.If the vector mask is present in rasterized form, then it will also be applied to the image. Unfortunately, complex Photoshop files often do not contain a rasterized form of the vector mask. However, simpler files will now mask accurately when loaded into Paint.NET. Fixed load failure for files with East Asian layer names, on a system set to an East-Asian codepage. This affects: Simplified Chinese (GB), Traditional Chinese (Big5), Japanese (Shift-JIS), and Korean. Fixed bug that caused some 16- and 32-bit depth images to load in as flattened images, without layers.

Hi Yacine, Thank you for the bug report. This particular file runs into three different issues: The file has too many layers to load into Paint.NET. Because Photoshop has partial layers and Paint.NET doesn't, files with lots of layers will blow up enormously in memory consumption when loaded into Paint.NET. This particular file has 1279 layers, with pixel dimensions of 6200 x 3716. At 4 bytes per pixel, it would require 118 GB of RAM to load into Paint.NET. Layer index 472 contains both a user mask and a vector mask. The PSD plugin does not properly handle this situation. This is what's causing the "erreur non spécifiée." The file has malformed layer groups. The webpage hosting the file states that it was created in Photoshop CS6 beta -- which probably explains the bug. I'm still using CS4, which produces a warning message: "Some groups were found corrupted and repaired." I can fix problem 2 and ignore the error in problem 3, but you still won't be able to load the file unless you have more than 118 GB of RAM. Unfortunately, this doesn't help you directly. However, once I fix 2 and 3, at least they won't prevent other people from loading similar files -- that is, files with fewer layers.

Version 2.2 of the Paint.NET PSD Plugin has been released, and can be downloaded from: http://psdplugin.codeplex.com/ Changes: Layer group visibility is now applied to all layers within the group. This greatly improves the visual fidelity of complex PSD files that have hidden layer groups. Layer group names are prefixed so that users can get an indication of the layer group hierarchy. (Paint.NET has a flat list of layers, so the hierarchy is flattened out on load.) The progress bar now reports status when saving PSD files, instead of showing an indeterminate rolling bar. Performance improvement of 1.7x in RLE compression, and 1.2x in RLE decompression. Better detection of insufficient-memory on 32-bit systems.

The question of hooking into the editable text plugin has come up before: I don't really see any developments in the past 20 months to change my thinking on this issue. It's still a hack -- a clever hack, to be sure, but nevertheless a hack. If Paint.NET were to implement editable text layers natively at some point in the future, that would of course be a different matter. For one thing, I trust Rick to design a good API and think through the edge cases. Ultimately, there are dozens of features in the PSD file format that are not implemented in the plugin. You could probably make a case for most of these features. The bright-line test of whether something is implemented natively in Paint.NET neatly defines the scope of the plugin.

I can't reproduce the problems. Since you say the problem is intermittent, I tried it ten times, and didn't run into either sluggishness or error messages on any of the ten runs. Please make sure you're running the latest versions of Paint.NET (3.5.10) and the plugin (2.1.0). I've had users report weird errors that go away once they update to the latest versions. So it's always the first thing to check. It's very difficult to diagnose intermittent errors. Does it fail every time, or just half the time? What's different between the times it fails, and the times it succeeds? etc. The more context, the better. It's also difficult to assess "if it's too big for my computer or something" without knowing what your computer specs are. The file takes up about 450 MB of memory and loads in under 1 second on my machine, plus another 1-2 seconds for Paint.NET to render the image. This is unlikely to lead to performance problems, unless, say, you're running a netbook with a single-core Atom and 1 GB of RAM.

Version 2.1 of the Paint.NET PSD Plugin has been released: http://psdplugin.codeplex.com/ Changes: Fixed a bug in which layer blend modes were not saved when the Paint.NET language is not set to English. Layer blend modes are now preserved on non-English languages as well. Malformed PSD files with missing channels can now be loaded in. Preserves image resolution, so that physical dimensions will be correct along with pixel dimensions. Sets the VersionInfo resource on PSD files to indicate the PSDPlugin version used when saving the file. Fixed a race condition in the parallelized loading, causing random load failures on files with lots of tiny layers.

If you could point me to the original PSD file (or upload it somewhere), then I'll certainly take a look at what's going on. Could be a colorspace issue like delpart suggested, but could be caused by a lot of other things, too. I'd be interested in debugging with these files, too. CMYK files will not be color-accurate when loaded in, because the conversion completely ignores the color profile. But it should not load in as static. If it does, then that's a bug in the plugin.

Announcing the release of version 2.0 of the PSD plugin for Paint.NET. Now posted on Codeplex: http://psdplugin.codeplex.com/ Please note that this is a .0 release that includes substantial refactoring of the underlying code. Substantial regression testing has been performed, but there may still be bugs. As always, please report any problems on the forum or via Codeplex. Major new features: Higher color-depth images can be loaded. Since Paint.NET represents images using 32-bit color (8 bits/channel): 16 bits/channel images will lose some precision. 32 bits/channel images will be truncated to the standard dynamic range. [*]ZIP-compressed images can now be loaded. Newer versions of Photoshop use this type of compression for 16 bits/channel and 32 bits/channel images. Older versions of Photoshop also offered this as an option for 8 bits/channel images. Bugfixes and other minor changes: Empty layers are now preserved on load and save. Layer names can now contain Unicode characters. Several mismapped layer blend modes are now mapped correctly between Paint.NET and PSD: Color burn, Color dodge, and Additive. Somewhat faster saving of images when a large portion of a layer is non-transparent. PSD files created by Adobe Photodeluxe are no longer blocked from loading. The plugin will now verify that sufficient memory exists to load a .PSD file into Paint.NET. The user will get an out-of-memory error, rather than experience an apparent hang as the disk thrashes from virtual memory paging. Bugs reports and suggestions from the following users were incorporated in this release: Aleksandr Zamerov, LHammonds, midora, rsiskd, Serissa. Thank you for helping to make the plugin better for everyone!

Duplicate Unicode layer names: fixed in changeset b4e2cc01eebc.

midori: the best way to include images on this forum is to attach them. (Use the full editor -- the quick reply editor doesn't have the Attach function.) This allows the images to be viewed immediately in a web browser, without having to copy-paste to a temporary file and then decode. I took a look at your screenshot. In my testing, I have not seen duplicate "luni" resources in a hex editor. If you have a .PDN file that can reliably reproduce the problem when saved out to a .PSD, then I can investigate further. I filed bug 7963 in Codeplex to track the ResolutionInfo problems. Since you're a programmer, you might consider filing bugs directly in Codeplex in the future.

Thanks for the bug report and the investigation. I've just committed changeset 1c3b7fb44cc0, adding proper handling of Unicode layer names.

No, the problem is with the plugin, which was originally written to skip all empty layers. I've since changed this behavior to load in all layers, but this was done in April 2011 and the 1.6.0 release is from December 2010. I still have some things to complete before the next release, but if you PM me your email address, I can send you a private build to use in the interim. There seems to be another problem with this file that you didn't mention: the circle looks gray in Paint.NET but green in Photoshop. This is because the "shade" layer uses the "hard light" blend mode, which does not exist in Paint.NET. This problem is still going to exist -- but perhaps it's not a problem for your particular use case.

Thanks for the repro. This is a very interesting edge case that you've turned up. I'll have to add some special-casing for images with no background layer. Should be in the next version. (If you send me a PM with your email address, I can give you a private build before then, to test with.)

I can't reproduce that problem either. After creating an empty PSD file in Photoshop (with or without adding empty layers on top of the background), it loads fine into Paint.NET. If you can supply a PSD file that triggers the problem, I can investigate further.

Could you supply a PSD file that demonstrates the problem? I cannot reproduce this issue by adding guides to a PSD file that already loaded properly into Paint.NET. Guides are implemented in the PSD file format as an image resource. The plugin only attempts to process PSD image resources that it understands, and to ignore the others. So it's relatively unlikely that guides would cause a problem. Of course, there are always edge conditions and unanticipated situations. But it's also possible that there's some other issue with the file that happened to coincide with the use of guides.