Lumariver HDR: new HDR software with raw-in-raw-out capability

[steveclv]

I can see what you are trying to achieve but I worry that you are concentrating so much on the technical excellence that you will miss the usability.

You are competing with products such as Photomatix which have a very easy to understand UI and produce excellent/very good results out of the box - your algorithms may be superior but unless you wrap it in a UI that is easy to use and understand then you may limit your audience to just a handful of people who want to take the time to really get into the 'nth' degree of HDR - whereas 99% of the audience may be happy to use something like Photomatix that produces an 'acceptable' result most of the time.

Just my 2c

[torger]

The tonemapper is intented to give natural-looking results, ie not the typical "HDR grunge look". We might add grunge algorithms later on if people request it, but it's not the niche we aim for.

The three "standard", "gradient" and "soft" components are quite straight-forward, while the "sharp" is a bit more experimental (less robust too, does not work well on all pictures) and would not be the tonemapping component you start with. Again you get the result as layers so you see exactly how the tonemapper has modified your picture, and you can export the result and use them as multiply maps in photoshop for example.

If input was raw you can save the result to a "cooked" raw DNG and import it into your raw converter and use it as a regular raw file.

It can be interesting to compare Lumariver HDR's tonemapping result with what your raw converter can do. Most raw converters don't do particularly well, with one exception; if you're a Lightroom user you already have a quite capable natural-look tonemapper. When it comes to natural tone-mapping there's a limit to how far you can take it without inversion artifacts, and we're up touching that limit. I think we do a bit better than LR, and you have the advantage that you get to see the exact result and there's no side effects in terms of saturation modification, we only work in the luminance channel. This also makes the result easy to export and further handle in photoshop.

Concerning tonemapping I have myself as a photographer felt that "my art" has been in the hands of the software makers, you pull some slider and something happens to the picture and you don't really see or understand what changes that were applied. I wanted to have something that can bring results further than traditional dodge-and-burn, but still be plain lighten and darken of pixels which you get to see how it's made and is neutral in the way it doesn't leave a "signature look" of the software itself. That's what we try to achieve with Lumariver HDR.

[torger]

I can see what you are trying to achieve but I worry that you are concentrating so much on the technical excellence that you will miss the usability.

You are competing with products such as Photomatix which have a very easy to understand UI and produce excellent/very good results out of the box - your algorithms may be superior but unless you wrap it in a UI that is easy to use and understand then you may limit your audience to just a handful of people who want to take the time to really get into the 'nth' degree of HDR - whereas 99% of the audience may be happy to use something like Photomatix that produces an 'acceptable' result most of the time.

Thanks for the feedback. I do agree that we have work to do on the user-friendliness, and we'll address that in steps. It can't be a super-easy program in the end though, because then we lose the "photographer in control" concept. We don't aim to be the number 1 selling HDR software. Finding our users will indeed be a challenge still. I don't really know how to do that in the best way, I'll think about that. Our intention is to start slow though, to not get a flood of users in the beginning, so we can give good personal support in this early phase where support is more likely to be needed.

Lumariver HDR is not the software one would use to get that cool HDR look one found in a picture on the web. It's a tool for a fine art photographer relatively experienced in post-processing that wants greater control when merging and tonemapping comes into play.

It's also for the technical photographer. There's really no established HDR software out there that can give you a merged raw or even TIFF that has the exact same linearity as the darkest raw in the set, there's always some hidden modifications going on. I had this problem when I was merging for reproduction photography. With Lumariver HDR you can do this.

There are few tonemappers out there I would use to make a fine art print that should look great rather than dated in 20 years. Lumariver HDR is for example an excellent choice if you like to do your fine-art post-processing manually in photoshop but need some added support by tonemappers. You can then bring this in from Lumariver HDR and as it produces neutral luminance maps they're easy to understand and further edit. We want the results from Lumariver HDR to feel open rather than mystical, so when you send your finished image to the printer you feel that you made the image to what it is from start to end.

With the import/export capabilities and multiple formats there are surely workflows you can have which we have not really thought about yet too.

We'll always focus on image quality. Sure we want to have algorithms faster than glacial, but we won't make realtime algorithms if we can get better results out of slower algorithms. We just need to find users that share the same desire of features that we do, it will probably be a quite small user group as you say though. If you want to reach the largest user group the program should have an entirely different focus, but we felt that in the HDR segment this is already well covered.

[steveclv]

The best software starts with a set of presets that deliver good results. That encourages users to experiment more and more. If was a major turnoff to load my pretty normal 5 shot HDR group and hit generate and see a black image

I realize that you don't want to restrict your algorithms functionality to be able to create real time effects - but if you have to tweak one value and then wait 20 seconds for a re-generate to show the result then I doubt many people are going to hang around long - we just don't have the time

I like the Photomatrix workflow in as much as you see an approximation of the processing before committing to a full render process. It can also create very attractive HDR even if their presets do err on the side of grunge

Because you are working in the visual domain, the software would need to be visual for good appeal and that means some sort of realtime operations. Also sliders, although not as precise as entering a number to 2 decimal places, is far more user friendly.

I applaud the efforts to make the intermediate steps available for post processing and intra process manipulation but I think it might have extremely limited appeal unless you can sweeten it.

[torger]

You're surely not talking to deaf ears , we'll see what we can do. Today the algorithms always work on the full-size image to give the exact result, which takes some time. It's a huge development effort to make multi-resolution algorithms with predictable results (ie same result on reduced size image as on the full size image), and one might need to sacrifice some quality on the way. Still it would surely improve the casual appeal of the app.

Some aspects are indeed already now suitable for multi-resolution, so we'll probably introduce that at some point, speed is always nice to have.

When you're used to the program you don't need much retries though. When the goal is a natural look it's only that much you can play with the values. As the software works in real stops and has absolute references (ie the scale is always the same, while slider-based software often adapts slider range after the image content) I know by experience what works a typical image. As I'm used to thinking in stops in the field (ie how many stops grad I use for a scene etc) I also like that the light control software I use do it too (one could have stop-based sliders though...). You learn quite soon where the limits are, and how you can combine the different tonemapping components for a particular scene. The tonemapper is not about creative effects (like Photomatix) but simply to reduce the DR of the image in the most natural-looking way as possible, and provide that result in an exportable way.

That the first view of a merge becomes as dark as the darkest image in the set, and that it is itself darker than the corresponding in-camera JPEG as we show the full range of highlights without compression we'll probably fix though by auto-setting an offset exposure and viewing curve or something. When you know how the software works the result is natural though, if you show the full range in the file without tonecurve, without clipping and without tonemapping it becomes dark. It's more of a "forensic" view as is, which we'll probably lighten up a bit (while still having access to the exact representation of course). Currently one can use the "Highlight Brightness" slider and "Exposure" settings to make the merge result easier to view, but we don't auto-set them.

[Hening Bettermann]

@ Torger, reply #6

> I can tell you that I'd really like manufacturers to adopt DNG , lots of our development time has gone into parsing raw files.

Why the need for raw input, as long as Adobe offers a free DNG converter? File size? That would not change if camera manufacturers would adopt DNG.

I am sorry that I don't have the time these days to test Lumariver more extensively, just let me say that I love your philosophy of making things transparent.

All the best!

[torger]

> I can tell you that I'd really like manufacturers to adopt DNG , lots of our development time has gone into parsing raw files.

Why the need for raw input, as long as Adobe offers a free DNG converter? File size? That would not change if camera manufacturers would adopt DNG.

If I would have done it from the beginning today I'd probably postpone native raw support -- it's indeed a lot of work and tough to maintain, and by using Adobe's own DNG SDK as we do the DNG support is excellent, you can even load and save floating point DNGs. The reason we still have native raw is to speed up the workflow a bit, you don't need to pass the DNG converter if you don't want to. I also had quite a bit of know-how from raw decoding as I also contribute to the open-source project RawTherapee, so adding it wasn't as bad as it could have been .

I've actually thought about making raw *write* support for some specific native raw formats (today we only write DNG if you want raw output), mainly Phase One's .IIQ, just because the among MF users popular Capture One software ain't that good at DNG.

Worth noting concerning Lumariver HDR is that from a user perspective there's no disadvantage from converting to DNG before importing, ie the only reason you'd open native raw directly is to save some time.

[Misirlou]

The feature that really intrigues me is the ability to manually edit the tonemapping mask. If I can wrap my head around that, this could be a really terrific tool.

[torger]

We've just released version 1.1.0, it has the following changes:

• Tooltips added, hover with the mouse pointer over any control to get some quick documentation.
• Drag-and-drop support for adding images.
• Support for changing DCP camera profiles at raw import.
• Image preview in raw import (to preview white balance, DCP etc).
• Support for more raw formats.
• Tone curve (highlight brightness and contrast) now a DNG style curve, rather than RGB. In other words film-like behavior of the tone curve without he colorshift problems an RGB curve has.
• Exposure and tone curve auto-set to a "out-of-camera"-like result at first raw import, to show a user-friendlier first result. Exposure and sliders at 0 still means a fully neutral rendering with preserved reconstructed highlight range (which often is quite dark and dull before tonemapping).
• Tone curve sliders rebalanced such that 50% on highlight brightness and contrast mimics a typical default curve used by cameras and raw converters.
• "Adjusted input" in the tonemapping tab will only have adjusted exposure (in 1.0 it could in some circumstances have adjusted contrast too).
• Renamed "normal merge" to "balanced merge" (algorithm unchanged).
• Add images menu option (same as Add images button).
• "Align" button always visible, but disabled when it cannot be used (to make informative tooltip visible).
• Changed white balance tint setting to work "Adobe" style with a (useful) range of -150 (green cast) to +150 (magenta cast).
• Exposure can now be set to negative (note that it will bring down clip levels below max, it's generally better to adjust contrast or reduce tonemapping strength instead).
• Locale cleanups.
• Various minor bug fixes.

[francois]

Thanks for the info. I'll give it a try next week when I have more than my ageing MacBook with me.

[kirkt]

The feature that really intrigues me is the ability to manually edit the tonemapping mask. If I can wrap my head around that, this could be a really terrific tool.

This feature is nice when you have a margin between two images that has an obvious defect in the automatic blend between the pixels.  This may happen on a uniform surface with soft falloff of light - the blend should be very gradual and continuous.  If you see that the automatic blend has left an obvious hard-ish seam, you can export the blend masks and soften the blend edge or shift the blend in the offending area to a seam at a harder edge in the scene.

Here is an example of this problem as illustrated by Guillermo Luijk in his tutorial about Zero Noise:



Figure 19 from this article:

http://www.guillermoluijk.com/tutorial/zeronoise/index.htm

Figure 19 reveals the Before and After image with a rollover on the source web page, so I made the above figure from the two images in the rollover.

In the "before" image (top) there is a hard seam that disrupts the gradual falloff on the wall next to the stairs, and the automatically generated segmentation map has also removed part of the persons lower body, due to motion of the subject and the confounding issue of ghosting.  In the "after" image (bottom) the segmentation mask has been manually painted back to correct both issues.  This permits the user to manually fine tune the merge of the source images if the automatic segmentation hiccups.

@torger:

Thank you for this application.  I trialed it and just purchased a license.  This approach is ideal for maintaining useable dynamic range in a raw or HDR workflow.  I am especially interested to see how it integrates with the DNGs produced by the Magic Lantern dual ISO feature, and how much data you need to feed your application to achieve a good DNG output.  I'll put it through its paces and report bugs or findings here, if that's okay.

kirk

[torger]

@Kirk: you can post here if you like, but there's also a forum the lumariver web which we intend for support stuff, and email and messages works too.

Concerning the blending; during development of the HDR merging algorithm we used very narrow seams in the first revisions, and that works okay most of the time, but if you have any smooth surface with even the tiniest changing light condition the seam becomes visible. There's also the issue with slightly different noise levels between the merged images that can cause a seam to become slightly visible. Therefore the current algorithm(s) in Lumariver HDR blends all seams, although not over a too wide area if not required.

These are the blend masks however, I think Misirlou referred to the tonemapping mask, or multiply map as we call it in the docs. If you edit that manually the what you'd usually want to do then is to add further dodge-and-burn, or to flatten areas you think should have the same uniform exposure. A tonemap which has large flat sections (flat=same scale factor, ie same gray) and has sharp transitions in suitable places is likely one that will look natural. A tonemap which is practically a straight black-and-white negative of the image will likely look a bit unnatural.

[Guillermo Luijk]

Concerning the blending; during development of the HDR merging algorithm we used very narrow seams in the first revisions, and that works okay most of the time, but if you have any smooth surface with even the tiniest changing light condition the seam becomes visible.

Be sure your visible seams are not because of deviations in the relative exposure calculation. How do you calculate the relative exposure between shots? if you just read EXIF metadata, visible seams are guaranteed since it is never precise. See this example: 3 shots 2 stops apart. First blend with properly calculated relative exposure (1,93EV) provides a seamless result. On the right 2.00EV correction reveals the seams:



The lower pair of images is the same as the upper pair with a contrast curve applied to make seams more visible.


BTW, did you get any inspiration for the DNG output? it's curious because I had exactly the same idea 5 years ago: ZERO NOISE VIRTUAL RAW.

So as other contents of your Manual such as zero noise HDR or 16 bit TIFF has more DR than you may think!.

Regards and good work

[torger]

We do not use exif data at all to calculate relative exposure between shots, it's probed by statistical methods. It's a slower algorithm but more exact. As I use a mechanical copal shutter myself (technical camera) which has like +/-15% exposure time variation shot-to-shot it's really necessary .

Yes I've known about your zero noise software, I've read your articles and got inspired, your term "zero noise photography" has got established on the forums so we used that in the manual. One of the reasons we started to make Lumariver HDR was that I did not find any of the established commercial HDR software that could do "virtual raw" files, ie keep the exact same properties as the original darkest file, just have it noise-free. The program is much about tonemapping though, and in the long term I think HDR merging will become less and less important due to increased dynamic range of cameras, but the tonemapping need will stay constant. We're not there yet though, there's still many applications where merging is useful.

[kirkt]

These are the blend masks however, I think Misirlou referred to the tonemapping mask, or multiply map as we call it in the docs.

I misread that - you are correct.  Sorry about that!

I'll check out the forum over at your pages.

kirk

[michael]

For what it's worth, Mac OS represents 37.3% of LuLa readers over the past 12 months.

Michael

[Hening Bettermann]

I am trying to get my hands on align_image_stack for use with Lumariver, but fail. This tool alone does not seem to be for download anywhere. The Hugin download from Sourceforge.net does not work. The download site refreshes after a short while, changing into something with 'post download' in the address bar, and saying 'thank you for downloading Hugin', but the download is far from complete, just started. This also applies to 2 of the mirrors linked to from the Sourceforge site - I did not try all, since the failure seems to be with the Sourceforge site.. A Hugin build downloaded from hugin.en.softonic.com, where the download worked, is outdated (2009) and does not contain align_image_stack as a separate file.

Anybody got a good idea?

edit:
I thought I had modified this post, telling that I would post the question in a new thread, which I have done in the meantime, got answers, and it's settled.

[Alan Smallbone]

+1

+1 here as well

Alan

[Hening Bettermann]

Now I got align_image_stack, but now I can't load images into Lumariver. I click 'Add Images', the File Navigation window opens, I select 3 images and click Open, a new window with the Preview window opens, but there are no images loaded in the 'Input Images' window (which now is hidden); if I click 'Render Image Preview', the app crashes. ??

[Hening Bettermann]

Problem solved. One has to click 'OK' at bottom right in the Raw Import Options window.