MJW

Thank you very much, Prensa, for your feedback, and especially for your clear illustrations and explanations. I wouldn't have been able to figure out what was going on without your previous comment. I'm not completely certain what caused the "blurring:" artifacts, but like you, I presume it was related to the edge-line artifacts. The one-pixel shift corrects a small problem with the old version, where the derivative was computed for the pixel to the left of where it should be. Now the derivative is centered on the pixel.

Thanks, null55. I'm glad to hear it doesn't crash, even though we don't know what change avoids the bug. If you want to make a non-CodeLab version, it would be very easy to do.

I finally found time to complete my changes to the CodeLab implementation of Normal Map Plus. The goal was to fix the edge-line artifacts when the zoom level doesn't show the entire image, but I'm also interested in whether by some chance it fixes the crash. My previous version now crashes on my system, though I made no changes to it since when it worked. Presumably that's due to a Windows update on my computer. So far, my new version doesn't crash for me. Perhaps some change I made happens to avoid the problem (or perhaps not). I made quite a few changes, and I haven't had time to do a thorough test, so nothing is guaranteed. For the DLL and the source code, please see the thread : NormalMapPlus (CodeLab Implementation)

The checkerboard is just Paint.NET's way of showing you that the area is transparent. It isn't part of the image. If you save the image, the checkerboard pattern won't be saved. If the areas were made white, you'd be unable to tell the difference between white regions and transparent regions. If you want white when you erase, create a lower layer and fill it with white. If you want to make areas white, not transparent, use the paintbrush instead of the eraser.

Posting to plugin threads is always proper, no matter how old the thread is.

Thank you very much, Maximilian!

In case it's not clear, my entry is my favorite summertime beverage, iced tea. I'm not sure the condensation on the glass "reads" as well as I might hope, especially in the somewhat reduced size from the original. I doubt have have more time to work on it, though.

Many, many thanks, AndrewDavid! That's exactly what I need.

Thanks for the info Eli.

Thanks Iron76. The problem is, I want to smoothly fade out some parts more than others in a very specific manner.

I'm trying to find a method to controllably make a region more transparent. What I want is something like the Eraser, but instead of entirely erasing the area, it would just decrease the opacity, so that multiple passes would be needed to erase a region entirely. Is there a method or plugin tool that can do that?

This is a short comment on the advantages of 24-bit height maps. A height-map is an image in which the color of each pixel corresponds to a height. Generally black represents the farthest distance, and white the nearest. Commonly, height maps are 8-bit-precision gray-scale images. (Color images are converted to gray-scale, by, for instance, using the intensity.) The problem with such a representation is that 8 bits is not sufficient to represent many smooth surfaces. This results in artifacts, such as waterlines where the levels change. It's somewhat like building a smooth surface, such as a sphere, out of Lego blocks. The solution is to combine the R, G, and B color channels into a single 24-bit number. This can be efficiently done in PDN, because the 32-bit ColorBgra colors are stored in what in the C language would call a "union." That is, the 4 BGRA bytes can also be accessed as a 32-bit integer. The integer values of ColorBgra colors can be obtained and saved using the Bgra field (e.g, src[x, y].Bgra). For 24-bit height maps, every color corresponds to a height. It may seem like there would need to be special handling for gray-scale height maps, but that isn't the case. Gray-scale height maps represent a subset of 24-bit maps; specifically, they represent the heights n * 0x010101, where n is between 0 and 255. Therefore, any plugin that can handle 24-bit height maps can also handle 8-bit gray-scale height maps. (Which is the main point I wanted to make with this comment: most height-map-type plugins can have the advantages of 24-bit height maps without alternating the way they work with gray-scale maps. That is, of course referring to the user's point of view; obviously the code would need to be modified.) Producing gray-scale height maps is quite simple, while producing full-precision 24-bit height maps is more difficult, since the height doesn't have an intuitive correspondence to the color. Full-precision height maps for simple objects, such as spheres, can be produced with plugins such as Render Sphere Height Map. The height maps can then be modified and combined using the Texture Merger. Gray-scale images can be smoothed into 24-bit maps using the the Texture Smoother. Plugins that want to treat images as 24-bit height maps can't use the normal interpolating Surface routines, such as GetBilinearSample, since those routines interpolate the color components individually, so I wrote some extension routines (called ZSurface.cs) to access the 24-bit height maps in a similar fashion:

I try to avoid using stock photos in my sigs, but this time I surrendered to temptation and used the following image: http://cdn.pcwallart.com/images/falcon-wallpaper-2.jpg

Believe me, toe_head2001, you efforts as host of OOTF are greatly appreciated. I didn't intend my comment as criticism, just as a suggestion.

I hate to be a stickler, but the rules for this topic require it be transparent glass: A transparent coffee cup would be fine. I don't think it needs to be absolutely transparent -- somewhat translucent is okay -- but I think the liquid should be visible through the glass. EDIT: I see that the specific requirements aren't listed on the topic thread. It would probably be better if they were, since it's possible not everyone checks the discussion thread. It may be unsportsmanlike to exclude entries that seem to qualify based on the topic description. I'm not sure what's the best thing to do.

You might also want to consider Paste Warp+.

I know exactly why the artifacts occur, and why they don't occur with a blank image. It's just a matter of fixing the problem. I knew the problem existed in the code, and added a comment about it: UL = (Float4)src[0, y]; // (This, and similar statements are wrong. Should be something like src[left, y].) Because I didn't know the visible ROIs are passed separately, I thought it would not matter as long as there wasn't a selection, which is almost always the case for this type of plugin. In line with my "direct port" approach, I didn't fix it.

It definitely helps, though I can't off hand explain how that could happen. I wonder if it's a less extreme manifestation of the problem that causes the crash. Maybe I'll be able to reproduce it on my system so I can investigate its cause more easily. EDIT: I had a thought (and this will only be meaningful to plugin writers). Perhaps for some reason PDN passes different ROIs depending on the zoom level. I don't know why it would, but it would explain this problem. I don't think it would expalin the crash, but I'll have to give that more thought. EDT 2: My assumption is now that PDN passes the ROIs for the visible region separately, perhaps either before or after the ROIs for the invisible region. That would explain the line-artifact problem. I don't have time to fix it now, but I'll try to make a new CodeLab version tonight. The code could then be easily converted to the non-CodeLab version.

Unfortunately, thanks to Photobucket, I can't see the artifacts being discussed. If you could describe them, or better yet post a picture, it would helpful. In theory, the zoom level should have no effect. The plugin has no idea what the zoom level is, and always gets and sends the same data no matter what it is.

A useful trick when using the Text tool is to type the text, set a reasonable font size, then open the list of Font styles. Put the mouse cursor over a style, but don't click. Instead, use the Up and Down keys to move among the styles. Before BoltBait mentioned this method, I spent a lot of time clicking one style at a time until I found the one I liked.

Oh, I see. Thank you. I'll probably take a look at the code. The fact that it's based on GPU code probably explains the rather odd way it treats each of the color components the same way, rather than just computing in some fashion a singe height from each color, then using those to calculate the derivatives.

Null54, I'm not clear on what improvement is being suggested. That is how the plugin computes the derivative, and I think it's a pretty good method. Well, actually, the plugin stores the results one pixel to the right of where it should, since it saves the nine neighbor pixels in variables at the end of the loops, then increments x. That should be fixed.

The problem doesn't occur on my system, so I can't debug it. One thing I'd try if I could debug it is removing the line: [StructLayout(LayoutKind.Sequential)] from the Float4 definition. The line should be harmless, and I believe it's the default, but it's also not necessary. The only reason I suspect it is because it's one of the few usual things I see.

I should have read the preceding posts more carefully, since I missed that there was a already working version. That does, however, solve your problem: use null54's version. In any case, the time I spent looking at the plugin may not be wasted, since I may be able to improve it.