Batch HDR Toning Script for Photoshop

[dmilligan]

So for a long time it has annoyed the crap out of me that there is no way to automate the HDR toning process in photoshop (for the purpose of timelapse, etc.). Searching the internet, pretty much all you find is people telling you to use some other software to do it like photomatix. Well I don't freakin' want to buy another piece of software when I've already dropped a boat load on photoshop and it should, at least in theory, be able to do this.

After scraping bits of scripts together I found from across the internet and single stepping through the MergeToHDR.jsx script built into photoshop to figure out how it works, I finally have come up with a script that can do this.

https://github.com/davidmilligan/PhotoshopBatchHDR/blob/master/Batch%20HDR.jsx

Guide on how to use this script:

https://github.com/davidmilligan/PhotoshopBatchHDR/wiki

Being a C++/C# developer by day, non-strongly-typed languages like javascript annoy the hell out me, and the poor documentation and crappy IDE of ExtendScript only make matters worse. So if anyone with more javascript/adobe scripting experience would like to help me polish this script up, that would be great.

Modify the 'numberOfBrackets' variable to tell the script how many brackets are in each shot, the MergeToHDR script will automatically determine which is which (+EV, - EV, etc) so the bracket order doesn't matter just as long as you always take the same number of brackets for each shot.

The script is currently not able load individual raw files for HDR toning (i.e. numberOfBrackets = 1) which is something I'd like to be able to do since even a single exposure raw file is 14bit which is higher dynamic range that an 8 bit screen, and allow HDR time lapses without as many actuations. I don't really know how to raw files; you have to specify a bunch of options when you try to open a raw file, and I don't really know what they should be. The MergeToHDR script will load raw files but it requires a minimum of 2 files so it wont work with individual files, and I can't really figure out what it's doing to load raw files (or at least I haven't tried really hard to figure it out yet).

Once I figure out how to load single RAW files I think this script could also be very useful for those doing RAW video, as it would provide a way to do HDR toning effects on RAW video footage.

I'd also like to figure out a way to avoid hard coding the toning settings in the script, perhaps reverse engineer the HDR preset file format and have the script load a preset file and use the values in that.

Also, I'm using photoshop CC, so I'm not sure if it works on earlier versions, but it should, as I don't think adobe has changed any of the HDR stuff in a while.

[dmilligan]

Cleaned up the script a bit and implemented a UI. I put it up on github:

https://github.com/davidmilligan/PhotoshopBatchHDR/blob/master/Batch%20HDR.jsx

Place the script in '[Photoshop Dir]/presets/scripts' and it will show up in the automate menu of photoshop

[Joachim Buambeki]

Great work David.
I would love to see this developed further - not beeing able to batch HDRI creation with Bridge and PS creation also annoyed the hell out of me...

A few questions:
- How to output 32bit TIFF files? I can choose .tiff as output, but the option to choose bitdepth is stuck at 8 bit and greyed out. I am using PS CC on Win8.
- Would it be possible to get 32bit DNG files by sending the TIFF files internally to the Adobe DNG converter? If yes, the option the create lossy, lower res proxies would be great
- When processing RAW files the .xmp sidecard files seem to be ignored, could your script take them into account?
I am asking because the default settings are not optimal for HDR image creation (see here), also I would like to remove CAs and lens distortion in that step aswell.
 

Thanks again for your effort!
JB

[dmilligan]

1. You should be able to select 32bit tiff, you have to select tiff first then the bit depth should become enabled (it's disabled for jpeg b/c jpeg only supports 8bit).   If you select 32 bit, the tone mapping will not be applied, the images will simply be merged into 32bit float.
2. No, not possible
3. Also not possible, photoshop cannot operate on CFA (raw undebayered) data directly, and there's no way and no reason to try to undebayer it once you've processed it. (This is why you get the ACR dialog when you try to open a RAW image, it has to be debayered into 3 channel RGB before photoshop can work with it).
4. I'll see what I can do, you can always just preprocess them with bridge first into 16 bit tiff. BTW, that article is about Lr, afaik Lr and ACR are not the same and operate differently, so IDK if the stuff in the article is applicable to this situation. I've never had an issue with losing highlight detail in HDRs, that article doesn't make much sense to me either. "mushed" is not exactly a very mathematical explanation. You can always assign more DR to the highlights with a curve if you feel they are too compressed.

[Joachim Buambeki]

Thanks for your fast reply David!

1. You should be able to select 32bit tiff, you have to select tiff first then the bit depth should become enabled (it's disabled for jpeg b/c jpeg only supports 8bit).   If you select 32 bit, the tone mapping will not be applied, the images will simply be merged into 32bit float.

After selecting TIFF as output both compression and bit depth are greyed out (the first one makes sense of course)

2. No, not possible

You mean DNG is not possible, right? AFAIK you can call the DNG converter from Adobe so I thought it should be possible to feed it with those (intermediate) 32bit TIFF files. If that works, proxy creation should also be doable if I am not mistaken.

3. Also not possible, photoshop cannot operate on CFA (raw undebayered) data directly, and there's no way and no reason to try to undebayer it once you've processed it. (This is why you get the ACR dialog when you try to open a RAW image, it has to be debayered into 3 channel RGB before photoshop can work with it).

I am not sure what you mean by that, but if you probably understood me wrong:
The DNGs created from 32 bit TIFF files are not CFA data, they are just an 32bit float file in a convenient DNG container (meaning the data has been debayered before the merging).

4. I'll see what I can do, you can always just preprocess them with bridge first into 16 bit tiff. BTW, that article is about Lr, afaik Lr and ACR are not the same and operate differently, so IDK if the stuff in the article is applicable to this situation. I've never had an issue with losing highlight detail in HDRs, that article doesn't make much sense to me either. "mushed" is not exactly a very mathematical explanation. You can always assign more DR to the highlights with a curve if you feel they are too compressed.

Though "mushed" is indeed not a very mathematical term, that guy one of THE authorities for HDRI, I am surprised you haven't heard of him.
LR and ACR use the same RAW conversion engine so their output is identical - meaning what the writes is also applicable to ACR. Though I am a technical layman it makes perfect sense to me what he says:
When using the default ACR settings you basically apply an s-curve to the image (it not that simple actually, because contrast affects the midtones more than the highlights/shadows of the image, see also here), so apart from the camera curve itself (sensors aren't perfectly linear as you know) the HDR merger has figure out how to reverse that midtone contrast that is applied. In PV2010 you could linearise an image by setting everything to zero, when you convert those values to PV2012 you get the following:

Code: [Select]

-1 EV
-33 Contrast
+25 Blacks
a slight reverse s-curveWhich is pretty similar to what he is suggesting (I am also not sure not accurate that conversion from PV2010 to PV2012 by ACR is, because a few test I did myself brought me to the conclusion it might be not).
Converting the sequence to TIFF with lens corrections applied first and then using your script is certainly doable, but that another manual step I would love to avoid. ;-)

Since I can't test the TIFF option:
Are the TIFF files compressed in any (lossless/lossy) way to save space? If no, would you consider implementing it?

[dmilligan]

I didn't realize you could put RGB data into a DNG, so I guess you're wanting that so you can use ACR on the result? since technically there would be no difference in the actual data contained in the file, and tiff is much more widely supported than dng.

I was under the impression that Lr and ACR actually used different raw processing engines, but I guess not (ppl talk about how they feel Lr is superior to ACR, I've never noticed a difference myself, but I assumed they knew what they were talking about).

That's kind of annoying that process 2012 applies nonlinear corrections even if you have all settings 0, but I don't see how it could, practically speaking, have much of an effect on the final image. Yes, you are throwing away some small amount of information in applying a non-linear transformation, but compared to the amount of information you end up with in the final HDR, it seems totally insignificant to me. Perhaps if it really is significant, the script should just automatically use the best ACR settings for you. I think an experiment would be in order.

[Audionut]

I was under the impression that Adobe software always applied nonlinear corrections, regardless of the process used.  I wonder how much of this is the result of flickering in your timelapses dmilligan.  You could try processing the parts of your last timelapse that required manual adjustment in a different raw processor and observing the results.

[Joachim Buambeki]

Yes, the goal is to use ACR to process the endresult. I know that there is way to call the Adobe DNG converter from another programm, because that is what LRtimelapse does. The option to create those those DNGs directly would be just a big timesaver, also have can get a preview of the tonemapped file embedded into the DNG, which is not only nice for browsing those files in Bridge or another programm but also good for processing the files in LRtimelapse (it does only work on Jpeg instead of linear data, so having those JPEGs would actually help to improve the final output).

About LR vs ACR:
Sometimes people don't know what they are talking about. ;-)

As I said, with the settings shown above applied you get (something pretty close to) linear output, to goal is definitely to send files to the merger that have as little nonlinear processing applied as possible. I haven't made any conclusive tests, but I guess that introduces some sort of local flickering, because if you only have three nonlinear files to merge, there is a certain amount of guessing while reconstructing the linear files - which is totally fine for a single image - but it might result in flicker in certain tonal ranges (as Audionut pointed out) that are hard to impossible to remove for a deflicker tool since they only work best if the flicker is global.
There is also a similar phenomenon that I discussed with John Hable a while back: In the shots with the fastest shutter speed you get flicker because the shutter isn't 100% precise at speeds faster than 33ms (on Canon), though that problem seems to be less severe on Nikon than Canon. If you're interested in this google for "shutter flicker".

The reason why I don't want to use something else than ACR to create the intermediate files is the overall quality of the output, there is very little artifacting, jagged edges and other stuff compared to other converters. Apart from that, creating intermediate TIFF files with another programm would be a huge pain the butt.

PS: If I understood you correctly you weren't aware that you could tone your HDRIs in ACR, maybe you want to have a look at this, instead of using the HDR toning of HDRmerge Pro  (which is not that great IMO) you could call ACR for the 8/16bit files created with your script. If you do that it would be nice to have an option to render both 32bit and 8/16bit to be able to create a fast preview clip directly after the TIFF/DNG creation is finished.

[dmilligan]

I was under the impression that Adobe software always applied nonlinear corrections, regardless of the process used.  I wonder how much of this is the result of flickering in your timelapses dmilligan.  You could try processing the parts of your last timelapse that required manual adjustment in a different raw processor and observing the results.

This would be true for "automatic" corrections, but in general there's no reason non-linear transformations should cause flicker, assuming you are applying the same non-linear transformation to each photo. It could make existing flicker worse (or better, just depends on the nature of the flicker and the type of transform), but I don't see how it would cause flicker.

All of the manual adjustments I had to do were because I gave post deflicker bad settings for the particular scene, and it's estimated exposure compensation was just wrong. In some cases I was able to fix the flicker by selecting a long sequence of photos where AETTR kept choosing the same expo parameters for a long time, and set their exposure value to all the same value (post deflicker chose different exposure value despite the fact the AETTR was not changing any exposure parameters, so post deflicker was actually causing flicker that was not present to begin with).

Anyways, after that OT,

There is no way to save as DNG in photoshop, which means there's no way for this script to do it without first saving to some intermediate file format that photoshop supports, also I see no reason to convert to DNG since the all that is going to happen is that TIFF data is going to be stored inside a DNG wrapper, and you can open and tone any file format with ACR. In Br, right click on any photo(s) and go to "Open in Camera RAW..."  This works with any format (I just tried jpeg, tiff, and psd to be sure). You can do the same in photoshop, in the open dialog just select "Camera Raw" as the Format.  Or just use Lr (apparently it's the same thing).

If you want to tone with ACR (which BTW, I do know you can do this for HDR), the best way is going to be with Br or Lr. Use my script to do your merge, save as 32bit, then use Br or Lr or whatever to do the toning. If you do it like this you should be able to realtime preview the results of the toning (on any image in the sequence), and even setup a non-destructive workflow from the merge step onward since AE recognizes the .xmp files that ACR creates and you can dynamic link to Premiere for compilation/finishing touches.

I think I fixed the problem with not being able to select 32bit TIFF, see if the latest version on github works

[Joachim Buambeki]

Thanks for the updated script, everything works now as it should!

Regarding the nonlinear corrections:
It is a problem that occurs if you use use more than the exposure slider and curves, see this thread and what one of the Adobe developer says:

Some (many) controls in the Basic panel in PV 2012 are now image-adaptive.  They use the image content itself to determine the range and behavior of the controls.  Highlights, Shadows, and Clarity are among the controls that respond most strongly to the image content.  These were not designed with temporal coherence in mind.  This is why you can expect to see temporal artifacts if you are to try to apply these controls to individual still frames.

For basic tone effects, I would suggest instead using the Parametric and/or Point curves to minimize temporal issues.

So depending on image content you get flicker - beeing severe or not (maybe even invisible).


Regarding the UI of the script:
- I would suggest to move the "Deghosting" up and next to the "Alligning" checkbox because it has nothing to do with the toning part.
- Would it be possible to add an automatic filtering for image files, so one doesn't have to type in *.CR2/NEF or whatever the file format is that you want to process? Knowing me, I would forget that filter in 1 of 5 cases... :-/
- Could the toning part be made collapsible?
- Can I set new defaults? If not, where can I change the defaults to TIFF/32bit output in the script?

Did you look into reading the metadata to get lens correction right before the merging process? I would also avoid sharpening before the merging because AFAIK that also can cause artifacts (Blochi also recommends to turn it off).
What do you think about creating 8bit AND 32 output at the same time? Or is that not possible within the architecture of the merger? It would be nice to have a tonemapped lowres (maybe 1920*1280) file ready after the merging to render out a preview quickly - rendering the fullres 32bit TIFFs in After Effects with ACR takes veeery long as you surely know.

The reason why I am interested to have direct DNG output is the following:
LRtimelapse (which I use extensively) is reading the embedded Jpegs in a RAW or DNG file to do the deflicker, so, to get it to work you need a Jpeg file.
This would save me the another manual step by having to go through Bridge or the DNG converter.
Anyway, it is your script and I am really happy you wrote it!

[dmilligan]

So I was looking at MergeToHDR.jsx, the script written by Adobe that is builtin to photoshop (my script simply calls certain functions in this script), and it appears that it sets some kind of special flag in ACR that tells ACR to output a linearized image, and ignores all the xmp exposure settings. So this is actually ideal and what you were trying to do with the ACR settings that supposedly give you close to linear output. This is what photoshop is actually doing during an HDR merge, so the ideas in that article about optimizing ACR settings for HDR are just flat out wrong, photoshop basicially optimizes this itself automatically.

Code: [Select]

// Set flag for Camera raw asking for linear response files.
mergeToHDR.linearizeCamRawFiles = true;

Maybe we can exploit this to get linear data out of ACR for other purposes?

- I would suggest to move the "Deghosting" up and next to the "Alligning" checkbox because it has nothing to do with the toning part.

Done

- Would it be possible to add an automatic filtering for image files, so one doesn't have to type in *.CR2/NEF or whatever the file format is that you want to process? Knowing me, I would forget that filter in 1 of 5 cases... :-/

Change line 52

- Could the toning part be made collapsible?

I can hide it, but I can't collapse it. It would just disappear and the window would stay the same size, with a large blank spot in the middle. ScriptUI is rather limited and quirky when it comes to layout. I will make it greyed out though, so it is clear that toning is not done when outputing 32 bit.

- Can I set new defaults? If not, where can I change the defaults to TIFF/32bit output in the script?

line 329 and 333

What do you think about creating 8bit AND 32 output at the same time? Or is that not possible within the architecture of the merger? It would be nice to have a tonemapped lowres (maybe 1920*1280) file ready after the merging to render out a preview quickly - rendering the fullres 32bit TIFFs in After Effects with ACR takes veeery long as you surely know.

possible, but will take some work, main difficulty is a way to specify such a setting in the UI.

[Joachim Buambeki]

The latest version works fine for me aswell. Maybe the layout could be optimised further, but that can be done later.
Hiding the toning part is fine with me if it can't be made collapsible.
 
I wasn't aware about the fact that you *can* get linear data out of ACR - cool finding. I am sure this will be useful somewhere else.

I am not sure if Blochi is wrong, I suppose what he does with those specific settings is that he creates TIFFs with LR/ACR and heads over to another application to merge them to an HDRI file - if that is the case using those settings is very likely better than using the defaults - he probably isn't aware of the fact that you can get linear images out of ACR.
I invited him to comment on this and opened new a thread about this script over at his small community  - maybe people over there have more ideas to improve/extend it even further.

Could you please have a look at the compression settings? Those TIFFs are terribly huge, I guess the script saves them without any compression, right? Maybe adding another dialogue in your script to set up different compression parameters might be a good idea.

Also, adding EXR to the output options might be another good idea, since that is the defacto standard for HDRIs AFAIK.


PS: While browsing around I found this - not sure if you are aware of it or if it is of any use (I can't use it in my version of CC, but maybe you have a look at the code) you, but I thought I might drop the link in here.

PPS: Why didn't you copy the more the detailed instructions you posted on the Adobe forums to the opening post here aswell? Just curious...

[dmilligan]

Could you please have a look at the compression settings? Those TIFFs are terribly huge, I guess the script saves them without any compression, right? Maybe adding another dialogue in your script to set up different compression parameters might be a good idea.

done, you can choose lzw or zip (both lossless)

PS: While browsing around I found this - not sure if you are aware of it or if it is of any use (I can't use it in my version of CC, but maybe you have a look at the code) you, but I thought I might drop the link in here.

Yep, that was one of the scripts I found that inspired this script. That script just didn't do everything I wanted, but it was basically how I realized that there was an adobe script I could call to do this stuff.

PPS: Why didn't you copy the more the detailed instructions you posted on the Adobe forums to the opening post here aswell? Just curious....

No one ever expressed any interest, so I never bothered to update the post. I did put them on the wiki on github, so I've updated the first post with a link to that

[Joachim Buambeki]

I just updated my post above while you replied. Please have another look at it again

[dmilligan]

exr is possible I think, but it's not a native format for photoshop so it requires a plug in iirc, I'm not sure how to do it, but I think that script you pointed out can do it, I'll see if I can figure it out

[Joachim Buambeki]

Isn't EXR native? I know there is the ProEXR plugin, but you only need that if have files with alpha, depth, whatever masks in it if I am not mistaken.

Thanks for the lossless option, unfortunatelly the savings aren't huge (~20%), maybe you could have a look a look at the other compression options aswell. 24bit Logluv and the the 16bit option (however that works) should be fine for HDRIs derived from photos without a visible loss in quality. For EXR I strongly recommend to implement lossy compression, you can save quite a good amount of space without visibly degrading the image.
I can send you more info on compression and file types if you need it, that stuff is just too much above my head to explain it properly.

Regarding the UI:
I would suggest to have different dropdowns:
File type: TIFF, EXR, JPEG, PSD
Compression: JPEG Q1-12 (you might reduce that to 6-11 to keep the dropdown compact, who uses the other values anyway?), NONE, LZW, ZIP, 24bit logluv, 16bit half, ZLIB, WAVELET, RLE, PXR24, (options not available for the chosen file format should be greyed out if possible)
Bit depth: 8, 16, 32 (options not available for the chosen file format should be greyed out if possible)

If you can/want implement the lowres proxies with user defined resolution, I would split the JPEG part from the rest and make that separate paragraph in the UI add checkboxes for both paragraphs to enable/disable them.
Since you can use Camera Raw as a filter even for 32bit Images since PS CC, you could also use that to tonemap the images instead of the HDRmerge Pro toning Options (which I personally don't like) and use the XMLs you talked about earlier. When using it as a filter, generating a second image as Proxy should be easy within the scripting laguage if I am not mistaken.

[mikmac]

great script, thanks!
For panoramas in HDR its marvelous, but i have one problem.
For 3-pics HDR it works flawlessly, but 5-pic bracket makes error all the time, during loading images to PS... regardless of settings set in script
Win8, PS CC.

[dmilligan]

EXR is not native, I've checked. I can only save files with the options provided to me by Adobe's API, even if photoshop can save in some particular format, or with certain options, it doesn't mean I can do it from a script, b/c adobe may not have implemented that particular format in the API. The only compression options available for TIFF in the API are LZW and ZIP (well, you can also do JPEG, but if you're going to do that, why not just save as JPEG). The JPEG compression scale goes from 1-10 (at least in the API).

@mikmac,
I'd love to help fix you're problem, but I'm going to need more information than that. What exactly is the error you're getting? is it a scripting error, or some kind of general photoshop error? When exactly does it happen? can you send me a screenshot? Does it choke on any 5 bracket sequence or is it only certain files it's not handling?

[mikmac]

ehh.. something has broke, i dunno what...
I thought it was 5-pic bracket, but its not, it was just my last bracket to make today... Now I've made some tests and script stopped working at all 3-pic or 5 or 7 bracket.
All the time same error:


I've reload PS, whole computer and even reupload script - nothing. Files that script made already now stucks...



Forget above... i have to write *.cr2 to omit thumbs file... shit..during testing i forgot about it.

But still with my 5-bracket panorama i get an error:

Dunno why... I've made some other 5-brackets now and it works great, with that one it wont. Every single 5-bracket makes same error from this panorama (13x5brackets).

[RenatoPhoto]

I am trying to script.  Have three tif files but get this error:

[dmilligan]

Sorry, I left the debugger on. These were just internal exceptions in the adobe scripts b/c I had the debug level set to catch all exceptions (even handled ones in try-catches). It should be fixed now. You can always just press the green arrow to continue

https://github.com/davidmilligan/PhotoshopBatchHDR/commit/1c50faaa1e57e504c549a25a4a145343bf83f36b

[RenatoPhoto]

Now it stops at line 108

Error 1302 No such element
line 108
->   if(app.activeDocument != null)

[ERANTZ]

dmilligan, receive a big big thanks for that great script! As a 360º panoramic photographer I have to batch convert bracketed stacks to 32bit HDR all the time (7 to 10 HDR stacks per pano) and is a pain in the ass to manually merge each. This script has really eased out things for me and I'm quite happy about it! 

Now, I'm a Mac user and I found an issue that may be bothering other users when applying this script and I want to share it with you. Using the script with folders containing plenty of stacks I've been getting this error in PS:

"Error: No such element, Check number of files in source folder"

After dealing a while with it I found that there was a mysterious extra file added to the file list the script generated from the folder which for example indicated 4 images at a directory when having just 3 of them on it or 61 images when the directory just had 60 and that was generating the script error. What I fountd is that the mysterious extra file is the hidden file .DS_Store which OSX auto generates at each folder and is counted each time interfering with the script, the solution to this error is to manually delete this file at the directory (configuring previously the system to show hidden files) or to just deactivate this file auto creation.

After discovering this I'm using the script fluidly without any trouble. Hope this info helps somebody else and thanks again for this marvelous tool!

Luis

[dmilligan]

Hint: you can use the filter field, example: *.CR2

Then only cr2 files will be included from the source folder

Windows users may have similar issues with thumbs.db

[engardeknave]

Just tried this now but I'm getting:





The message isn't referring to a line in the script though because it happens no matter what's on line 182. I'm doing this in in Photoshop CC. It happens no matter what the settings unless I put only one frame per set.