Kill Color v1.1 (Update: 23.02.2009) -- BUGFIX, new option

[HiPhiSch]

Description:

This plugin removes a color from the selected part of the image and tries to find a substitution for it by analyzing the surrounding parts.

 

Download: https://www.dropbox.com/s/exmcdhpt35e07j5/Kill_color_v1_1.zip?dl=0

 

Source code (for programmers): https://www.dropbox.com/s/wgaptwrkqyz68pf/Kill Color_source_v1_1.zip?dl=0

 

Changelog

v 1.1:

* BUGFIX: "Tone Amount" now working as supposed

* New option "Keep only pixels that changed" added

=> very useful duplicate layer first, use plugin on new layer with this option checked

* Source Code is now available

* Tweaks in how "Tolerance" and "Tone Amount" are working.

Screenshots:

Example 1:

 

(Parameters for this one:

Color (R, G, : 190, 189, 187 (Picked with :ColorPicker: from the image first)

Tolerance: 30 (for v1.1: maybe ~70)

Tone Amount: 30 (for v1.1: 100, a bug was preventing toning in v1.0)

Radius: 40

Precision: 20

Relevance of Proximity: 60 (Less blurry)

Relevance of Colordifference: 60

Weight (Replacement): 40

Weight (Selection): 25 (Low saturation is more important than brightness)

Assume Transparency: 0 (The fence is solid and has no blurred out edges)

)

Example 2:

 

(Properties for this example:

Color (R, G, : 38, 127, 0 (Picked with :ColorPicker: from the image first)

Tolerance: 0.01 (Just one color used) (still o.k. for v1.1)

Tone Amount: 30 (would be 100 in v1.1 (toning was not working in v1.0))

Radius: 40

Precision: 20

Relevance of Proximity: 60 (Less blurry)

Relevance of Colordifference: 60

Weight (Replacement): 50

Weight (Selection): 50

Assume Transparency: 0 (Splatters aren't transparent)

)

User Interface:

 

Hints on Usage:

* Select a color first

* Tone amount and tolerance let you control on how much the image is altered. A bigger tone amount causes similar color tones to be stronger affected. Tolerance defines a minimum change in the color so that the pixel is affected at all.

* Radius and precision affect how many pixels in the surrounding of the altered pixel are used to estimate a replacement color.

* Relevance of colordifference and proximity settings affect how the replacement color is estimated. A large value for the first one will give stronger weight to colors with a larger difference in color and intensity. Setting the second one to a larger value will give the direct surrounding a higher weight for the replacement color.

* The weight (color <-> intensity) sliders influence what is considered more important as difference. 50 will give a balanced weight, 0 will just look at the tone and 100 at the lightness. The selection property influences which pixels are affected, the replacement option influences how the pixel in the surrounding (used for replacement) are weighted.

* Assume transparency can be used if the surrounding is toned a bit with the color.

* The "keep only pixel which are altered" option (v1.1, scroll down to see it) will only keep pixel that are affected by the algorithm. The remaining pixels are set as transparent. Also instead of toned pixel color, the alpha is set to a corresponding value. This makes it easier to modify the outcome in a second step afterwards.

* The algorithm includes converting RGB values to CIELab values. This is time consuming and therefore the plugin tries to cache the whole image in CIELab values during initialization. If this is not possible (low on memory) the plugin will still work but get significantly slower. To speed up a bit aliasing will then be performed for RGB and one conversion with this bilinear sample will be used for calculation. If you remove the check from the checkbox you can set the plugin to do the aliasing after CIELab conversion. This will slow down the calculation with probably a factor two or three but the resulting image is identical to what you get, if caching were possible.

Suggestions:

* Duplicate the layer first and use the "keep only pixel which are altered" (since v1.1). Effects (like a Gaussian blur and correction of areas youd don't want to be affected, can than easily be achieved)

* Don't increase radius too much if not necessary (e.g. for larger areas of the color you want to remove). The result will become much more blurry and it takes longer.

* For images with low structure decrase the relevance of proximity and increase it if the altered parts look blurry.

* If the replaced color has some strange toning you probably assumed too much (or less likely too few) transparency.

* Play around with the two weighting sliders (and tone amount/tolerance, relevance of colordifference). I first tried it out at some selected parts of the image and afterwards applied the effect to the whole image.

Technical Details:

* CIELab is used to compare colors and calculate colors. Therefore the plugin tries to cache the image in CIELab format.

* The color you want to kill is compared with the pixel colors. The difference in combination with the tone amount value determines the change of a pixel. If the difference is below the tolerance value (some scaling is involved here) the pixel will stay.

* Precision and radius determine a number of pixels surrounding the pixel that should be changed. A weighted average of the color is determined. The weight is calculated from a distance factor, a color difference factor, and the alpha value.

* The distance factor is something between one (relevance of proximity zero) and pow(distance,-3). (Calculation is discrete for speed reasons, no Math.Pow() involved)

* The color difference factor is determined by difference(ColorToKill, ColorFromSurroundingPixel). Weight(color <-> intensity) and relevance of colordifference have an influence on this function.

* The source is not documented and quite messy. If you are interested nevertheless just p.m. me. I plan to rework it a little and put it online later on. The source is now available. Grab it if you are intersted.

Future plans:

* Optimize the loop structure, for better memory access => increased speed.

* Optimize the bilinear interpolation, that transparent pixel will be excluded already for the bilinear filtered values.

* A CUDA implementation (seems to be possible from first tests, but will probably take some time for me to write it)

Have fun,

Philipp Schäfer

 

Edited July 11, 2018 by toe_head2001
Fixed broken Postimg images

[LFC4EVER]

You know what? This is awesome. Sort of kills (no pun intended) the need for InPaint. Thanks for the awesome looking plugin!

*goes and tests*

[Blooper]

Holy potato.

[LFC4EVER]

XD

Original

[007 Nab]

Excellent effect - will certainly try this out.

[davidlee9288]

Woah this looks really amazing dude

Ima try it out now

[Andrew D]

That title sounds like a Billy Mays advert, lol.

Anyways, look fantastic, if it works very well then this could put Paint.NET in a position to trump GIMP, and mabye even Photoshop

[Frozen_byte]

This is awesome! Really!

Thanks, a lot!

This makes the Stamp tool unnecessary :3

[TheDutchJewel]

Download:

[attachment=1]Kill_color_v1_1.rar[/attachment]

[attachment=0]Kill_color_v1_1.zip[/attachment]

[attachment=2]Kill Color_source_v1_1.rar[/attachment]

It seems something went wrong with the attachements. Can you fix it, please?

[Ego Eram Reputo]

Images rehosted. Thanks to @ReMake for making them available.