OpenMP, in general, ought to be more stable than TBB - it's been around much longer. This is not to say TBB is unstable. It simply is a generalization that stability increases with maturity.
If you have unstable OpenMP applications this is indicative that you have multi-thread safety issues in your code. Switching to TBB (Cilk++, etc...) will not fix an underlaying problem unless the port gives you an opportunity to fix a bug in your code or you replace a piece of your code with a solid MT library (e.g. MKL, IPP).
Where TBB has an advantage over OpenMP is when your problem can be decomposed application-wide into tasks. IOW the entire application is a collection of task (with synchronization here and there).
Were OpenMP (pre V3 with task sets) works well is were components of the application benefit from a n-way fork and join (e.g. parallel for where application is single threaded before and after parallel for). Nested parallel regions with nowaitcan improve the parallelization to some extent and OpenMP V3 task can extend parallelization further but the two tasking systems widely differ. As to which is better.... this depends on the extent to which you want to introduce parallellism into your code.
A secondary concern is:
Are you shipping a complete application?
Or, a utility library to be integrated by the user into their applicaiton?
If the former, then choice of threading model is your choice. If the latter, then the end user would want to choose the threading model (which means you may need multiple threading models for your library).
A third concern is:
Is the HDR working on a single still image?
Or, are you HDR-ing a video file?
If the former, then you will want to place your parallization inside each (the only) frame.
If the latter, then you will want to keep each frame single threaded and run multiple frames in seperate threads (parallel_pipeline on a frame by frame basis).