Ed Harvey

This is very close to the generally accepted perceptual 'mid-gray' (Ansel Adams used 18% gray as his reference for judging exposure)

and it's one of the few I actually bothered to make an icon for.... typical

Some of the effects in the Ed Harvey Effects package have been incorporated in Paint.NET. However, in some instances the built-in versions have a simpler interface or less features. In these cases the original effects will be archived here for anyone who really needs those features... Fragment EdHarvey-Effects-Archive-Fragment-20080412.zip The built-in version has a simpler interface, but is functionally the same. Polar Inversion Plus EdHarvey-Effects-Archive-PolarInversionPlus.zip Some of the Plus features have been incorporated into the standard Polar Inversion. However, the original effect has additional options in the 'Edge Behavior' list (primary color, secondary color, transparent, original) Dents 'Classic' EdHarvey-Effects-Archives-DentsClassic.zip The original version of Dents. This version has a more complex UI than the one built into paint.net, and adds Stretch and Edge Behaviour options Dither EdHarvey-Effects-Archives-Dither-20100508.zip Ordered, Floyd-Steinberg and Atkinson Dithers. Warning: Floyd-Steinberg and Atkinson dithers do not play 'nice' with irregular selections Textile Texture EdHarvey-Effects-Archives-TextileTexture-20100709.zip Edit 2010-05-05: Added Dents Classic Edit 2010-05-08: Added Dithers Edit 2010-07-09: Added Textile Texture

Why do you think I put it in a tip? It is easy to miss...

Shift also 'snaps' the angle chooser in effects to 15° increments. A few 'hidden' features in the Ed Harvey Effects (where appropriate)... * Color Wheel [*:3enxn5vg]Shift - 'snaps' Hue to 15° degree increments [*:3enxn5vg]Ctrl - locks current saturation/effect-amount [*:3enxn5vg]Alt - locks current hue [*:3enxn5vg]Shift & Ctrl can be combined * Right-clicking on a primary/secondary color button selects a color of the 'opposite' hue. For example, if the button is red then right clicking selects cyan. * The up/down control on Hue wraps around from 359°<->0°

A subtle 'Extreme Makeover'...? [click on image for larger view]

No, 'built-in' types such as integer and floating point numbers are exempt from this limitation. Interestingly however, the System.Math methods are not inlined. I'm not 100% sure why, perhaps because they are ngen'd or in the CAG ? Cool. Last I heard they weren't due to fix that until the next version bump, so if it'll get into the SP that will be excellent... 8) Certainly will help (at least for the smaller, more commonly used, methods)

FYI, for those of us interested in perfomance. The current implementation of the JIT/NGEN compilers will not inline methods with value type arguments, local variables, or return values.

A maintenance release of the 'Ed Harvey Effects', updated for Beta 2, is available HERE

Yup, It's redundant... well nearly.The 'Plus' version has a few more options for Edge Behavior than the new built-in version. If these are important to you, then you can keep a copy of the 'Plus' version around...

Yes. I'll be splitting these effects out from the main package into a set of 'Legacy' effects; The effects have been simplified in places for the 'built-in' version, and some people may still have need of the original functionality...

I haven't tested them, but they should be ok.. I will check them tomorrow - it's 3:45am here in Australia, and I really need to go to bed

This is a maintenance release of the effects package. There are no new features in this build; It contains compatibility work for changes in Paint.NET v3.30 Beta 1, and a few minor bug fixes. EdHarvey.Effects.3.30.2980.8423.zip

How about this? It's not finished yet; It's part of a new set of effects I've been writing... EdHarvey.DrawingHelpers.zip

You have a lot of company. L-M discrimination difficulty is quite common... I cannot stress enough that these are very rough approximations! I wouldn't put too much faith in them, especially for 'diagnostic' purposes... but I'm glad you had fun with them

OK, here's a (very rough) approximation... These only simulate complete red or green deficiency. They do not cover the slightly more common 'anomaly' condition. You may be able to get an impression on the anomaly condition by overlaying the simulation over the original with an opacity of about 225. Remember these are only a rough first-order approximation, this algorithm is nowhere near as sophisticated as the one used by VizCheck !!! EdHarvey.ColorBlindness.zip

Yup, their code is almost directly lifted from the algorithm in the original paper they referenced. The results are, how can I put it nicely, 'rather average'. And their Tritanope simulation is just plain-wrong Which just goes to show that just 'cos someone goes to Stanford it doesn't mean that everything they do/write is brilliant (take note Google ) I'll try to get some examples up to show what I mean, but that will need to wait until later (got work to do).

What they said was to contact them if you wanted to Licence the algorithm; that is, pay them money for it! The theory behind this is not too complex... I'll have a play around and see what I can come up with. No promises though; I might not be able to get it to work

Exactly... No, it does not. There is no workable way around your problem... Pyrochild's code attempts to get around the first issue I raised and only create one copy of a work surface. Unfortunately there are a couple of problems with his approach. [*:28w4i20h]The code is not thread-safe, and it is quite possible that more than one work surface will be created :shock: [*:28w4i20h]The work surface that he creates is never disposed, and so the memory is not released until some later, indeterminate, time.

Tanel, I hate to break this to you, but this will never work as you intend Let's see if I can find a way to explain this; It's very late and my brain is turning into cream-cheese... Each call to Render() processes one or more rectangles (rios). Render will be called many times per image, possibly simultaneously on multiple threads, and the regions will not necessarily be processed in sequential order. This create several, fundamental, problems with your concept; [*:16x2zkp3]You are creating a new work surface each time Render() is called, so performance will be appalling, and you are likely to hit memory problems. [*:16x2zkp3]You are creating a new work surface each time Render() is called, so each work surface will only contain a small strip of the final image. When blur is called, it only has part of the info it needs to complete the blur; the lines above and below are missing. [*:16x2zkp3]Even if you were to find a way to create a work surface only once (a dispose of it in a timely fashion), you will never have the full image available for the blur. Is my explanation understandable?

If you are using XP, you need the Microsoft Windows XP Tablet PC Edition Software Development Kit 1.7 (don't you just love MS product naming?) If you are using Vista, I think the assemblies are on the install DVD; you may need to do an install of the Tablet PC Optional Components... Control panel >> Programs and Features , Turn Windows features on or off (in left hand task pane) Hope that helps..

Then you aren't looking hard enough Off Topic, but to be fair, it's only just over 2 years (2005-10-27 -> 2007-11-19) And you can't really make statements of entitlement like that, it's not like you paid for it

The most pervasive problem is that you have declared your working variables outside the Render method, and hence they are global Since these variables are being modified from multiple threads, the results are, umm, not nice... Repeat after me "Global variables are bad. Global variables do not play-nice with threads. m'kay"

Yes, pressure sensitivity works on XP Tablet PC Edition; In fact, that is the only xp version it works on... Pressure sensitivity is available on non-tablet pcs running Vista if you use a Wacom graphics tablet. I'm not sure if this was a special deal between MS and Wacom, or if Wacom just decided to add the Tablet PC interfaces as a product differentiator. Either way it's nice to have

Fix already coded... Just waiting for Rick to release the v3.20 Beta (just in case anything else breaks between now and then)