Rick Brewster

It might be doable with compute shaders, but PDN's D2D wrappers don't have support for that yet, nor does @sergiopedri's ComputeSharp.D2D1.

Did you know about Effects -> Noise -> Median? That's what this new plugin is replicating, but running it on the GPU The CPU version (the built-in Median) is actually faster, too -- as it turns out, doing a median calculation is very expensive to do on the GPU!

Well that image immediately caught a different bug -- you can't run a GPU effect (or adjustment) on that image, there's an internal overflow that prevents it. I've fixed it for the v5.1 release.

No; that is just background technical commentary. Also, that note is obsolete because it refers to an older version of the plugin.

@tieTYT the first post tells you where to find them in the menus.

No -- shader linking can only link a simple shader to another simple shader. I was just linking to D2D's documentation as a side note. Do you mind if I take this code and run with it? I might be able to turn it into a more fleshed out plugin, or even incorporate it into Paint.NET itself. I know @BoltBait has been asking me for a Median effect he can use in his plugins, and this might do the trick better than the median approximation algorithm in Median Sketch.

With shader linking, they should be equivalent (there are restrictions on this). But that's mostly a performance thing and I'm not sure that's what you mean. What I'm saying is that you can think of a shader's simple inputs as being equivalent to function parameters, e.g. float4 Execute(float4 simpleInput1, float4 simpleInput2). (You can't write the code like that, but like I said it's conceptually equivalent/isomorphic.) The shader's Execute() method would only call HiLo() once. The value for d would just be plugged in as a shader const (a private readonly field). Input 0 would stay the same and would be complex (D2DInputComplex), but Input 1 would be hooked up to the previous instance's output and would be simple (D2DInputSimple). So instead of: input -> Shader(call HiLo 8 times) = output You'd have: SourceImage | +---------------------------+-------------...-------------+ | | | v v v Flood(0.5f) -> Shader(call HiLo once)-> Shader(call HiLo once) ... -> Shader(call HiLo once) = output d=0.5 d=0.25 d=... Flood is used to provide the initial value for c. This would calculate the same thing, and it might even be slightly slower, but it would either eliminate or greatly reduce the lag imposed on the rest of the system because the GPU can "take a break" between each HiLo() call. Shaders can't be pre-emptively paused/resumed like CPU threads, IIUC, they must run to completion and can lock up the GPU or the whole system.

You're asking for a completely different app. Paint.NET can't just be "ported to mobile phone." That's like asking to add a bed to your life raft because you can't always use your yacht. Yes, they're two superficially similar things, but they're also just ... not similar. Because that's all you can really fit onto a mobile device's screen Never going to happen, and this has been communicated clearly since PDN's inception almost 20 years ago. If you need Paint.NET, then use your PC. If you can't use your PC, then that's just a completely different issue? I can't solve all of your problems.

Are there strings that you edited that got missed? That's possible, it's happened before, and unintentional. Just point them out to me and I'll make sure they get picked up for the next update. It is not necessary to "create an issue" in Crowdin (for Paint.NET anyway) -- that actually just adds a ton of noise. I go through every change in the activity log, which catches most things, and then I do search queries for things like "translation added but not yet approved" or "translation changed since approval", etc. Sometimes when there are two translators making edits (which I'm not sure is the case for Corsican), it can be difficult to figure out which translation to use.

I played around with this a bit and it's really interesting! It definitely has some performance problems, but I think that could be improved -- I believe each invocation of HiLo() could be put into its own node in the shader graph, which would help avoid bogging down the GPU scheduler (pre-emptive scheduling does not seem to be a thing) as it appears to need to fully execute a shader before it can task-switch out to something else. This "temporal separability" is a major advantage of the algorithm you've devised here. So the shader would take two inputs, the first being the source image and the second being the output of the previous shader. Then chain it 8 times. Where did you come across this algorithm? Searching for "hi-lo algorithm" gives me a bunch of discussion about ... databases?

Paint.NET puts a PNG in the first priority position on the clipboard. I'm surprised Firefox doesn't just use that instead of the DIB/DIBV5.

There is nothing official for this, and I won't be providing it. However, for an upcoming major release (let's call it 6.0) I am planning on redoing/revamping the .PDN file format. I am hoping to include with this a public specification of the file format to better enable interoperability. The new versions of Paint.NET will be able to open both the old and new .PDN format files, but old versions of Paint.NET will obviously not be able to open the new format. This format revamp will then open the door for new features, e.g. higher bit-depth pixels, layer folders, etc. Right now the .PDN format is kludgy (it's based on .NET's binary object serialization) and not worth amending with these for various reasons.

You need to tell us which fonts, otherwise our lack of psychic powers prevents us from being able to investigate this

It will never ever happen. This has already been asked and the answer is in the links you posted and in the FAQ. No reason to open another thread about this.

Layers -> Import Image and select all the PDNs in order to import them all into 1 image, and then use that ZIP filetype plugin @frio mentioned

What do you mean by "cleared" ... ?

You can do this by leveraging some DirectWrite stuff that I haven't wired up yet. No "math" involved, it will just tell you where to draw each glyph (letter). But, it's a bit more work. I can definitely get this wired up for v5.1 and then show you the ropes. I can probably make it "really easy" to use.

@BoltBait do you want to support multiple lines of text? (in other words, was this was a design choice, or were you not yet sure how to do it)

That's just how it is on my system for some reason, I forget why. Anyway the documentation works fine for everyone else, and you also figured out, so I don't see any reason to worry about this. I'm not sure why you're so upset about it. It really just sounds like there's some configuration problem with your PC. You have a pattern of making grumpy/argumentative posts on this forum, so I doubt continuing this conversation is going to be productive. You have your answer.

Because that's not the path that Paint.NET uses. It asks the Windows shell directly for the Documents folder location via ye ol' CSIDL_MYDOCUMENTS. You may have OneDrive installed, and it may have pushed itself to the top of your Explorer navigation pane, but you may not have it configured to be your official Documents folder. (This is how it wound up on my system: OneDrive's folders look like they're the primary location, but then there's a second list of folders below it and ... ugh, I don't know what happened here but it's a constant nuisance here that I haven't bothered to look into yet.) You can configure this, btw. Open up your user profile directory and then right-click on Documents. Then go to the Location tab and verify that it's pointing where you want it to.

In other words I prefer you to not need to implement IBitmap yourself. Having a flag for controlling this behavior does sound reasonable.

I could also look into adding that in an extra overload, like factory.CreateBitmap(..., CreateBitmapOptions.RequireContiguousAllocation) There isn't yet a non-internal implementation of IBitmap[Source] that I know of, so I'm not yet ready to endorse and support it. It's not that I'm disallowing it, there's just a few weird corner cases in the component model and I need to make sure the potential sharp edges are rounded off. For the moment, let's just see if it helps narrow down what the problem is. Then we can figure out if 5.0.13 should have that extra overload. And/or we make sure that implementing IBitmap[Source] via BitmapSourceBase<TPixel> is both possible (which it is right now) and fully supported (i.o.w. I won't regret it later for some reason I can't foresee right now).

@null54 you can do some additional debugging by making your own implementation of IBitmap[Source]. Derive from BitmapSourceBase<TPixel> and then also implement IBitmap<TPixel>. In your implementation you can use whatever allocator you want, e.g. NativeMemory, so you can employ whatever stride you need to help you narrow down where the problem is.

@BDP, probably won't help -- they already did a clean install of the entire OS. And if you need the latest drivers for a GeForce (930A in this case) just go to nvidia.com, no need for some random utility program. It really does look like a failing/failed GPU. The vertices for the selection data are obviously mangled, and nothing short of blatant memory corruption somewhere along the way could cause that.

I can't seem to figure it out from looking at the code 🤔 But from looking at the screenshots, my guess is there's (at least) a bug with how the per-row output pointer is being calculated. Notice how it has a transparent chunk at the bottom. This could happen if the destination stride was not taken into account, and if that stride was a bit larger than the width*bytesPerPixel. It looks like maybe about 10% wasn't filled in? So maybe the output is ~900px wide, but the buffer is ~1024px wide (with 3600 byte stride). I can't really discern a specific pattern in the output pixels -- it's obviously not just the left portion of the image, which sometimes happens if bytesPerPixel is incorrectly applied (e.g. only filling or utilizing the left 25%, or something like that)