This content has been marked as final. Show 23 replies
I am not a pro by any stretch of the imagination. But it seems to me that since you have modified your camera in such a way as 99% of other users would not modify their camera, you are the one who has a problem to solve. Your style of photography is very unique, and it seems to me that it is your responsibility to calibrate Camera Raw for your type of photography and create your own unique subset that will accommodate what you are doing. In that way, I think Camera Raw and Photoshop are unquestionably "pro" applications because they provide you with the flexibility to customize them to what you are doing. The only problem is, that forces you to act like a pro, because you have to perform your own calibration.
I know that seems to be a very simplistic answer. But it makes sense to me.
"When ACR (or any of these other apps) do the RAW conversion, they mangle the WB data to fit this temp-and-tint view of the world, and the result is usually bright red pictures. "
No...you've mangled your camera so that _ALL_ embedded white balance metadata is, by definition, incorrect. How the heck is Camera Raw supposed to know that?
"The only problem is, that forces you to act like a pro, because you have to perform your own calibration."
Fantastic. How do I perform such calibration? Photographing a Macbeth color checker doesn't help me here, for obvious reasons.
More to the point, why is ACR unable to produce results, in the "As Shot" mode that are even vaguely close to the embedded preview in the RAW file.
See my response to Jeff for more.
"No...you've mangled your camera so that _ALL_ embedded white balance metadata is, by definition, incorrect. How the heck is Camera Raw supposed to know that?"
Absolutely incorrect. As a simple proof, using dcraw with the -w switch (Use camera's white balance) does exactly the right thing.
Let me try to explain this a different way.
I have a modified camera but ultimately the sensor is responding to the light that makes it through whatever combinations of filters are over the lens. In the case of a stock camera, that's an IR-cutoff filter. In my case, it's a red or IR-pass filter.
So, in order to process that data correctly, I measure a 'neutral' object and set a custom white balance. This embeds a set of corrections in the RAW file that adjust the sensor data to produce a neutral tone for, at least, your reference object. This is exactly like a normal visible-light image, but the corrections are obviously different.
Now, I open that image in ACR. It takes the embedded white balance data, which I believe is a set of coefficients for each color in the Bayer array, and 'converts' it to a color temperature and green/magenta tint. But that can't express the original data successfully with that model, so you end up with very different color than if you didn't try to 'convert' the color data. And I cannot find a way to get ACR to use the custom WB data as is.
"I measure a 'neutral' object and set a custom white balance. This embeds a set of corrections in the RAW file that adjust the sensor data to produce a neutral tone for, at least, your reference object."
That works ONLY if the camera sensor is getting the light in the EXACT same way it's EXPECTING to get it...through the original IR cutoff filter. The moment you alter the nature of the sensor capture (change the IR cutoff filter for example) the white balance data will be, by the nature of what you've done, useless. That means you'll have to do EVERYTHING in a completely manual approach which means wanking on the sliders till you get what you want.
And that is what you should have been expecting all along...you've modified the camera beyond normal opperating specs so you are completely on your own. Good luck...
"That works ONLY if the camera sensor is getting the light in the EXACT same way it's EXPECTING to get it..."
No, actually it doesn't. The piece of this system that is expecting something specific and isn't getting it is ACR, not the camera.
I've thrown a few quick examples on the web here:
For each image, I've provided the embedded JPEG from the RAW file, the output of dcraw -w (no wanking on sliders, just using the white balance data from the camera), an "As Shot" image from ACR, and the equivalent from Aperture.
Clearly, the image that actually uses the WB data from the camera (dcraw -w) is just fine. But I can't figure out how to get ACR to use that data as a starting point. Color temperature and tint just don't get there.
So, even if ACR can't do the right thing based on the embedded white balance data, which sliders do you recommend I wank on to get there? I can use levels once I'm in PS, but if I'm going to do that, I can't use most of the other adjustments in ACR and might as well use dcraw.
Aleksandr, try running the red looking images in CS3 using the B&W conversion step. I did and got a marvelous result using either Max Black or the High Contrast Blue filter. Forget the sliders in ACR.
Thanks for the pointer. Certainly the images taken with deeper IR filters are effectively monochrome, and we have great tools for working with B&W images.
Unfortunately, doing so completely ditches the color information that is present in the red and near-IR filtered images like the #29 and R72 filters. The #29 images are strongly colored, and though it doesn't come through well on the web, the R72 images have a lovely effect that is close to a split-toned B&W print. Though, the split is not highlight shadow as much as it is living/dead. (stone and sky are warm tones, plants are cool)
What is the effect of picking white balance from the shot you used for setting the custom white balance?
That's a good question. The answer is that it doesn't get it right. It does OK on the white card itself, but the remainder of the hues don't match what's in the correct output from dcraw or the embedded JPEG.
I'm away for the weekend, so I won't be able post any test shots until Monday, but I'll post those at the above URL as well.
Well, it appears that what you want to see is the data beyond IR that filters pass. if I were to place a Wratten #29 in front of my camera with the IR filter intact, I would not expect the WB to be correct either. The express purpose of such filters is a grayscale image, along with the wavelengths which make it through the low Pass 29 filter. The existence of these wavelengths usually are usually considered to be contaminants, so a steeper lo pass is employed, reducing those further. In fact, one can build a IR pass out of material which is completely oblivious to the visible spectrum. Germanium comes to mind.
The object of all this is to obtain a b&w final image.
Kodak had (has?) an IR color film that produces false color:
According to this article, you used a deep yellow to obtain the result shown in the article. I would experiment with that filter instead of the deep reds. I would expect that the same #29 to produce a red result as well.
If B&W is your goal, the conversion methods in CS3 are applicabe. If false color is, then dcraw is your app.
Complaining about lack of their capabilities in ACR is rather pointless, IMO, anyway.
You're exactly right. I do want the data in the deep red and near infrared. The false color images exploit differences in the IR pass characteristics of the various colors in the Bayer array (thus Canon G1s with their CYGM array produce rather different results)
Whether or not the WB is 'correct' is kind of beside the point. The WB is there, represents the desired effect, and ACR mangles it. It seems incredible to me that ACR cannot reproduce the embedded JPEG because it "knows better." I was hoping that there was some way in which ACR could be persuaded to use that data correctly, thus affording me the other options available in ACR. Sadly that seems not to be the case.
False-color Infrared film and digital camera sensors don't have anything like the same characteristics. In fact, the deep yellow filter in the article is analogous to the IR-cutoff filter in visible light digital photography. All three emulsion layers in Ektachrome IR are sensitive to blue, so you use a deep yellow (or 'minus blue') filter to remove that light. Similarly, all 3 or 4 colors of the Bayer array on the digital camera sensor pass IR, and the sensor, so you use an IR-cutoff to remove that light.
Shooting digital IR through a yellow filter would give you red+IR, green+IR, and IR-only as your three channels. I suppose the blue channel would give a pure IR monochrome image, and there would be enough visible light admitted to allow this method on a DSLR where composition through a deep red or IR-pass filter on the lens would be difficult to impossible. An interesting suggestion, but not applicable to this case.
It seems like it would be a huge issue to photographers that ACR does not, indeed cannot, use the WB data in the RAW file without mangling it. I guess I'm wrong. As to complaining about this, is there an effective channel to Adobe for user feedback?
If you are on a tripod, a deep IR is applicable. The view camera photographers lose their image at the moment of exposure, but if you look at the Westons, one must concluded that was not a factor at all in his accomplishments.
More to the point, WB is analogous to the various film balances obtainable in film, but is very different as to it's application. You can rebalance film, so as to obtain the correct "WB", at a speed cost.
With digital, there is no native color balance in the sensor array, other then the actual wavelength cutoff of the sensors. We tell it what the colors should be. Now, my question to you is: How do you know that dcraw is accurate? All you really know, it seems to me anyway, is that dcraw provides you with an output that you find artistically desirable, and that is admirable, and fortunate. I looked at dcraw a couple of hours ago and it is indeed a program that has tools which, as an engineer, I find attractive. I don't hope for same in any other program, for if dcraw is the ultimate, then it's adoption as the standard would follow, and maybe will. But for the moment, it is another tool, available on multiple platforms (great!) that we can employ for our needs. The Richardson-Lucy sharpening algorithms are also quite powerful, but after using them for a while, they actually fail to provide the general sharpening needs I have, so I reserve it for special apps. The same applies here, IMO.
I like what you are doing with infra-red, Aleksandr, and I hope you take my remarks in the spirit of exploration of other paths to follow, and continue to post your work and findings.:-)
"If you are on a tripod, a deep IR is applicable. The view camera photographers lose their image at the moment of exposure, but if you look at the Westons, one must concluded that was not a factor at all in his accomplishments."
Actually, that's the beauty of converting something like a Canon G-series or some other camera with a live preview: You can compose in IR, and shoot handheld, even with a deep IR filter.
As to whether dcraw is correct, it depends on how you define correctness. This is a false-color process, so in that sense nothing is correct. However dcraw is able to reproduce the color rendition that is shown in the viewfinder and recorded by the camera in the JPEG embedded in the raw file. In that sense, it's correct. I can reproduce the image that I would have recorded if I'd shot in JPEG.
This seems like a pretty fundamental capability for any raw conversion tool, yet it's missing from many of the tools available today. It's not just ACR: Aperture and LightZone have the same problem. As such I cannot maintain the in-camera color rendition while using any of the other adjustments offered by ACR.
Thank you for the encouragement. Digital IR is an emerging thing, as evidenced by some of Fuji's cameras that are 'factory prepared' for UV and IR work.
It is my understanding that ACR uses a significantly different algorithm from most other raw converters - including dcraw. In particular, it uses two color profiles for each camera, one with a tungsten color balance, and one with a daylight balance (or at least one low-temp and one high-temp), and uses the temperature and tint to interpolate between the two.
ACR's advocates suggest that this is a wonderful innovation, and provides more accurate color under more widely varying conditions. Its opponents maintain that since they cannot use a color profile specific to their cameras and lighting conditions, it *cannot* provide accurate color for them.
Regardless of which camp you fall into, it appears that the way that ACR uses color balance is very different from a more traditional approach. It seems to work pretty well under typical lighting conditions, but I suspect that your conditions are often way off the end - instead of interpolating between two color profiles, it needs to extend its model beyond one of them. This could account for ACR's rather bizarre interpretation of your images, and more normal interpretation of more typical images.
"ACR's advocates suggest that this is a wonderful innovation, and provides more accurate color under more widely varying conditions."
Sigh. It probably would be if there were a box I could uncheck to return to using the camera data.
"Its opponents maintain that since they cannot use a color profile specific to their cameras and lighting conditions, it *cannot* provide accurate color for them."
Indeed. Not to mention that as an engineer, it violates one of my first rules: "Never design anything around the notion that you know more about something than the people that built it." Adobe may know a lot about color, but to presume that they're *always* going to be better than Canon and Nikon, et al. seems to be stretching it.
>Adobe may know a lot about color, but to presume that they're *always* going to be better than Canon and Nikon, et al. seems to be stretching it.
Not stretching it at all. The Japanese suck at programming.
If you think I'm wrong, please provide an example of outstanding Japanese software.
I would go along with Ramon. As an engineer, the effort to standardize is rather important.
When is a standard not a standard?
When there is more than one.
As to the Japanese sucking at programming, that is rather moot, as each firm will be running their own "standards" anyway. It's notable that Hasselblad also will not go along with Adobe either. So we have as a minimum 4 "Standards".
Personally, having certain apps like dcraw or Richardson-Lucy available for color or sharpness is an advantage, if you take the time to find out what they do and apply it accordingly.
So far as infra red, how far is far enough? Should we go out to 1500 nM?
Instead of slamming what I believe to be the most elegant solution to RAW processing yet,(over-simple . . . nah, perfect for high productivity), why not set your ACR defaults to value which suits your IR images and save those values as "As I Shot it".
Gotta say that I am curious to see what your images look like since most people remove the IR cutoff filter to make B&W images!
Just curious, if you have an app that is producing a desired result of a specialized nature using modified equipment, and another app does not seem to work the way you want it to, why not just use the one that works?
As you have one of the folks resposible for the developement of PS trying to explain why ACR doesn't work the way you think it should, that seems to be the way to go. Or try some of the work-arounds sugested here. I'm also sure you are aware of the IR community out there for other ideas.
And yeah, I used to do color and B&W IR film work. Kinda fun, but not many pros out there doing it on a regular basis outside of the scientific community as far as I know. PS and ACR seem to be more of a working man's tool set.
Thought of something else...
What sort of a reading do you get with a standard photo colormeter reading a pure infrared light source?
Just what would the camera be setting itself to if doing a custom WB through an IR only filter?
IR film was designed specifically for IR work. Digicams, by and large, aren't except for certain use specific models.
Probably not much. IR meters are usually calibrated to measure power. I would think the visible light meter would have cut off in IR.