Goblin Alchemist

👍 🙂

Windows 10 Keyboard layout with non-Latin alphabet (e.g. Cyrillic, Greek, Arabic etc.) Switch to Latin (e.g. English) keyboard Ctrl+A selects the whole image - OK Ctrl+Shift+I inverts the image - OK P activates the Pencil tool - OK K activates the Color Picker tool - OK Switch to another (e.g. Russian) keyboard Ctrl+A selects the whole image - OK Ctrl+Shift+I inverts the image - OK P is not working - ERROR K is not working - ERROR I suppose that, for keyboard shortcuts without modifier keys (e.g. simple P or K), "virtual key codes" should be used instead of "character input", so that the key code does not depend on the current keyboard layout.

I always have many programs running on my computer. Outlook, Skype, Winamp, browser, task manager, various editors etc. Moreover, I know that there are hundreds of invisible services running. When I want to shut down the computer, I don't want to close each of these programs separately; I simply click Start > Shut down. All running programs are closed automatically by the operating system. Each program responds correctly to this action: it gracefully closes. Of course, if there is an unsaved edit in an editor, it responds to the operating system with a corresponding message; the computer stops shutting down and requires me to save or discard the unsaved file. This is obvious. But Paint.NET is always preventing Windows from shutting down, even if all files were saved. This is annoying. I believe it's a violation of Windows coding guidelines. It's very strange to see this kind of odd behavior from a program branded as ".NET".

After reading the Wikipedia link I agree that this is indeed correct HSV. In this definition, V = max ( R,G,B ), so bright yellow, deep blue and white all have 100% Value. But please note that the conversion from RGB to HSV is not smooth. It's obvious from the fact that the non-smooth "max" functon is employed. Also see the picture from Wikipedia: conversion to HSV and to HSL requires flattening the RGB/CMY spatial polygon to a planar hexagon. This is when the creases occur. If then we perform some manipulation in the HSV space (e.g. shift the hue) and convert back to RGB using the same conversion, new creases are added; the two sets of creases either cancel each other or not. So my point is that the Hue/Saturation dialog should use something other than HSV or HSL. For example, the Luma/Chroma/Hue model may be better because the conversion from RGB is simple affine transformation without any "min" or "max" functions, and a smooth gradient will remain smooth.

Cool, didn't know about this feature. Your code introduces creases explicitly with the Math.Abs function. But at first glance in the Hue/Saturation dialog there should be no creases, it should smoothly adjust colors and that's all. This is the problem.

Sorry I didn't understand the thing about moire patterns. I don't have moire patterns there, I have a smooth gradient. And red, yellow and green are not opposing each other. Yes, the RGB color space is a cube. But Euclidean distance from zero (black) is not saturation, it's rather a kind of lightness or brightness: white is also distant from zero. Saturation is the Euclidean distance from non-saturated colors, or the black-white diagonal of the cube, or the grayscale axis. Geometrically it would be a cylinder. But calculating the exact distance requires some square roots, so I believe a faster algorithm is employed, with simple comparisons and subtractions. But this fast agorithm is calculating something different than distance, so the surface of constant saturation becomes a hexagonal prism around the grayscale axis. I would rather argue that the current implementation is not HSV. For example, "V" in HSV stands for Value, or lightness / brightness. Draw something in bright yellow color and change its hue by 180. The color will become deep blue, which is obviously darker, i.e. has different V (value). I have flattened the image and merged the two layers into one. I believe 3.5.x should work the same in this aspect. In the RGB color cube it's hard to define what are "rainbow colors". The six "pure" colors are in corners of the cube, and the line connecting them is a broken zigzag line. I'd rather not call it a "rainbow", the rainbow should be something smoother. Yes, I think that saturation is the distance to the grayscale axis, and "pure" colors have 100% saturation. Calculating it exactly as Euclidean distance yields a cylinder passing though these six corners. Orange is an intermediate color between red and yellow, so in RGB space it is on the straight line connecting red and yellow, therefore it's inside the cylinder and has less than 100% saturation. Yes, on every conversion the calculations may produce fractional numbers which are then rounded, which introduces a small rounding error (not larger than one color step, or 1/255th of the full color range). Such error is usually not perceptible, but if you make several HSV adjustments and then do strong contrast/gamma adjustments, it may become visible. That's why some professional software operates in 16-bit color spaces and uses image formats such as 16-bit TIFF. http://en.wikipedia.org/wiki/HSL_and_HSV There is a double cone indeed Wow, code, something interesting. How do I run it?

Create a new square image, draw a black-to-red gradient from left to right. Add a new layer, draw a black-to-green gradient from bottom to top. Change the second layer mode to "Additive" and flatten the image. You get a smooth four-color gradient. Now go to the Hue/Saturation dialog and start dragging the Hue slider. You will immediately see that something weird is happening. For example, with Hue = 20 you get the following: In the middle of a perfectly smooth image two sharp edges have appeared. One could say it's a rendering or display artifact? No, it isn't. Launch the Hue/Saturation dialog again, reset Hue to 0 and drag the Saturation slider to the left end: In grayscale the new edges are clearly visible. So, adjusting the hue of smooth images (photos etc.) introduces weird artifacts which may make it impossible to use the hue adjustment at all. In fact, only Hue = 120 and Hue = -120 yield a smooth result. I guess I know why it's happening. It's the simplified algorithm of RGB to HSV conversion: saturation = max(R,G, - min(R,G, lightness = (min(R,G, + max(R,G, ) / 2 This algorithm is fast and reversible, but not smooth in the RGB and HSV spaces. In some areas of the image, for example, where R=G, even though the colors are smooth gradients, this algorithm introduces a crease. (Geometrically, in the RGB space the surface of constant saturation is a hexagonal prism, hence the creases). I guess it would be nice to use another algorithm which performs the color space conversion smoothly, without creases and edges. Something like: saturation = sqrt(R² + G² + B² - (R+G+ ² / 3) lightness = (R + G + / 3 In this algorithm, the surface of constant saturation is a cylinder, and no creases and edges should occur. On the other hand, this algorithm is not 100% reversible, i.e. after changing hue the resulting color may happen to be outside the RGB cube and will have to be clamped; but this happens only for extreme 100% saturated colors which are rare in real photos. And this will be compensated by the general smoothness improvement.

Hi everyone, I also used to have a specific palette layout in Paint.NET 3.x, and sadly versions 4.0 and 4.0.1 don't remember the layout. The main window size is also not restored. The only thing that is restored is whether the main window is maximized or not; if not, the window appears in a slightly different position every time the application is started. I miss this feature and will be happy to provide any feedback and assist in fixing the issue Windows 7 SP1 64-bit, Classic window scheme Dual-monitor system, the secondary monitor is on the left and has negative coordinates Microsoft .NET Compact Framework 2.0 SP2 Microsoft .NET Compact Framework 3.5 Microsoft .NET Framework 4.5.1 When installing versions 4.0 and 4.0.1, I did not notice anything unusual such as freezing "Optimizing performance" step. On Classic scheme it's impossible to change the color scheme in PDN settings. Other settings such as language, default tool, brush width and flood tolerance are stored and restored on restart. Since I installed 4.x on top of 3.x, I thought that something wrong may be left in the registry. I deleted the PDN registry key in HKCU, the application created it anew, but the window and palette positions are still not remembered.

If these are separate photos taken by hand, then they may need not just rotate/zoom, but rather perspective/distortion adjustment. In this case you could use panorama stitching software such as Hugin. It can analyze the images automatically or let you to manually place control points, and then adjust the images to fit perfectly. After that, it can combine the two images (or more) with optimal contrast and luminosity so that both dark and bright areas are visible.

Maybe it would be a good idea to store last used settings in the registry or something? In Photoshop, each plugin remembers its settings even after restarting the program.