Barely StL wrote:
The photo was shot in RAW, retouched as a TIFF file, then saved and resized as a JPEG.

My apologies for the mistake.

This photo is obviously an extreme example, but if you look closely at the rest of your portfolio you can also see precursors to this in the transition areas of images; particularly the warmly-lit ones.  In all cases, it is almost certainly the result of JPEG compression at some point in your workflow prior to upload to MM, as JPEG uses an 8x8 color compression matrix, and while these artifacts are obviously square, they are smaller than 8x8, meaning that it happened before you resized.

If you look at the blue channel (or, better, the a* or b* channels in LAB) of the original image before resizing, do you see the same, or is it still clean before you save to JPEG?

EDIT:  Also, new favorite method for cleanup = Split a* and b* into HF and LF; average HF of a* and b*; apply back to respective LFs and replace a* and b* channels.  Beautiful result, IMO [great starting image helps].

Sean Baker Photo wrote:
EDIT:  Also, new favorite method for cleanup = Split a* and b* into HF and LF; average HF of a* and b*; apply back to respective LFs and replace a* and b* channels.  Beautiful result, IMO [great starting image helps].

You know Sean, we all love it when you put this stuff in an action or a script.

Robert Randall wrote:
You know Sean, we all love it when you put this stuff in an action or a script.

Here you go.  Way easier that way.  Action also adds a final noise reduction stage which really amps up the effectiveness of the technique (note: if doing manually, still start with the averaging; NR just isn't good enough on its own).

NOTE: Must be in LAB before running; otherwise I promise it breaks.

It's beta; let me know if it breaks, and especially if you can think of a better way to do this.

Robert Randall wrote:
I used this on a file from a 1DsMKIII on which I had completed a full retouch session. The first time I ran the action I couldn't discern any visible change to the file. I left all settings as is when prompted for an input number.

I then added a value of grain to he file, 7.5 Gaussion. I then ran the action, and it made the grain worse.

I don't usually suffer from noise, so there isn't much urgency behind all this, but your stuff is always so fun to play with that I want to know how else I can use the tool.

Where do you suppose I'm going wrong?

Edit... I was in lab.

Actually, that makes perfect sense to me.  You didn't see any difference the first time you ran it because you already do a good job of handling color correction, have no meaningful compression in your workflow, and so there weren't any artifacts to try to clean up.  The second time through likely just smeared the color channels a bit, due to the higher radius used, resulting in some chroma / luma mismatches which made the grain more apparent.

To be sure, this action is only meant to deal with images already suffering from JPEG compression artifacts.  Any other situation is unlikely to benefit from it's use, and in fact is more likely to end up looking worse than better.  Sorry for any confusion on that point!

It worked great for the OP's image, though .

Sean Baker Photo wrote:

Actually, that makes perfect sense to me.  You didn't see any difference the first time you ran it because you already do a good job of handling color correction, have no meaningful compression in your workflow, and so there weren't any artifacts to try to clean up.  The second time through likely just smeared the color channels a bit, due to the higher radius used, resulting in some chroma / luma mismatches which made the grain more apparent.

To be sure, this action is only meant to deal with images already suffering from JPEG compression artifacts.  Any other situation is unlikely to benefit from it's use, and in fact is more likely to end up looking worse than better.  Sorry for any confusion on that point!

It worked great for the OP's image, though .

Here's the results on the induced grain image...



The real reason I wanted the action was to dissect the process and see how it works on other stuff. I have so much control over most of my images that I rarely see artifacts such as was shown in the OP's images. I'm not implying anything with that statement other than every time I pick up a camera, I have a digitech sitting at the tether computer, while 3 assistants are playing with the lights. It's hard for things to go wrong in that environment.

That being said, the last time I dissected one of your actions a whole new world opened up to me.

Robert Randall wrote:
That being said, the last time I dissected one of your actions a whole new world opened up to me.

Well then FWIW, the methodology is based around the idea of how JPEG compression works and a few assumptions about the image the action is used on.  That is, JPEG can be thought of as being a lot like LAB in the way it handles color and brightness.  Based on vision research (and the history of TV going back ages), most of its compression comes from (1) the chroma and (2) smooth / transitional areas.  It does that by blocking smooth ["low frequency"] areas of the image into 8x8 sections and then writing out a summary of what those 64 pixels look like [think of it as rounding off the values].  At the same time, it does its best to protect the "high frequency" information, expending most of the file size on it.  That's why smooth, low contrast backgrounds so often end up looking poor on MM or Facebook, where the JPEG (re)compression really takes its toll.

In any case, knowing that that's how JPEG does things, we know two things about a compressed image which has been converted to LAB -- (1) the 'squares' [regardless of whether the image has been resized] will line up perfectly in the a* and b* channels and (2) that statistically speaking, JPEG is not likely to have rounded in the same direction for each of the channels.  So, we take the high-frequency data from each (remember that any true detail was already preserved by the original compression algorithm), average them - thereby restoring the original smooth transitions, and then put them back overtop their low-frequency forms to restore the channel in its (near) original glory.

Put another, much simpler way, it's the ghetto version of doing what those commercial "JPEG Recovery" applications do.

HTH someone.

AKMac wrote:
Sean,

You mentioned earlier applying the high frequency information from another channel into the Blue channel. I had a go but in a confused and round-about way. Can you advise what is the most efficient way of doing this?

I'm not sure that there is an efficient way, but the down & dirty way that I was doing it to test was:

1) Duplicate layer / stamp visible.
2) Select G or R, depending on which is cleaner + looks a lot like B.  Copy All / Merged.
3) Select RGB.
4) Paste into new layer, we'll call it 'Fixed'.
5) Repeat 2-4 for B channel.
6) Use FS to create HF and LF versions of R/G and B.
7) Discard B HF and R/G LF.
8) Merge R/G HF onto B LF.
9) Copy merged layer.
10) Select B channel of 'Fixed' layer; paste new B channel in.
11) Examine results.

I've not spent a lot of time thinking about it, but offhand I don't think there's a slick way of handling this kind of cleanup otherwise.  The plus side of course is, it can be automated via action, and shouldn't be a common occurrence if you analyze your workflow in order to avoid the issue in the first place.