Thanks Jeff.

Is it possible then to do away with the colour space encoding? Taking a very simplistic approach; the TIFF file is representing RGB values, with 16bits per pixel per channel. I understand the 7D RAW files have data to 14bits of 'accuracy', so in terms of quantisation and clipping I'm not trying to squeeze samples into a smaller dynamic range. As such, I'd assume that ultimately somewhere within the ACR process, it's dealing with RGB values (with some precision, perhaps 16bit, perhaps more) and applying the exposure/shadows/highlights etc sliders to that data. It feels to me therefore that it must be possible somehow to do this with TIFF data in a way that would yield identical results.

The odd thing is that if I make the exposure correction to the RAW before I import, then save as a TIFF, the imported RAW and saved TIFF look identical (so the TIFF, with its colour space can still represent the desired colours - but not if it's saved uncorrected, then adjusted with ACR afterwards).

The workflow is in essence an idea to blend the data from multiple RAW files, but as I obviously can't write image data to a RAW file, I was hoping to take RAW data into TIFF, blend it with some homemade software, then bring the resulting TIFF into Photoshop via the ACR plugin. If the behaviour of ACR with TIFF files is greatly different from CR2 files then that might knock the idea on its head.

Thanks conroy. That helped (i.e. it's better, but still different). It seems then that what I need is a way of selecting an ICC profile during the ACR import with an impossibly wide gamut (or no ICC profile); such that it doesn't cause any problems? Unfortunately you only get Abode RGB, ColorMatch RGB, ProPhoto RGB and sRGB.

I did randomly try opening the RAW with the ProPhoto profile, then used Assign Profile to change to "Don't Color Manage This Document" before saving as TIFF (or selecting Wide Gamut RGB). No cigar with that approach.

May be out of luck sadly.

> ProPhoto RGB is the exact equivalent of Camera Raw's internal color space.  It doesn't get any wider than that.  It contains even stuff beyond that which the human eye can see and recognize as color.  It is, in effect, the "impossibly wide gamut" you envision.

OK, that's good to know.

> What seems to escape your grasp is that a demosaic'ed, converted image can never ever have the latitude of a raw file.

I should probably explain that I have a software engineering, rather than art/imaging, background. Coming from this point of view, I'm considering each pixel (in a 16bit file) as having a sample for R, G and B (each of which can be 0-65535). The RAW file has, as I understand it, no inherent colour space, as it's the recording of the cells in the camera's sensor. Whilst the Bayer pattern means that each individual pixel is only R, G or B (with the 'smarts' behind RAW conversion producing an RGB triplet for each pixel), even if the sensor was truly 16bits per sample, the RAW (in terms of sample range per pixel) couldn't have more latitude than the converted image - surely?

As I mentioned earlier, I'm assuming (though accept I could be wrong) that the ACR plugin will perform a demosaic step to get an RGB sample per pixel, then apply the algorithms used to change exposure, shadows etc. At the RGB sample stage - it's just a set of numbers. Ignoring the colour profile, it should be feasible to have, say, a TIFF file that contains RGB samples whose values are the same as those used in the ACR stage for a RAW before the effect of the sliders - however, I guess there must be some limitations caused by the profiles that's affecting the results when a TIFF is brought back through the ACR plug in. That is of course unless the algorithms for the sliders work on the Bayer data directly, but that would surely require logic for each different type of sensor, so would be very complex to implement.

ssprengel, Jeff, JJMack - thanks for the constructive replies

station_two - after your use of mildly aggressive language ("What seems to escape your grasp") in your first post, I had money that your subsequent response(s) would be on the lines of "I'm too busy to explain it to people like you". Thankyou for confirming my expectations (sometimes I wonder if some people engage in forum discussions for the sole purpose of trying to get themselves [and possibly others] riled)

So... back to trying to find a construcive solution: If the algorthirms for the adjustments in ACR do operate directly on the Bayer data (before demosiacing to RGB per pixel) then operating on the TIFF (or any other demosaiced RGB data) will indeed be a non-starter. Without (probably unlikely) input from an Adobe developer however, we can't know for sure.

> So RAW numbers after debayering to RGB are linear with numbers of photons within a particular color (R, G or B), while TIF numbers are assumed to be linear with human-vision sensitivity

Understood (I'm familiar with gamma, camera sensor behaviour, exposing to the right etc). Ultimately though, it should be possible to produce an RGB file that is also linear (i.e. not adjusted for human vision) to then bring back into ACR. However, if that's simply not possible with ACR, then that's also a non-starter (and wouldn't help anyway if the adjustments operate on the Bayer data directly).

I did look briefly into opening the RAW as a smart object, but sadly I didn't think that'd help. The goal I'm trying to achieve is an experimental idea to blend parts of images together from multiple exposures; but to achieve a single RAW file with that data as if it came from the camera (thus it could be brought into ACR to get the benefit of - from my point of view - the useful and intuitive adjustment sliders). Clearly that would require reverse engineering the particular RAW format for the camera being used (and each and every camera you'd want to support) - thus, it's not really practical.

I'd hoped to be able to convert (without edits) the RAW images into TIFF (or some other lossless RGB container that I can read programmatically), do the blending to produce a single TIFF, and then bring that back into ACR.

Whilst it's more convoluted, I suppose it might be possible to generate the unedited TIFF files purely for the purposes for getting data about the images, then using that to create a set of masks. Then, as Jeff suggests, perform adjustments to the RAW files in ACR, and use the masks to blend the imported (and now corrected) RAWs into one image. Not ideal, but perhaps worthy of more experimentation.

Hi Noel,

Yes, you may well be right. It might be worth a mail to the ACR forum when I can get the time to write something a bit more descriptive of what I'm trying to inject. Probably only the guys that actually work on the ACR code would be able to answer the questions, but I don't know if any of those guys lurk there.

The kludge I'm wanting to attempt (potential good name for the program BTW) would involve automatically blending parts of multiple RAW files into a single RAW that could then be opened in ACR. I'm not aware that ACR can open/blend multiple RAWs, so I'm presuming that isn't currently possible.

I suspect it would be possible in PS itself (by opening multiple RAWs then performing some processing) but I'd like to see if I could do it all in one external operation. Lack of time at the moment is meaning I'm not getting many opportunities to progress said kludge.

Probably nothing if it doesn't work, but the (crazy) plan was an experiment to produce a single RAW that doesn't suffer from a great 'feature' provided by recent Canon DSLRs - namely terrible banding problems in shadow detail.

I've no doubt this can be done in stages in PS, but the goal is to produce a single linear DNG RAW with the shadow detail replaced from a brighter exposure (and obviously brought down to match the exposure of the base image). Experiments with multiple RAW files seem to show that it would be beneficial, but I need to work out the affect of exposure on the samples within a RAW file.

A brief play with ACR shows that (as long as samples aren't clipped) adjusting the exposure of a RAW to match that of another bracketed shot (of the same scene) does result in very similar RGB values for the corresponding pixels (i.e. an exposure at EV0, with +2 on the slider tends to match an exposure taken 2 stops brighter). It's clearly not just a simple case of +1 stop == 2x the RGB values though, so I presume there's some formula for doing this. I also presume it doesn't need intimate knowledge of the original sensor, as bringing non-RAW files into a HDR program must (I guess) do something similar (in order to create a 'virtual' image with a large dynamic range from pictures with different exposures). If anyone understands the relatioship between changes in exposure and the resulting RGB values on a pixel then I'd be grateful for some pointers.

I wouldn't claim to have a deep understanding of the problems with current Canon sensors (there are many on photography forums going into great detail regarding the differences between the Canon sensors and the Sony Exmor units used in some Nikon bodies); however, the main issue appears to be with trying to push shadow detail. Even a relatively modest push can start to expose banding in shadow areas, and I've not yet seen any noise reduction that's capable of tackling this sufficiently (certainly in a way that'd give you detail like trying the same thing with an exposure from an Exmor sensor). Given the vitriol directed towards Canon on the issue by even some Canon owning landscape pros - who are, based on their work, clearly skilled photographers and PS users, I presume there is no current way of adequately fixing this on a single exposure.

I've noticed that if you take a lighter exposure, reduce the exposure in ACR, open it in PS, then later try to lift the shadows, you'll still get pretty good results (because the original detail was bright enough to not suffer from the banding problems on the sensor). Hence the idea to replace pixels with shadow detail in the 'base' image with the corresponding pixels from a lighter image (by reducing the exposure to match). Note this isn't an attempt at any sort of HDR - it's simply an experiment to produce a single RAW file that would withstand lifting of the shadow detail.

Any form of auto alignment of the images would be 'version 2'; though with mirror lock-up, a remote release cord, and a good tripod, I've tended to find little need for alignment between bracketed shots. The bigger issue is usually moving objects in the scene (leaves etc.)

Oh - to answer the question in your first sentence - simply convenience (if it works). Occasionally I have no choice but to combine multiple exposures due to the dynamic range of a scene. However, I often find that I'd be OK with a single exposure if I could just raise the shadows in an image a little... but often a little more than I can get away with on a Canon sensor. The convenience of being able to adjust a single RAW in ACR would save me a lot of time vs. having to open multiple RAWs then blend shadow detail from multiple images. I'm not a fan of the general HDR 'look', so have never found just bringing multiple images into a HDR tool gets a result I like.

I'm not in front of a machine with my data at the moment, but here's an example of the kind of thing I'm talking about: http://www.fredmiranda.com/5DIII-D800/index_controlled-tests.html

I'd suggest that if you could make 5D3 pushed shadows (from a single exposure) look like those off a D800 you'd win yourself a lot of friends amongst Canon shooters! I'm using a 7D, and the banding is significantly worse than the 5D3.

My understanding is that the signal to noise ratio in shadow details on the Canon sensors at the moment is sufficiently low at base ISO that any NR is just going to smooth out the noise (there's not enough signal to poke through that noise).

> Let's get something straight right off:  No amount of noise reduction is going to equal an image in which less noise is captured. 

Absolutely... but hence my plan to try to automate some blending of exposures.

>Canon will either respond with something new or fold.  I hope the former, as I'm a Canon shooter myself.

There seems to be sufficient noise (pardon the pun) from insiders to indicate there will be a high megapixel Canon body 'soon'. Hopefully that'll tackle the DR and banding problems too, but I suspect (certainly based on Canon's recent pricing) that it won't be cheap.

>However, I'm here to tell you the banding noise, specifically, can be mitigated.  Very few folks have figured out how as I have.  This is one of the images from the page you linked to untouched (top) and after the run of my Vertical Banding Noise Reduction action (bottom).

> But this image would have benefited greatly from more noise reduction dialed-in during raw conversion, perhaps enough not to need my action at all.  Unfortunately, the raw file isn't available.  People sometimes don't realize just how good the noise reduction in Camera Raw actually is.

Well, I have to say I'm very impressed with that result. OK, of course there's still plenty of noise, but the (almost total, to my eyes) elimination of the banding makes it far less objectionable. Is the action you've created something you've shared (or would be willing to share)?

Impressive. Where is that actions set available? I'd certainly consider it if it'd help some of the images I've taken where it wasn't possible to bracket.

No time to play further with the blending experiments this weekend, so no progress sadly.