When we gained the option to use ACR on the 32 bit file we made with merge to HDR, it made all other methods redundant. I stopped using Photomatix, and started revisiting old bracketed sets so I could marvel at all the extra detail and image quality I could now get. Merge to HDR has changed with ACR 9.0, and I am not entirely sure if I am using it correctly.
It seems to take longer than it used to to produces the merged image, which we can now save in DNG format, and reopen in ACR to apply all the local adjustments that make using Photoshop so much better than the competition. The DNG has so far opened for me with some fairly radical settings already applied, and the image looks really quite good. However, making further 'local' adjustments does not cause the lag I was getting previously, so I'm thinking I must be working on a 16 bit image, and not 32bit.
Is this right? If yes, is the workflow cast in stone, or can I choose to save the DNG in 32 bit? I've only tried it on a couple of images so far, and to be fair, it is working well, but I am wondering if I am missing something, or our options have changed? (I could probably tried another set in the time it has taken me to type this post :-( )
JimHess asked that question and got an answer from MadManChan2000. (Basically, stored as 16-bit; rendered as 32-bit.)
If it seems to work faster while doing local adjustments, it could be because of ACR now supporting GPU acceleration. (I can't say for sure, though; I'm not a propellerhead on the matter.)
(Basically stored as 16-bit rendered as 32-bit)
Eric seems to be saying that the DNG has 16-bit floating point HDR data stored in it (not 16-bit integers like "16-bit" usually refers to), but once the HDR data is read into ACR, the internal workspace is 32-bit floating point for HDR manipulations.