CS2 versus Capture

[ednaz]

I just posted the results of my testing the current version of Capture to decide if I was going to shell out for the upgrade, on dpreview. But the short of it is, the new version of Capture is way bigger and runs way slower than the older one that I'm using now. That's bad, particularly bad for me since I do a ton of my processing on a laptop in the field. The solution that people are coming up with for dealing with Capture's growth, 2gb of RAM, going to RAID, overclocking, etc, just isn't an option in a small, light laptop. (has to be small and light because in Uganda, for example, you don't ever let it leave your body...so every ounce counts.)

I upgraded to CS2 shortly after. Wow. It seems like everything runs faster, including batch processing (I checked that, I batch processed 50 images from full size 16bit multi-layer Adobe 98 files to 500pixel sRGB 8bit jpg files in less than half the time as before.) The RAW processor is way better than before, except for the excess of automation of every setting - I've been playing whack-a-mole trying to get them all set to some basic setting that I'm comfortable with for a default.

Opening, editing, and print-prepping a 1gb image (medim format scan, multiple layers, 16 bit, every way you could find to bloat a file) was also noticeably faster in CS2 than in CS. WHy? Who cares, it's wonderful. Name one software package that got faster and more efficient when they added a bunch of new feature/function?

I kept Capture because some difficult images just couldn't be done in CS as well as Capture. At the moment, CS2 raw does those images better than capture - again, i dragged out some old "these files are awful" images and CS2 blew me away.

Now I know why Nikon wants to have WB encryption. I honestly can't see why I'd want to graft a declining performance Capture onto the front of workflow that could be done completely on an improving performance Photoshop CS2.

At least for my D100, this is a no brainer. But it's got me thinking really hard about D2x; I don't WANT to have to have both Capture and CS2 running on my laptop just to be able to check proofs on site. Gak! I want this solved!

 

[Iliah]

White balance is not as simple as a pair of coefficients. Actually, it can not be properly represented in that way. Instead, it is a spectral data with a minimum of 20 nm step between readings.

If you set in Capture "flash" white balance, and then "daylight" with compensation to exact same temperature, are colours the same? What is the reason to have overlapping colour temperature data in tables for white balance; but in different light modes?

Since D1h/D1x Nikon is using partial spectral data to work with light sources with unusual/uneven spectral distribution. Those include fluorescent lights and flash lights. For these light sources white balance using 2 coefficients, as most of third-parties do, was never accurate.

Two-numbers approach was left behind long ago by leading colormeter-making companies; even simple monitor calibrating tools now are using spectral methods.

Reduction of white balance to customary schemes actually prevents progress in accuracy of colour rendition. Why are we carried away?

 

[ednaz]

Iliah, I found CS2/Adobe RAW WB to be MORE accurate

I find that Nikon's WB presets across the board look cold to me. Perhaps its because the "natural" color of light in Japan is bluer than that where I live. Adobe raw, when clicking "daylight" or "flash" or whatever, produced a look that was much more accurate, to my eyes. And, Capture is not good at all when you get into color temperatures like sodium vapor lights, which I encounter frequently on forays into some of the places where I do street shooting - in fact some of the lights can't be balanced at all in Capture, while Adobe RAW grabbed them back from the edge, as much as you can expect from pictures shot in light that has almost zero in the blue channel.

And I know what you're saying about spectral rendering data - I often use the "flourescent" settings for a lot of the mixed light environments, because the mixed light happens to pretty much equal daylight, or cold, or whatever, flourescent presets.

 

[Iliah]

My point is - current accusations of Nikon encrypting white balance are not enough justified (trying to be politically correct here )

As far as NC vs. ACR - whatever works for you and your customers

 

[Chris101]

At least for my D100, this is a no brainer. But it's got me thinking really hard about D2x; I don't WANT to have to have both Capture and CS2 running on my laptop just to be able to check proofs on site. Gak! I want this solved!

Check the post about ACR 3.1 being currently available. Try it with a D2x, then you will know if it's solved or not. I doubt that Adobe's WB guessing algorithm is unsophisticated.

 

[ednaz]

Iliah - my concern is that I've played the SDK game before

I worked for a very large blue company in the computer business that shall remain unnamed, and for other large and small firms with edgy computer technology. When we owned the good stuff, and SDK was usually used as a way to figure out who you're going to extract tribute from. That's what I'm worried about. I'm sure there are a lot of guys at Nikon who understand that an open system will sell their cameras, but there's gotta be one freshly-grown MBA who's going to do a chart that shows how much money they could make from hitting up Adobe and the other guys who have money in their pockets. I'd rather have a system where there are 10 guys working out how to make images better than 2 of them.

 

[Iliah]

So, you suggest that Nikon should publish the file specifications. Hundreds of developers will start writing their raw converters, and ask for technical support and explanations. I do not think that is a viable perspective for Nikon. I can tell you from experience that companies who produce colour-measuring devices provide zero support to software developers who ask questions like "what is that your device actually measures, and how to interpret and use the data".

 

[Retief]

White balance is not as simple as a pair of coefficients. Actually, it can not be properly represented in that way. Instead, it is a spectral data with a minimum of 20 nm step between readings.

If you set in Capture "flash" white balance, and then "daylight" with compensation to exact same temperature, are colours the same? What is the reason to have overlapping colour temperature data in tables for white balance; but in different light modes?

Iliah, once again you teach me something. I have seen this and never bothered to wonder about the "why", I just figured that the differences were something I was "imagining". But this comment got me to thinking that the light source itself, even with the same "K" setting, is still going to have other color effects. Am I understanding this properly in a very simplistic way?

Thanks for making me think, always appreciated.

 

[Iliah]

But this comment got me to thinking that the light source itself, even with the same "K" setting, is still going to have other color effects

Right. Photographic colour temperature calculated using 2 or even 3 coefficients is nothig more then a rough approximation, while spectral distribution is everything.

Problem is that light of different spectrum distribution is coerced to same colour temperature - that is why colour temperature and those 2 coefficients do not describe colour accurately. "Many to one" kind of projection

Fluorescent, HMI, strong overcast, and many other situations - most important, mixed light ... all of those are poorly described with white balance represented by traditional 2 numbers...

Colour calibration is migrating to spectral approach with increasing speed. Compare DTP-92 calibrated monitor with monitor calibrated with Spectrolino - and you will see what the difference in the approaches results in. And DTP-92 - is three-colour calibrator, not two-colour....

My humble opinion is that some folks do not have enough colour science background, and/or are not ready to progress with Nikon towards the advanced colour handlng. So, they resort to denial.

I asked one of my friends from a company whos primary business is colour management for his opinion on WB issue.

After study of D2x file samples he laughed and said that pressing Nikon to retreat to old white balance scheme is illogical, as new scheme allows for better colour and more flexibility. He suggestd that at this stage too much educative efforts are needed to explain how to use the new scheme. He also was amazed of how little trust we have in Nikon, and how easily we fall into the hands of ignoramuses and big mouths. Also he added: - "Are you all blind? Why not to give Nikon a benefit of doubt at least?"

Next step should be that we will oppose multi-colour arrays only because we do not know how to demosaic them, and how to colour-correct...

An old joke. A man comes to the Council of Elders and suggests to replace square wheels with round ones. Educated Elders answer him - "All the noise and difficulties to roooooootate square wheel are because of the angles. What is circle? Any child knows that it is nothing more them a polygon with infinite number of angles. So, noise and problems will be infinitly increased."

 

[Chris101]

An old joke. A man comes to the Council of Elders and suggests to replace square wheels with round ones. Educated Elders answer him - "All the noise and difficulties to roooooootate square wheel are because of the angles. What is circle? Any child knows that it is nothing more them a polygon with infinite number of angles. So, noise and problems will be infinitly increased."

Heh - I like it! Mind if I steal it?

 

[Retief]

Iliah, I completely, totally and freely admit to being both a "colour" and "color" illiterate, which is why having folks like you areound is such a treat.

Here is the situation that I have recently gone through shooting the Everett Hawks football team indoors. Crummy mixed lighting, so I do a K reading with the color temp meter which gives me something around 5200. One thing annoying about the D2H setting of K is that they have a set of "numbers", you can't actually enter something like "5207" for example. So I look at the chart and decide that 5200 is, from memory so I am probably wrong, like Cloudy +2. Shoot the game and when I look at the images they are not quite right. Switch to Fluorescent HMI and BINGO, so much better. And now, while I don't pretend to understand the science behind it, I understand the "why" at a high level.

Thanks for the education, I hope this helps others understand this as well.

 

[Iliah]

Dear Bill,

Using colormeter, in postprocessing through Nikon Capture, I set the correct type of light (ensuring more or less proper treatment of spectral charachteristics of the light source), and then correct colour temperature - via Nikon "compensation" tables. Then I set the gray point.

All colour rendition tests ACR vs. NC are usually done for light sources with spectral power distribution more or less close to black body radiator. I wish folks would try flash, HMI, fluorescent, mixed light (vs. custom WB reading taken with camera at shooting time)...

Dear Chris,

I think I've stolen that joke too from some old book

 

[Iliah]

To give an example:
in AdobeRGB
R=195, G=185, B=159
and
R=200, G=181, B=171
are characterized with same correlatd colour temperature (Robertson's method) of 5000K.

It is easy to see how different are R/G and B/G in both cases.

 

[Man-Fai Wong]

Iliah,

I'm not sure if this is entirely relevant for digital photography, but in the video world, people also differentiate between color temp/WB/gray scale from color encoding/decoding accuracy.

When an ISF tech calibrates your TV, he/she must deal w/ both to meet NTSC/ATSC spec and yield a truly good picture. Generally, what happens is the TV is built to have extremely high color temp that also varies across the light output range -- so even if you have a setting for 6500K, it's probably not gonna be 6500K across the board -- *and* will have color decoder inaccuracies primarily *designed* to "help" compensate for the wrong color temp. Usually, there's a red push to compensate for blue color temp although there's a green push sometimes too.

Is there perhaps the same sort of issue here, but I guess expressed differently? Personally, I do wonder if there's not a red push issue w/ the way Nikon does their color processing at least in the past since their WB seemed to tend towards blue (and this would explain the hot red I see from the D70).

_Man_

 

[Iliah]

Dear _Man_,

Yes, what you described is done by individual channel curves.

 

[cwilt]

Always something new to learn from Iliah.