pikalek

Thanks for the clarification - I was pretty sure, there was still the chance I had missed something. Plus, others now know as well. As BoItBait pointed out, I do have some alternatives, so I can still get by using the IndirectUI & if I really can't live the alternatives, I could always brew my own UI with Visual Studio. Anyway, I imagine it's called IndirectUI for reason; while having a little more control would be convenient for my situation, there's probably higher development priorities than adding a new rule.

I could, but the result is not as precise as I'd like as the user cannot consistently indicate how many pixels to shift the selection by. Your idea is certainly a good one & is on my short list alternatives. I'm still interested in knowing if IndirectUI can solve this problem directly though.

Is it possible to dynamically change the min/max property of a slider control generated via the IndirectUI? Specifically, I want to limit a max value based on the bounds of the selection region. I tried using some astronomically large limit & then clamping the amount; this worked, but the UI felt like it handled poorly; most of the slider range becomes functionally useless & the usable range becomes very 'touchy'. Using a smaller limit helps, but then it hamstrings the plugin with an artificial limit. Reviewing the archives, I found a related, older discussion on changing UI control values using IndirectUI, but I don't see how the SoftMutuallyBoundMinMaxRule would help my problem since it only involves one control. Can I coax this behavior out of the IndirectUI via clever programming or some other IndirectUI?

I could see some plug-ins making good use of that. While jumping through the hoops required more up front time and frustration, it also meant that I had get a better handle on the framework sooner as opposed to later.

Below is the starting reference image: Below is the result from the plug-in's scale2X filter: Below is the result from the plug-in's scale3x filter: Below is the result from the plug-in's 2xSaI filter: Below is the result from the plug-in's Super2xSaI filter: Below is the result from the plug-in's SuperEagle filter: Below is the result from the original 2xSaI implementation. Note the black line artifacts along the top & bottom and the color bleed along the upper right edge. The original implementations for Super2xSaI & SuperEagle give similar artifacts.

Provides various pixel art scaling algorithms used in many console emulators. It's intended for enlarging low-resolution pixel and line art; use on other images may give strange results. The original Scale2x and Scale3x algorithms were developed by Andrea Mazzoleni. The original 2xSaI, Super2xSaI and SuperEagle algorithms developed by Derek Liauw Kie Fa (aka Kreed). There are slight differences between my implementation Kreed's algorithms and the originals. I use the nearest valid pixel for the out of range neighbor problem. The original code uses zeroed out pixels for top and bottom out of range neighbors (resulting in the black line artifacts at the top and bottom edges) and edge wrapping for left and right out of range neighbors (sometimes resulting in color bleed along the left & right edges). The my implementations of the Super2xSaI & SuperEagle filters do not currently work as desired. It seems like I'm interpolating differently, but I haven't found the source of the problem. Helps to check the results carefully; turns out I did fix this problem before releasing the beta. Issues I'd appreciated feedback on: I'm not sure which sub-menu would be the best home for this effect. I was unable to associate an icon with the plug-in using Visual Studio 2005. Figured it out. I considered adding a safety check box - the basic idea is that the user would need to check the box to enable the 'Send to Clipboard' button & that the box would clear in between 'visits' to the plug-in. I got impatient trying to set this up via the IndirectUI & figured maybe it wasn't a good use of time. The original algorithms were developed in GPL projects. I wasn't clear if my code would also be GPL (I.E. if my reimplementation different enough). It was even less clear how such licensing on a plug-in would mix with a non-GPL project like Paint.NET. I don't expect anyone to debug my Super2xSaI & SuperEagle filters, but you're welcome to surprise me. It's my first plug-in; if I've made any noob mistakes, don't hesitate to tell me. Possible future improvements: Add support for other related algorithms Add more options for the in place scaling within a selection Add selection masking when sending the image to the clipboard Fix bugs in the Super2xSaI & SuperEagle filters. Update plugin to reflect the previous code fix. PixelArtScaling-BetaLight.zip

Is it permissible for an Effects plugin to change the contents of the clipboard? If not what is the recommended way to handle an effect where the output is larger or smaller than the input? (for instance, pixel art scaling algorithms or seam carving)