BrainSlugs83

Okay, so in 4.3.2 how do we do it? -- It seems to completely ignore pressure sensitivity, the erase button, etc.

It's cool -- thanks for chiming in -- I'm willing to give it a shot myself as a plug-in. -- ... or did you mean the plug-in options? (i.e. the ability for more than one plug-in to support the same output file type? / the ability of a plug-in to change the default output type?) Just looking for the best way to accomplish this myself, even if others don't find it useful. Do you foresee any pitfalls here that I should avoid or have any advice on how I should proceed? 1.) My version of IrfanView -- even with the plug-in -- can't seem to read them -- Windows Explorer shows previews though, so that's pretty good -- also, the XNA content importers are broken now -- because they don't call initialize -- then you update them to fix that, and they don't work, because of some parallel junk that the Paint.NET DLLs do in the background which causes unloading the App Domain to hang -- I wrote a simple console app that just spun up new Surface/Document objects (load the document form a file, flatten it to a surface) and then tried to unload the AppDomain afterwards, and bam, it hangs and throws an exception, it's pretty bad. I'm thinking about just creating a console app and writing a console app that can do the conversion and shelling to it from XNA for the content import task... -- but as I was saying -- seems these kind of issues are crippling the ability to have a good .pdn plug-in for other apps (not to mention it's all 4.5 now, so you can't even load the dlls in a 4.0 app anymore... -- also each version saves the files in a version that's specific to that edition, it can read older files but not newer ones -- are the files really that different with every single version? seems to break forward compatibility of the plug-ins too... -- would be nice if there was a single .NET 2.0 or 3.5 dll that you could embed which could read the formats for at least a year without requiring an update...) 2.) psd is also a pretty non-standard format... (.NET can't load it by default either...) though, it's neat to know there's a plug-in for it. -- I bet there's a good open plug-in for .NET that can read them without issue, so it might be worth checking into. :-/ -- Would rather just have good support for a single native format. 3.) I will keep in mind that it's possible for the chunk order to be rearranged by external programs -- probably put some kind of small header in each chunk specifying that they're part of the data I need and also an integer specifying the order they need to be in (then I can just read them into objects and sort them based on the order value). Hmm, seems somewhat limiting -- and several applications (the aforementioned irfanview) have the helpful feature of renaming files that have incorrect file extensions -- in several ways, using an alternate file name extension defeats the purpose of what I'm trying to accomplish... -- I wonder, can you register compound file extensions? (like ".pdn.png"?) Is there a developer resource somewhere where I can find out more about getting started with writing Paint.NET plug-ins / an object-model reference or SDK?

So, this is my first post -- hopefully I'm in the right section of the forums -- I use Paint.NET a lot -- it's awesome. I work with .pdn sources, and then output to .png -- and if I modify the source again, then I re-save as the source, and re-save the output .png (and hope I did everything right, and cross my fingers that I didn't forget, etc. -- it's really painful actually.) However, I wonder why the two file formats are necessary, I ask myself: why not just have one format? I, like other users who've used FireWorks in the past, know that there's some way to save layered .png files. I've done some research here (before even stumbling on to the above thread) and have found that .png files definitely do not support layers natively. However, .png files do support arbitrary data chunks in them (that decoders which are compliant with the .png standard will ignore) -- also mentioned in that link: apparently jpegs can store arbitrary data too, but the chunks are limited to 64K in size (you can split a large segment into multiple chunks though if you need to)... It just makes me wonder, why not have an option [in addition to the current regular png/jpeg formats] for "fat" pngs (and/or "fat" jpegs) that contain both the regular flattened pixel data they would regularly hold (so that other spec abiding programs can read them without issue), but then in an arbitrary data chunk, store a gzip compressed version of the .pdn source? -- that way you could just have one single file that all programs could use, and you would have full fidelity of all of Paint.NETs features (the file format could save everything a regular .pdn file could). Honestly, if that option existed, I would switch to using that as my primary format, no more using two separate file types! It so happens, I'm a .NET developer (honestly, who else would be in this section of the forums?) and I'd be interested in prototyping the above functionality as a plug-in (if no one else is); BUT, before I get started -- IS this the type of thing a Paint.NET plug-in can do? -- Can it add support for loading/saving file types? -- Can the user change the default file format that paint.net prefers to use? -- Can I overwrite (or somehow deregister) the existing .png loading support? (If I have to build a fakes assembly or decompile / recompile with ILSpy, it might not be worth it to me... -- and Paint.NET isn't open source anymore right? -- So, like, it's not like I could branch it, add the functionality and then submit a git pull request or something, right?) Where's the best place to get started learning about writing this kind of plug-in (assuming what I want to do is feasible)? -- If it's not feasible, where can I submit a feature request (for either this specific feature, or at least, for the plug-in model features that would make it feasible for me to write a plug-in that can do this)? Thanks!