Get Colormanaged » workaround

“Hacking” Grain settings into ACR and more

René — Fri, 11 Jun 2010 11:37:40 +0000

Noise

While most people in this digital age seem overly concerned with noise, and mainly want noise reduction, I tend to like grain: It can really improve a digital image, and even make it appear sharper. Until now I had to simulate it using Photoshop for instance.

No longer: Recently, Adobe released ACR 6.1 and LightRoom 3. In these there was a new option added: “Grain”, with three controls: “Amount”, “Size” and “Roughness”. It produced some pretty nice “film like” grain. Way better then a simple “add noise” in Photoshop for instance.
That could be a time saver and simplify the workflow quite a bit.
Of course, I’d need to upgrade to LR3 for this feature. But, along with the mayor improvements in IQ due to the new demosaicing and processing algorithms (Process Version 2010) that would be totally worth it to me. Some of the other new features would be the icing on the cake.

One problem

I’d need a new Mac to run it: LightRoom 3 and PSCS5 only run on an Intel Mac, not on my Dual G5 PPC.
Since buying a new Mac just for this is a bit over the top, I decided to see what my options were.

A while back, Adobe updated the previous versions of ACR and LR to ACR 5.7 and LR 2.7: These versions also support the demosaic algorithm from Lightroom 3.
From what I’d read on the web, these should render the file as seen in Lightroom3, but not allow you to make changes to the new Develop settings, like “Grain”.

A bit more researching led (as often) to the excellent site of Victoria Bampton, AKA. Lightroom Queen. She had a bit more detailed info: ACR 5.7 should use the same Demosaic, and match the new additions closely. She also mentioned “5.7 can read LR’s settings but there’s no UI to change the new settings.” Sadly, LR2.7 will ignore the new LR3 settings. (Why Adobe, why?)

Then I got an idea when answering a question on POTN. Would it be possible to “hack” an .XMP file to only adjust the Grain settings?

The answer? It is!

All you need is an .XMP file with settings applied in LightRoom3 (thanks Anouk!) and a text editor.
It really is that simple.

An .XMP file is simply a plain text file, with instructions for the Adobe Raw converter: “Set this slider to this value”.
The part we are interested in, is this:
58 30 59

All you need to do is copy-paste this into a “blank” .XMP file.
To do that, open a Raw file (not a DNG) in ACR 5.7. Then go to the “flyout” menu and choose “Save settings…”.

To make life easy on yourself, only save one set of parameters, for instance “sharpening”.
The advantage of doing it like this, is that all other settings will remain the same. So if you’d already made adjustments to the Raw, they will remain.

Close ACR.

Open the .XMP in a text editor. I like Smultron.
That gives you an .XMP that looks like this:

xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/"> 5.7 5.0 62 +1.0 8 81 True

Delete the “Sharpening” settings, and replace them with the “Grain” settings you want.

You get this:

xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/"> 6.1 5.7 50 30 60 50 True

Save this under a new name. “Grain50_30_60″ seems a logical choice in this case. You can of course save a number of different settings under different names.
Open a Raw file, apply the preset, and BOOM. You just added Grain

But wait, there’s more

So, what if you want to alter just one of the settings? Do you need to open a text editor every time?
No. It’s easier to create a few more presets, each only adjusting 1 parameter.

I created separate presets for GrainAmount, GrainSize and GrainFrequency, in different values.
So, if I open an image in ACR, it looks like this:

Then I apply three presets to set the Grain I want.

In this case GrainAmount80, GrainSize20 and GrainFrequency80. Not as flexible as sliders, but pretty close.

The other way around

In LR3, there’s another new addition that is lacking in LR2.7: There’s a point curve added.
In LR2, you could only adjust the (wrongly named) “point curve” as the ACR “Parametric Curve”. So it was not possible to create a curve to invert the image or set the black and white point to something other then 0 and 255. (Something quite a few people like to do, which makes absolutely no sense to me).

There’s a way around that as well: Open a CR2 file in ACR, adjust the curve as you like, and click “Done”. You just created an .XMP file with all the info you need.
Open that .xmp file in an editor, and look for the second entry for tone curve:

0, 255 255, 0

the first entry for “Tone Curve” is the Parametric Curve. Don’t mess with it, since LR allows you to adjust that.

0, 0 32, 22 64, 56 128, 128 192, 196 255, 255

Now, in LightRoom2, create a new Preset. Use only the “Tone Curve” setting,

Open this preset in a text editor as well.
It will look different then an xmp, but will be plain text as well.

s = { id = "847A699E-AEA0-4E00-BF19-F6E681D5EBD7", internalName = "Negative", title = "Negative", type = "Develop", value = { settings = { ParametricDarks = 0, ParametricHighlightSplit = 75, ParametricHighlights = 0, ParametricLights = 5, ParametricMidtoneSplit = 50, ParametricShadowSplit = 25, ParametricShadows = -5, ToneCurve = { 0, 0, 32, 22, 64, 56, 128, 128, 192, 196, 255, 255, }, ToneCurveName = "Medium Contrast", }, uuid = "F2FF3CF0-C863-43EA-B051-B624A8113D3A", }, version = 0, }

Remove the stuff you don’t want, and change it to this:

s = { id = "847A699E-AEA0-4E00-BF19-F6E681D5EBD7", internalName = "Negative", title = "Negative", type = "Develop", value = { settings = { ToneCurve = { 0, 255, 255, 0, }, ToneCurveName = "Negative", }, uuid = "F2FF3CF0-C863-43EA-B051-B624A8113D3A", }, version = 0, }

Restart LR2, apply the preset. You just inverted the image

Of course, there might be a number of other things you’d want to “hack” into either LR2 or ACR 5.7. Just give it a try! And be sure to post any nice results you get in the comments!

PSCS4, OsX and Epson…

René — Thu, 25 Jun 2009 15:57:23 +0000

part 2, not the best news

In my previous blog post about the subject, I mentioned a workaround for the bug, and also said I didn’t like the idea of converting to GenericRGB somewhere in the process since it might clip colors…

Gave it a quick try today, and yeah, it does clip “somewhat”…

Same image as last time. Original is AdobeRGB. In this image, some purples and dark blues are out of gamut for the R2880, using Epson Premium Glossy paper. Admittedly, not your “average” color palette, but one that does show problems if they are there.

Softproofed

Let’s start by showing the original converted to sRGB;
(again: all screenshots converted to sRGB for web display)

Nice and colorful. Not that big a difference from the AdobeRGB original. (It’s only slightly out of sRGB gamut in the shadow areas.)

When softproofing for the Epson Glossy Paper profile, you see a difference, but about what’s expected. Purples turn a bit blue-ish. Not a huge problem in this case I’d say. Not worth a screenshot. If it were a problem, I’d correct it while softproofing.

Okay, so far so good.

Now apply the workaround: Convert to the paper profile. No change obviously, since I was already softproofing. Then assign Generic RGB. Totally whacked colors. Also to be expected and also not worth a screenshot.

If the workaround were without drawbacks, the image would be sent to the printer and be converted from paper profile to GenericRGB somewhere along the lines. But since we “compensated” for that by assigning the GenericRGB profile beforehand, you’d expect the results to be the same: The printer gets the right “numbers” sent… But are the numbers the same?

Timeline, step by step.

This is what the image goes through:

Open original in PSCS4. Softproof & edit as needed
Convert to printer profile (workaround step 1)
Assign GenericRGB (workaround step 2)
Press “print” in PSCS4
Convert to printer profile (by PSCS4s print engine)
Convert to GenericRGB (done by OSX because of this bug)
Assume printer profile. (by the R2880, because it knows nothing about color management, and just prints the data it gets)

The problem lies in step 6: (For those interested: It’s easily reproducible by doing the same steps manually in Photoshop.)

The image after step 5 is massively out of the GenericRGB gamut, as shown here:
The funky colors are the result of assigning GenericRGB in step 3 obviously.

This results in clipping. Big time.

The result…

…is a print that is way less saturated then it should have been: Top left would be like printed from PSCS4 using the “workaround”, bottom right is the print that PSCS2 would produce:

I hope that this bug gets fixed pronto. I know I’ll keep using PSCS2 for printing in the meantime… Which ~~sucks~~ is a bit of a drawback quite frankly.
(Again: Apple and Epson: Are you reading this?)

PSCS4, OsX and Epson…

René — Thu, 18 Jun 2009 16:02:11 +0000

don’t seem to play nice together.

When testing my Epson R2880 on PSCS4, it was quite obvious that something was off; The print came out looking nothing like the softproof on screen.

To give an indication of what it looked like: Here is a splitscreen: Top left is the softproofed image, bottom right is what the print looked like:
(screenshot converted to sRGB for web display: The difference is bigger in print)

The same image printed from PSCS2 was a perfect match to the softproof. Very weird.
I remembered that another photographer had complained to me about similar issues, and showed me some pdf files in preview. (In OSX you can preview a print as pdf file in Preview).

So I tried that. What a surprise: pdf generated when printing from PSCS2 was entirely different from the one using PSCS4. Same printer driver, same settings in Photoshop, same everything.
Neither of the pdfs looked even remotely like the respective prints by the way. The PSCS4 pdf looked like the softproof (as did the PSCS2 print).

Getting weirder by the minute.

A search on the net only brought up a “Double profiling” issue in OSX 10.5.something. Not what I was experiencing. Also, I’m running 10.4.11.

So, I decided to investigate further.
The pdf generated when printing from PSCS2, has an AdobeRGB1998 profile embedded. No idea why, since it is obvious the wrong profile (should be the paper specific profile for the R2880 I’d think, but that also isn’t the case)
Even weirder, the PSCS4 pdf, had a GenericRGB profile. What? Why on earth… That one has an even slightly smaller gamut then sRGB as far as I know…

Workaround

Some ~~messing about~~ testing with profiles followed.
It turned out that converting the PSCS2 pdf to GenericRGB, then assigning the paper profile, gave two identical images (easier to compare that way around, since the pdf coming out of the PSCS2 print path was very saturated and weird looking because of the wrong profile). Both were now again looking like the softproof in Photoshop.
So, doing the reverse (Convert to paper profile, assign GenericRGB) should give a decent print out of PSCS4. (at least, looking at the pdf. Haven’t wasted any paper on it yet).

So far for a workaround, now for the explanation…

Including “GenericRGB” in the search term proved to be a good idea. On the Adobe Forums I found a thread about grayscale printing (no wonder I hadn’t found it earlier).
In that thread Eric Chan explains how OSX Leopard will convert the image data to Generic Gray or Generic RGB before handing it off to the driver. So, yeah. That’s likely to screw things up…
I’m still not sure why or where the PDF out of PSCS2 gets an AdobeRGB profile. Seems rather silly if you ask me.

I might use the workaround when in PSCS4, or print from PSCS2 until this issue gets fixed… I think I’ll mostly use the latter, since I don’t like the idea of converting to GenericRGB somewhere in the process; it might clip colors without me having any control…
Have to compare a few prints, to see if there are differences.

Edit: The workaround does have its drawbacks: See my next blog post.

(Apple and Epson: Are you reading this?)