The Math Behind Photoshop's Unsharp Mask and Gauss

[Drazick]

Hello,
Has anyone succeeded in reproducing Photoshop's Gaussian Blur and Unsharp Mask?

I have a technique to apply a really nice Local contrast Enhancer based on Unsharp Mask yet I have to reproduce Photoshop's first.
I reproduce Photoshop's Unsharp Mask using some math on layers and the Gaussina Blur.
Assuming 'O' is the layer we want to apply USM on then:

USM('O') = O + (O-GB) - inv(O + inv(GB))

Where GB stands for a Gaussian Blurred version of O.
Subtractions and Addition can be done using Photoshop's 'Apply Image' command.

As you can see this is not the "Classic" Unsharp Mask.

Has anyone reproduced it in C / Python / MATLAB?

P.S.
I'm asking here because I know many people here have a deep understanding about the math of Photoshop and how things works internally.

Thank You.

[Der_W]

Re: The Math Behind Photoshop's Unsharp Mask and G

Your formula seems to have one too many inv() in it I think.
USM('O') = O + (O-GB) - (O + inv(GB)) works fine and is a 1:1 representation to USM with 100% strength, the Gaussian blur radius and 0 threshold.
Photoshop's Gaussian blur is quite heavily optimized for performance, therefore the "correct" algorithm will give too weak effects: http://www.hackerfactor.com/blog/ind...The-Lines.html

[Drazick]

Re: The Math Behind Photoshop's Unsharp Mask and G

Hi,
I went according to this:

http://www.lynda.com/Photoshop-tutorials/Building-your-own-USM-Gaussian-Blur/543/34451-4.html

And he does the "Extra" inverse.
I will try later without to see if it does work :-).

Moreover, if inv(L) = 1 - L (Assuming images normalized into [0, 1]) your equation is:

USM('O') = O + (O-GB) - (O + inv(GB)) = O + O - GB - O - 1 + GB = O - 1.
Which isn't USM by all means.

What strange, my equation yields USM(O) = 3O - 2GB.

It's strange, really strange.
Am I missing something? Maybe I'm wrong about the inversion operation?

[klev]

Re: The Math Behind Photoshop's Unsharp Mask and G

What is your bit depth? You mention 0 to 1 and add/subtract, but that only works with linear float values. If you're using 8 to 16 bits per channel in photoshop, the working space and encoding of the image both have baked gamma, so you will not get the right results from standard addition and subtraction. Half floats are also unsupported. PS just promotes them to 32 bits, presumably by zero and sign extension.

Any reason for mentioning python apart from its math libraries?

[Drazick]

Re: The Math Behind Photoshop's Unsharp Mask and G

I'm just trying to implement Gaussian Blur and USM as close as possible to Photoshop.

[Drazick]

Re: The Math Behind Photoshop's Unsharp Mask and G

Ok,
I think I'm getting close.

Using Photoshop's GB Impulse Response I think I have something close to how Photoshop's Gaussian Blur is working.

The size of the filter is M X M where M = ceil(radius).
The Std of the kernel is radius / 3.

The USM is given by:
USM(O) = O + 2 * (Amount / 100) * (O - B).

Didn't figure out the Threshold yet.

Someone has something better?

[klev]

Re: The Math Behind Photoshop's Unsharp Mask and G

You're just hacking random stuff, and you're going to introduce artifacts with that formula, although it may be close. Maybe that's why I dislike the look of PS's sharpening. The MxM thing is how all resampling algorithms work. If you're interested in the topic try reading some of gpu gems or glassner's graphics gems series.

[Drazick]

Re: The Math Behind Photoshop's Unsharp Mask and G

Klev,
I was wrong with the formula.
It's M = 2 * ceil(Radius).

You have at least 3 sigma as radius, the Gaussian is practically 0 outside it.
Though probability they use IIR filter for that.

What's interesting is using inv(L) = White - L:

USM(O) = O + (O - B) - inv(O + inv(B)) = 2O - B - (White - (O + (White - B))) = 2O - B - (White - (O + White - B)) = 2O - B - (White - O - White + B) = 2O - B - White + O + White - B = 3O - 2B = O + 2(O -B)

Though using Apply Image yields different results.
I mean, create (O - B) ussing Apply Image (Subtract)
Then add (O - B) to O twice using Apply Image (Add).
The result isn't USM.
What's wrong?
Is it just the clipping in each phase?

[klev]

Re: The Math Behind Photoshop's Unsharp Mask and G

Are you in 32 bit mode? If not add won't work as you expect, nor will subtract. It doesn't matter that you're using apply image to set them.

[Drazick]

Re: The Math Behind Photoshop's Unsharp Mask and G

Hi,
Photoshop doesn't allow Subtract and Add in 32 Bit mode.

So, If I have the photos in MATLAB, how should recreate this?
Should I clip into [0, 255] / [0, 1] after each subtraction / addition?

It sounds weird that the code USM does clipping into [0, 1] / [0, 255] after each step.

[klev]

Re: The Math Behind Photoshop's Unsharp Mask and G

Hi,
Photoshop doesn't allow Subtract and Add in 32 Bit mode.

So, If I have the photos in MATLAB, how should recreate this?
Should I clip into [0, 255] / [0, 1] after each subtraction / addition?

It sounds weird that the code USM does clipping into [0, 1] / [0, 255] after each step.

Use layer blending modes linear dodge and subtract rather than apply image. I was completely serious that the way you're doing it mathematically unsound. Even if Adobe did something that way I wouldn't suggest it. It's because you're dealing with unevenly spaced values using a blending mode that is designed for evenly spaced distributions. As mentioned photoshop isn't exactly the place if you want to really see the underlying math. If you plan to make adjustments to images with gamma encoded, you have to account for that. Even in matlab, you can remove it, which some software does internally due to some programs being based around linear calculations. If you plan to address linear values, which is really quite a bit easier, both the image itself and the workspace have to be that way, and you have to to verify it.

Oh as far as clipping I'm not sure how I would approach that one if the clipping is necessary. IT depends on the final destination of that tool. If it is to be applied in 8 and 16 bit integer modes, you do have the issue of overflow. There isn't a good way to store anything beyond that without introducing a very large performance hit, so I doubt Adobe does so. I have to assume they're packed in some way so as to store more than one 8 bit pixel in a given register either by packing channels (RGBA) at a given index or tiled when it comes to making general computation that is to be performed by a cpu.

[klev]

Re: The Math Behind Photoshop's Unsharp Mask and G

I'm just going to add that clipping at every step actually introduces a lot of artifacts. Trying to reproduce this is just the worst possible idea. Adobe's algorithms have been updated to a degree over time. Their early ones were really based on what was available. They had to work with a limited range of values and severe performance constraints. People older than myself have indicated just how long it took to apply certain filters or transformations in the era of Photoshop versions 2 - 3. If you really wanted to do this, you should try a linear raw processor like dcraw or darktable, preferably one that can process to an exr, as they recognize a specific sign bit. Take that. Correlate it with something like a munsell greyscale system to ensure you have a reasonable gain. Take that into matlab. Research your algorithms from there. Apply the sharpening before gamma. Evaluate both visually and numerically to ensure against corner case issues where the data blows up. From there is this is to be applied normally to lower dynamic range gamma encoded data, you want to attempt to match those initial results with something that can be applied to gamma encoded data, meaning you can no longer use add and subtract.

That's a bit more detailed explanation, but I have to ask, do you have any programming experience or math background? Graphics are one of the most math heavy areas of programming in general. Coming up with a new sharpening algorithm would be way beyond my own comfort level, as you have to account for the issue of ringing/haloing and over what radius it would be acceptable. Typically that is what is happening, but it doesn't matter as long as the viewer can't perceive it. If I wanted to do what you're attempting, I would be looking at existing research on the topic, as I don't think you'll learn anything from the way you're going about it.

[Drazick]

Re: The Math Behind Photoshop's Unsharp Mask and G

Klev,
I really don't understand you.
I showed you how Adobe Photoshop creates USM using Gaussian Blur.
The way I showed is 100% identical (Put it on difference mode and see everything is zero).

Now, if no clipping is done all sums up that USM(O) = 3O - 2B.
If clipping is done, this is explanation why doing O + 2(O-B) using Apply Image doesn't reproduce the same effect.

This is the contradiction I'm after.

Adobe applies all filter on the image on screen.
No need to do Gamma inversion for those kind of filters.

[Drazick]

Re: The Math Behind Photoshop's Unsharp Mask and G

Regarding your question, I have math background mainly with MALTAB programming skills.

Now my problem mainly deals with how does Photoshop translates the user's Radius parameter into the size of the Gaussian Blur Filter and its Standard Deviation (Sigma).

I'm pretty sure the use some approximation for the Gaussian Blue (IIR or Box Filters).

Yet still I wonder how they translates the parameter.

[klev]

Re: The Math Behind Photoshop's Unsharp Mask and G

Klev,
I really don't understand you.
I showed you how Adobe Photoshop creates USM using Gaussian Blur.
The way I showed is 100% identical (Put it on difference mode and see everything is zero).

Now, if no clipping is done all sums up that USM(O) = 3O - 2B.
If clipping is done, this is explanation why doing O + 2(O-B) using Apply Image doesn't reproduce the same effect.

Don't mind me. I noticed my posts have taken on a grumpy tone today, although that wasn't intentional. Strangely I didn't think of difference mode. As mentioned they would have to clip at typical bit depths due to no way of otherwise handling out of range values.

This is the contradiction I'm after.

Adobe applies all filter on the image on screen.
No need to do Gamma inversion for those kind of filters.

Ahh they do hack some things a bit that way, such as screen blending, which uses strange math. I actually said they formulate it to work on gamma encoded images. I just added that it can produce a certain number of artifacts due to the nature of what is being done.