zeromus

I know OP was upscaling, but I am downscaling and have always used supersampling. I wanted to write some notes here for fans of the old supersampling (but the context is only downscaling). I discovered that an up-to-date "fant" (from 5.0.7) was doing what I always thought supersampling was doing for downscaling (the box filter). In fact, I can't find any difference except for rounding errors (that is, +/- 1). These errors had an artificial line-like structure; I assume these came from the old "unsalvageable" optimizations. In the 4.2.14 paint.net I've been using for years, fant looks pretty decent on casual inspection but seems offset by half-pixels down and right perhaps. Most importantly, the 5.0.7 fant doesn't have this problem. Therefore, for fans of supersampling for downscaling, I suggest you use fant but check your paint.net version closely to make sure it is the latest version or one that has the superior fant. I'm okay with supersampling being removed because now this fant's close enough for my needs. You just have to know to use it when you discover supersampling is missing (and that education is what this post is for.) I don't recommend bicubic (smooth) for fans of supersampling downsampling. You're not going to like it. It gets rid of the ringing, but at what cost!? For fans of supersampling for downscaling, I think you must also disable the gamma correction. While the gamma correction yields some interesting results (I had one test case where it saved some stars in a starfield that would have otherwise disappeared) it also invariably gives an impression of changing the image overall when a/b tested with the original. I don't think fans of supersampling for downscaling will like that.

OK, I can believe that. I've seen tooltips off the bottom of winforms toplevel windows not blinking before, but not in applications as complex as paint.net which could be doing 1000 other things to smoke out the scourge of the flickering tooltips.

You're right. This thread is a textbook illustration of disrespect.

I just noticed there are no tooltips for any of the widgets at the bottom of the screen. This made it difficult to figure out what was happening with the zoom mode button so that I could understand your response to https://forums.getpaint.net/topic/114683-paintnet-42-is-now-available/?tab=comments#comment-561516 Regarding that locked thread, I don't agree with how this works. When the zoom is locked, the zoom icons don't appear grayed, and rightly so -- using them will kick it out of zoom lock mode. So too should panning. The zoom lock mode is still useful, in that the document stays filling the screen while you move the window around, but would be less obtrusive then, getting out of the way when you're indicating via the mouse "I want to actually do something that you're blocking". I don't think the point is to prevent people from accidentally panning, so this should be taken as a cue that they are no longer interested in the zoom lock mode being enabled.

The new (as of when? I don't know) layer palette icons are not improvements. They are a sea of pale boxes. It is the merge and sort up/down buttons that I get mixed up about. Those are two very different things, but the icons (blue boxes and arrows) are similar so I get lost. Compare to the previous icons which had giant up and down arrows only for the layer moves. The pretty aesthetic logic is "these buttons do things to layers so have an icon containing a layer" but that is poor logic. The context of that menu is already layer. Information saying "this icon is about layers" is redundant, and is essentially noise, making the SNR for the strip of icons very high. At the same time the useful information (the arrows) have been shrunk thus impairing the SNR even more. Actually, when I want to move a layer down, my eye is drawn to the slightly larger arrow on the merge icon (and the arrow isn't the important part of that, it's the two boxes) and so I use that icon, then wonder what in the heck is happening. There is the same situation is intense for the delete layer icon (formerly a giant X, now a tiny X with an irrelevant blue box). For these reasons, the old icon concepts should be restored, even if you have to redraw them to match some new line and fill styles with the other icons in the UI.

I've just noticed a weird problem where any newly opened (or created) document cannot be panned by holding the mouse wheel / middle button. The cursor will show an opened hand and an X instead of a gripped hand. However after simply zooming in once and then back out it gets unlocked, and there are no longer any problems with that function. I'm running windows 7, and I would readily believe it's something jacked up with my system, and I haven't tried rebooting. I don't anticipate rebooting between now and a future paint.net release so I figured I'd go ahead and report it. To be clear, the repro steps are: 1. Open paint.net 4.2 final 2. Try dragging with mouse wheel (it wont work)

Oh don't worry about me, I'm quite fine after I shout a few vile oaths at my monitor, each and every time. I actually feel quite blessed overall by paint.net, and thanks to all responsible for that. I don't use more than 2 documents in paint.net because the ctrl+tab logic is wrong and it would just confuse me, so I never noticed that. But I could see it being a similar situation for an appreciable fraction of the dozens of users still using classic theme. The same problem does apply to the tool palettes however, but it isn't as disconcerting there just due to the usage pattern, I believe.

OK, so I gather I will be miserable until the end of my days because toggling visibility off a layer changes the edit focus to another irrelevant layer drawn out of a hat, and there will never be an option to change this. But I'm more miserable than most people because the color of the selected layer for editing is equal to the color of the layer that my mouse is hovering over (i.e. the one I just toggled the visibility of) so that whenever I toggle off a layer, I see two layers selected. I am then suddenly uncertain what has happened and I have fewer visual clues to regain my equilibrium than everyone else. I'm attaching a screen shot of me having just toggled layer 3 off. I don't know why the mouse cursor went weird when I took my screenshot. I'm also attaching a crude mockup of what it should ideally look like instead. I have ascertained during the 30 seconds I was willing to engage the aero theme that it functions similarly.

I won't be using Windows 10. I can't entirely freely pick which OS I use, and even if I could, I wouldn't pick windows 10, which seems to add nothing of interest for me and forces me to abandon the windows classic theme. When paint.net requires Windows 10, I won't be using paint.net anymore.

Well, it certainly auto-chooses 8bit when theres less than 256 colors used in the image. That would be a correct decision. If it looks fine in other programs but just not in minecraft, then that's pretty much proof that paint.net is working correctly and it's minecraft with the problem.

.net framework is different from .net runtime. It's the .net framework that you install, which makes sure it's corresponding runtime is installed. So, 'requirements' lists for software installs list the .net framework versions. And usually when just ".net" is said casually, it's referring to the framework. you can check if you have .net framework 4.5 or 4.5.1 or 4.5.2 (I would imagine, I havent checked that version yet) by looking in appwiz.cpl under "microsoft .net framework" If paint.net requires framework 4.5, then having 4.5.2 would not interfere with it. So it's worth installing. However, I'm not sure whether A) 4.5.2 would even get used by paint.net, and whether anything microsoft claimed it fixed would manifest as fixed in paint.net (it would depend on many details of paint.net engineering) Making programs be DPI aware is potentially one of the most excruciating things for a programmer to do, depending on his personal nature. One thing that makes it easier is if you make your UI look like a fisher-price videogame toy. That trick isnt available to programs made for serious grown-ups getting work done, like paint.net. So... try to have some patience

Of course I agree this is piriform's problem and not paint.net's, but in case youre curious: maximize the window, sort by registry key, and search for HKCU\Software\paint.net. You will probably find other entries in the sorted region of HKCU\Software so youll know when youve found that region, but it isn't guaranteed (I didn't have that many). Then you can find it's comments on why it's messed up. I only found "obsolete software". When I allowed it to just clean one of those, it said it was going to delete it, and it did.

occam's razor says: the files are corrupted. I suggest you backup your other files.

If no program can open it, then that's a pretty sure sign the file is corrupt.

I can't make sense of "trustedinstaller download says the file is invalid, so I can't use that". It sounds garbled. Have you redownloaded the paint.net installer? Perhaps you have -- perhaps 'invalid' is referring to an older version of paint.net's installer, which it is attempting to uninstall first, if the link i pasted is related. That link doesn't say there should be anything obviously about paint.net in your registry, it discusses a cryptic number in your registry. At any rate, you can search for msizap which lets you clear out MSI's awareness of old things to uninstall, or discover whatever microsoft thinks is an adequate replacement (some troubleshooting wizard), or whatever people are doing instead of msizap nowadays, or find a link to an old copy of msizap. There are a lot more links on this forum about the subject. I'm confident youre having the same problem http://forums.getpaint.net/index.php?/topic/20393-issues-installing-356-on-windows-7-x64/ http://forums.getpaint.net/index.php?/topic/18931-fatal-installation-error-1603-fix

http://forums.getpaint.net/index.php?/topic/17903-x64-msi-wont-install-on-64bit/ this sounds related. try to double-check the error message for more text which may relate it to that link, which posted more text in the error message. You can't conclude that you need a new 32-bit OS to install paint.net. It could be a dysfunction in your current 64-bit OS, as the above link would suggest. In fact, it is definitely untrue that a 32-bit OS is required to install paint.net. So don't do that.

Personally, I have no use for anything but PNG, but there's a lot of reasons.. let me brainstorm some... Even a maximum quality jpg is easily half the size of a png. Image processing scientists are weird and probably like JPEG better due to it being some kind of a mathematical transformation of the image data instead of a lame compression of imagedata as if it were any other kind of data, which is mostly what PNG is. And consumer electronics programmers are weird, having many clues and concerns about many things but not so many of either about how software users are going about their business. I think JPG is designed to be rapidly compressed with low requirements on resources and power. PNG is designed to be compressed without as much concern for those factors on a general purpose CPU. Someone may have to correct me, but It's possible that JPEG can be implemented in a way which can put predictable bounds on compression time or image size. This is friendly to a device which wants to ensure certain levels of responsiveness or cut as many corners on the hardware resources as possible Cameras have a tendency to produce speckled images, which JPEG can kind of blur to oblivion, and PNG chokes on. To JPEG, noise is just easily discardable information. To PNG, it is the worst possible kind of information which has to be kept intact (random noise). Finally, you get RAW instead if you dont like compression, so PNG is redundant, if you start from the point of view (its futile to resist) that JPEG is baseline functionality for image processing equipment.

mspaint doesnt seem to use WIA, so that isn't informative. maybe running a regsvr32 c:\windows\system32\wiaaut.dll would help. I'm not sure who installs wiaaut.dll, the internet seems kind of unclear on the subject. perhaps yours has been overwritten by another program. mine is 6.1.7600.16385 In your registry, you can check for this and make sure it's pointing at %SystemRoot%\System32\wiaaut.dll HKEY_CLASSES_ROOT\CLSID\{850D1D11-70F3-4BE5-9A11-77AA6B2BB201}\InprocServer32

Sounds like most likely someone who didn't know what the 'windows image acquisition service' was for disabled it. Restore its setting to automatic, and it can solve this error message (which might should be rewritten to mention this possibility). It's also possible that your WIA is broken and every time the service tries to start, it fails. You might could detect this by manually starting the service and see if it fails. In that case your windows event viewer should contain some information about why its not functioning.

I doubt it. That would be an unusual feature, and this program has an unusually low number of options. I'm confident this is a bug, so a discussion of how to disable that feature would have a short shelf life anyway, hopefully. But in case someone likes making it a hotkey, maybe it could obey the scroll lock key, which could be loosely defined as 'prevents things from automatically scrolling' and would therefore apply in this case.

. make a new image . zoom a bunch, 300% is enough for me . scroll all the way to the right . draw a filled solid rectangle from the center of your screen off to the very right edge of the canvas . magic-wand select it . copy, paste. with sharp eyes you can see the problem now, but... . ...nudge downards... . ...and observe that the selection got pushed leftwards 1 pixel, even though there shouldve been room to paste it without the new logic bumping it in.

I don't have to keep going back to where i copied from, if I remember to copy it immediately after pasting it each time. Then, it will be near where I am. However, if it's large, then it will no longer be near where I am; it will be nudged around seemingly incoherently. In fact, I already do this, because when zoomed out, I _do_ have to go back and forth from where I copied (albeit without having to scroll) Imagine the case where you copy a large area and then zoom in and scroll around and paste it into a whole bunch of different places near each other. The only time I want it your way (sometimes) is on the first paste while zoomed in. If it came from far away, it's nice if some part of it is in my viewport. Since most pastes are first-pastes, your default makes sense. That's why I asked for it as an option. Another related idea would be a hotkey which pastes the clip such that its move-box or clip center is under the mouse cursor. That would solve the original problem (clips too far away from the viewport to grab) although I wouldn't dare say it's better for anyone else than what you've done. However, it would enable me to still solve the original problem, even while your solution was disabled with an option. I would recommend ctrl+E for that, but only because that's what Paint Shop Pro uses. What I'm trying to say is I salute your zany ideas, but I think they mess up as many cases as they improve. However it's possible that with a few minor tweaks, all the messed up cases could get fixed and you'd be cutting-edge creative in a fully successful way. I'm not just making this stuff up, it affects me in actual work and I'm trying to understand what it is making me more comfortable in Paint Shop Pro for certain tasks.

In PDN 4.0+ , there is a change to the way pasted pieces work. They try (even though it is sometimes impossible) to move themselves to not be outside of the current view. Heres an example: . Open a new PDN with the default (for me, anyway) 800x600 canvas . Make a rectangular selection from 234,0 of 305x578 (specifics not necessary, just make it the middle 1/3 of the image, from the top to near the bottom) . Zoom in 6x or as much as necessary for the selection's edges to be totally out of view on your system. . Cut . Paste . Zoom back out You will see that the clip isn't where it came from, due to the logic which adjusts the clip position being unable to function when the clip is larger than the screen. In fact it's in no kind of sensible position. It should be pretty easy for a setting to disable this by suppressing the repositioning logic.

I'm still seeing some kind of problem (basically what I already described) in 4.0.2. I'm seeing some pixels with (Sr,Sg,Sb,0) where S is my secondary color, and some pixels with (0,0,0,0) left behind after moving a few pixels on a mostly transparent layer.

It is not very hard to reproduce his issue with the selection logic. At some point paint.net got really slow with extraordinarily complex selection areas. You can make it dysfunction impressively.. the selection rectangle will become useless, since it sort of updates the selection in realtime as you drag. Test steps A: Create a 2000x2000 images with a monochrome checkerboard (squares 1px large). Now pick magic wand, global selection, 50% tolerance, and click somewhere and watch paint.net freeze. Test steps B: FFSnipe's suggestion of using magic wand global with low tolerance is pretty spot on.. since this creates very complex areas of stray pixels. Just do it, on a large photographic image, and keep unioning the selection to increase the complexity, at least up til its 50% filled and the complexity would be decreasing! Youll see performance begin to tank eventually, but more gradually than test steps A. This is a phenom II X6 1090T cpu @ 3.2GHZ and a GTS 450