oblivioncth

Ah my mistake. I was under the impression that C# primarily used an interpreter like Java (though that can be implemented as a JIT too) after being compiled to its intermediary, but it seems that C# is always compiled down to native byte-code on the target machine.

Thanks for elaborating. I'd assume the tolerance percentage corresponds to this as some simple form of percent difference, but with 0 and 100% as exceptions to match only the exact color and match all colors respectively? Or is it as simple as 0% -> 0 and 100% -> 255? EDIT: Seems to be a simple scaling of x/100 = y/255 according to the magic wand source (with some additional quadratic shaping from "FastScale()" in its case). Man I wish C++ bytecode could be disassembled with this much detail in-tact . Obviously impossible since C# is interpreted by a VM and C++ is compiled all the way down

It probably is just so it's simpler, which would explain some of the oddities with it. That tool looks incredibly useful, is it this you were referring to? https://github.com/icsharpcode/ILSpy I'd be interested in using it to see more, particularly what distances are considered included for what percentages.

Ah, that's a great starting point. Thanks.

I've begun studying it by seeing how many up-ticks of tolerance it takes for the next pixel to be affected in a gradient (of hue, sat, light, or combinations of them) where each pixel is only 1 higher/lower than the previous, but at the point I've gotten to it seems that the transform for whether a pixel is included or not is not linear (though this in part is most likely due to the rounding that occurs when ticking H/S/L up and down, perhaps I should start with just RGB. And additionally there will be some relative scaling due to the tolerance slider being percentage based) So, given that this means reversing it will take longer, I figured I'd simply ask if I could know what the algorithm paint.net uses for its tolerance level inclusion/exclusion calculations is (i.e. for the magic wand, paint bucket, etc.). This is assuming no anti-aliasing (though that part would be nice too). I'm making a plugin that needs a tolerance slider and I want the behavior to be as close to the standard tools as possible; however, given that the implementation of this feature is potentially something that separates Paint.NET from its competitors, I can understand if whoever knows it would rather not share.

Imo this wouldn't make it anymore complicated for a plugin developer, though I can understand it does make the code a little more complicated. Perhaps my situation is just a bit specific and what I want wouldn't be helpful that often but: BoltBaits suggestion is what I do in my plugin now to get around this; however, my plugin largely has to do with doing HSL adjustments to match colors with its primary usage being to select the color you want to change as the primary color and the color you want to change to as the secondary color. Because of this I feel like it makes much more sense to simply have 2 color pickers on my dialog that always default to the primary and secondary colors when its opened so that they can still be tweaked if needed but often will simply act as a reminder on what you're about to change and make the use of the plugin more intuitive, also avoiding the need of an additional dropdown box or radio group. Yes you can see the primary and secondary colors in the color window while using the plugin, but the window is faded and information that is critical to using the plugin correctly is then kind of just in the back out of focus instead of prominently being displayed directly. I just found it strange that Paint.NET doesnt litterally just repeat an effect with the exact parameters used before when using Ctrl+F and instead does grab these parameters from the previously edited token, but does so by repeating the effects UI initilaization portion of its code so that what your options for what the user sees in the UI and what is actually in the "history" token are one in the same and inseparable, as this is not how I would have done it personally. Though again this is just my opinion. Perhaps many people would prefer the current behavior despite it not being how I imagined one would use this plugin.

Ah nice! Thanks a bunch EER. This current plugin is pretty simple and while its effective it was also kind of an experiment for me in getting started on these plugins in case I want to make more. So for this one I'll just wait on Paint.NET to eventually update if they do end up putting this feature in; however, I can easily see myself wanting to do a more complicated plugin at some point that will need to make use of these.

While working on a plug-in I realized that I have the same problem that ReMake talks about in that I'd prefer the Color wheel get reinitialized with the current Primary color each time the effect windows is brought up. I am able to use the strategy BoltBait mentions in that thread to get around its current behavior and always grab the primary color, or offer the user the option to use the primary color or the color in the wheel through a radio button group, but it just isn't as clean, especially since the color in the color picker won't get updated even if the user selects the primary color option (unless there's some way to grab the instance of whats rendered onscreen and change the form parameters through the IndirectUI framework that I haven't caught onto yet, though I don't think there is). This doesn't ruin the plug-in, just makes it a bit awkward. Reading through this thread lead me to develop a few thoughts/ideas. BoltBait listed two main reasons as to why the effects behave the way they do currently: 1) Many effects rely on the convenience of being able to use them multiple times, perhaps often with slight changes, so the convenience of being able to reopen the tool and have the previously applied settings retained in the window is significant 2) As an extension of the above, changing this behavior and this behavior alone would potential break Ctrl+F depending on the plug-ins intended use since using the "Repeat...X" option would use the new colors instead of the old ones. Point 1 is just a side effect of how the current token system works (from what I understand and what BoltBait explained) and I can't see being any trouble to change as the PropertyEffects could just be fleshed out a bit more to include a true/false parameter (which then could be forwarded to an option in CodeLab) on whether or not to hold the previously used values or reinitialize from default. No problem. Point 2 on the other hand surprised me a bit and made me want to share a small thought on the matter and how Paint.NET handles this. I can see now how this would definitely break Ctrl+F currently as I mentioned above, but what I had assumed is that Paint.NET would have handled this in a slightly different way that would have enabled the behavior ReMake and I desire(d) without breaking the repeat option: For the moment, lets pretend that this is older Paint.NET and there is no effect preview. When you select the effect in the menu for the 2nd, 3rd, etc. time the program pulls the previous parameters from the appropriate tokens to populate the UI controls and then runs the effect when you press OK. Pressing Ctrl+F achieves the same as it checks the same tokens and then applies the effect with those parameters. What I'm suggesting is that if this new flag that is exposed to the IndirectUI is set to false (or whatever the default would be), this behavior stays the same, but if true, the parameters within the UI will be reinitialized to the specified defaults; however apply this to the UI only and always retain the previously applied settings in a separate token or some other kind of memory, having the Ctrl+F repeat function draw from those values instead. This way, the UI in the effect window has the option of showing the values applied in the previous effect usage OR the defaults depending on the wishes of the plug-in developer, but the Ctrl+F function isn't broken. I can't imagine that this would change things too much at all and would simply add a KB or two of ram usage and just require some small changes in references for the effect window and repeat option related functions. Now, this would be a tad dicey when you take into account the effect previews, except all that would need to be done is change the preview so that it uses the parameters specified in the UI as well instead of the parameters stored in the previous use token. Only have the token get updated when the user actually commits by pressing the OK button. This way if they hit cancel then the token hasn't been changed and hitting repeat later will still result in the effect being applied with the previous parameters. I guess what I'm saying is, if you separate the parameter storage so that you have a dedicated token for the repeat option that only is updated when the user hits the OK button on an effect, not pulled from the plug-ins UI initialization routines and therefore not overwritten every time the user changes the primary color in this usage example, you would be able to maintain the repeat option's current behavior while adding the option for plug-in developers to reinitialize the values shown in the UI of their plugin (and there only) whenever the window for their effect is created. Essentially, keep the UI to itself is what I'm saying. I do understand this may have some implications on the programs Undo functionality that I haven't touched on, but I can't see that being too bad to handle either unless I'm being dumb and missing something. Anyone that helps develop Paint.NET have any thoughts on this matter, whether it be feasibility or potential issues? Or does anyone else find this feature to be useful? Believe me I could overlooking something huge here and I also don't know how a lot of the programs functionality is handled behind the scenes, but from what I understand within this scope at least I feel like this could be a relatively simple change that would enable a tad more flexibility in the IndirectUI.

Thanks for all of this clarification, its starting to give a me a good sense of things. I wasn't aware exactly what IndirectUI was until now but that makes total sense, its just the framework that exposes some pre-made UI options to plug-in creators, which also basically wraps up why CodeLab is setup the way it is. This also confirms my suspicions that more back-end work with the .NET WinForm controls would need to be used to acheive this. I can start looking into that as well as the library you linked. Great tip for leaving the description blank as that allows for a somewhat decent temporary solution until I can achieve something more robust. Oh my apologizes I didn't realize as the way that Midora talked about it in that post made it sound like something he was considering implementing but hadn't yet, but I now realize that he was simply saying he was considering outsourcing that particular feature of his library as a standalone plugin. The link to your plugin source will also prove very helpful I'm sure. In this regard, I was refering to the style for a potential separate Trackbar as you mentioned, forgive my phrasing, referring to the fact that even if I could get a TrackBar to be grouped in with the color picker (which I now can thanks to your tip) that it wouldn't have the alpha control style applied to it and wouldn't reflect its value on the color preview square. Thanks again for all this, as it gives me a direction to go in order to figure out more on my own. Based on what I've learned from the above quote, I'm assuming that you mean that the next version may include an Alpha slider inclusive color picker as one of the options for the IndirectUI? Regardless of whether this happens or not, is there any kind of timeframe or development cycle schedule that Paint.NET tends to follow that gives a sens of how far along each release is? Or is just more of a "when its done" kind of thing on Rick's part? While Midora's library looks very promising, it would be cool if this feature became part of the regular library as well. Thanks to you too.

Hi guys, I'm not new to C, but I'm completely green when it comes to Paint.NET plug-ins and the .NET framework. I was hoping that someone could give me guidance in achieving a color picker that also features an alpha selector for the simple plug-in I've been working on. The plugin is practically finished, and is entirely rigged up to work to spec on the back-end, but the small amount of alpha value manipulation I perform is currently nixed because of the way the default color wheel/picker for plugins functions. I've been following the development guidelines on the forums, such as this thread: https://forums.getpaint.net/topic/109990-how-to-write-an-effect-plugin-tutorialsresources/ as well as the great information over at boltbait.com for CodeLab, all of which has helped me get used to most details regarding plug-in development relatively quickly. The one thing I can't seem to find much on however, albeit, I can understand as this kind of assistance can easily become tedious/complicated very quickly, is how to customize the UI elements of your plugin further than what CodeLab allows for by default. I built 90% of my plug-in with CodeLab and then did some debugging and tweaking in Visual Studio, both of which were ultimately no problem, but I am now stuck because I just need to add a simple extra bar to the left or right of the RGB bars for the default color picker element and I'm mostly at a loss as to how to do that. My two color pickers initialize based on the currently selected Primary and Secondary colors in the main color picker, but their Alpha values are totally ignored and always set to 255, hence this requirement. From the bit of poking around I did, I know I could an integer slider from 0 to 255 below the color picker and intercept the assignment of the "Amount" variables that CodeLab uses to have the slider set to the actual alpha of the selected colors by default, and then overwrite the 255 value with the actual Alpha value when I retrieve the pickers value. protected override void OnSetRenderInfo(PropertyBasedEffectConfigToken newToken, RenderArgs dstArgs, RenderArgs srcArgs) { Amount1 = ColorBgra.FromOpaqueInt32(newToken.GetProperty<Int32Property>(PropertyNames.Amount1).Value); Amount2 = ColorBgra.FromOpaqueInt32(newToken.GetProperty<Int32Property>(PropertyNames.Amount2).Value); // Alter Amount 1 and 2 here Amount3 = newToken.GetProperty<BooleanProperty>(PropertyNames.Amount3).Value; Amount4 = newToken.GetProperty<BooleanProperty>(PropertyNames.Amount4).Value; Amount5 = newToken.GetProperty<BooleanProperty>(PropertyNames.Amount5).Value; Amount6 = newToken.GetProperty<BooleanProperty>(PropertyNames.Amount6).Value; base.OnSetRenderInfo(newToken, dstArgs, srcArgs); } But this is crappy because its a bit hacky, doesn't show the change in Alpha on the rectangle preview of the color wheel/picker, and when implemented using CodeLab (only way I know how right now) it puts a separator between the color picker and the slider (normally this is fine as its supposed to be another section but in this case I'd want them grouped. In particular, I see what the color picker comes from one of Paint.NET's own classes: using ColorWheelControl = PaintDotNet.ColorBgra; ... ColorWheelControl Amount1 = ColorBgra.FromBgr(0, 0, 0); // [PrimaryColor] Source Color (Translate From) ColorWheelControl Amount2 = ColorBgra.FromBgr(255, 255, 255); // [SecondaryColor] Destination Color (Translate To) Is there a way I can my my own version of this "widget", or extend the functionality of the current one? If not, is there a somewhat simple or at least logical way I can still use this built in class and just tack on another slider right next to the current ones, unlike how I'd have to with I'm sure this is probably a bit into the realm of .NET framework in general and understanding the implementation of form controls, its just that the only other mention of something like this I've found is what's essentially "concept art" by another user on the forum: https://forums.getpaint.net/topic/28112-indirectui-colorwheel-with-alpha-selector/ Funny enough, this is exactly what I want. Its basically the programs main color picker just without the pallet and the HSV info, particularly in that it is linked with the square color preview and shows the transparency. I've seen much more detailed or reorganized plugin's developed by others in the past that suggest to me that this should be possible. So does anyone have the knowledge to point me to a tutorial for this, get me started, give me a direction, etc? Or at the very least know a good resource where I can learn how to modify the menus within Visual Basic effectively (I see where some of the manipulation is as I pointed out earlier but I'm obviously completely oblivious when it comes to a lot of the intricacies, naming conversion, back-end behavior, etc. so that I can get passed the limitations of CodeLab despite how convenient and effective it has been for me so far? I see they added slider style presets which aren't mentioned on their site (it notes that in CodeLab you can't theme a slider even though you now can), but the alpha scale checkboard pattern isn't one of the options. The writer(s) for that site mention that you can at least skin the sliders different ways with in VS, they just don't mention how. Sorry this was a bit wordy, thanks for any help to the Paint.NET noob.