Luminous Landscape Forum
Raw & Post Processing, Printing => Other Raw Converters => Topic started by: torger on November 25, 2013, 08:28:24 am
-
This is a commercial announcement, but as a long-term and active forum member I thought it would be okay, and I'll of course be around to answer questions etc, so it's not just a fire-and-forget spam announcement :)
We're doing a "stealth introduction" of our first commercial photo application called "Lumariver HDR". Actually it's here at Luminous Landscape we announce it first. We've had it ready for a while but it took some time to get our Apple Developer ID for signing, but at last it's there ready to download and install.
It's an HDR software that can do merging and tonemapping, and is in that far from unique, but we have some features that makes it one-of-a-kind:
- The tonemapping algorithm is made to produce natural-looking results. We're not after the "HDR grunge look", but simply control difficult lighting situations and produce a natural-looking image. I think myself that we are up there with the best in terms of results :), and you get to see the resulting multiply map which you can export to work further on in photoshop etc.
- It can read raw files (various formats) and merge to raw output (DNG), so you can work with the file in your favorite raw converter just as if it was a normal raw file.
- Import/export: all output is made visible as layers, including merge maps and the tonemapping multiply maps, and can be exported/imported to your favorite photo editor such as photoshop for further editing.
- Raw highlight reconstruction: optional advanced reconstruction of highlights such that you can get the sun center be yellow etc.
- No black magic hidden away from the user, you get to see the true linearity of the file, all output as layers, we don't hide away anything from you. We want the photographer to be in control and be able to see what the algorithms do.
- "Zero-noise HDR" and reproduction HDR, you can merge raw files into a new raw file with the exact same properties as the original (ie no modification to linearity etc), just without noise in the shadows, which can be useful for those that just want to have an extremely robust file for post-processing or just noise-free raw in reproduction work. I've used it myself when copying dense color reversal films.
- LCC (flat-field correction). I'm a medium format tech cam user myself so I've of course made sure it works well with a tech cam workflow. I often shoot with grads myself to capture large DR in one shot in the field, and LCC-cancel that and tonemap with greater control in Lumariver HDR, that workflow and others are described in the manual.
- Supported formats: TIFF 8/16/32 bit floating point, OpenEXR (an HDR format), various raw formats (.cr2, .nef, .iiq, .mos etc), DNG input and output (including floating point DNGs). The wide input/output possibilities makes it possible to do merging in this HDR software and tonemapping in another or the other way around.
You find the manual and a fully functioning trial at http://www.lumariver.com (http://www.lumariver.com). I recommend to take a look at the manual (http://www.lumariver.com/Products/LumariverHDR/Manual/).
Currently it's Mac OS X only. We work on full-size floating point images so it's a resource-hungry software, we recommend running it on a fairly recent and powerful machine, especially if you work with high res medium format files :). We've focused on getting best quality possible in the output rather than speed, we expect to improve speed in further updates though. I shall be honest and say that we don't aim for the casual user, while we try to not be too user-unfriendly it does not hurt to be somewhat familiar with how digital photography works and HDR in general.
I use the software myself for my landscape work. My favorite workflow is shooting one raw with a grad to control the sky, LCC to cancel out the grad (and color cast, I have a tech cam), import in Lumariver HDR, tonemap it, and export to DNG (ie raw in raw out) and open up in my raw converter and make further adjustments there. It's open for many other types of workflows though. When I make a fine-art print I almost always make manual fine-tunings in a photo editor and then I export the tonemap multiply map layer(s), may also adjust merging if the image is a merge.
If you have any questions write here in this thread, or post me a private message or email me.
-
Sounded interesting till I got to the "Mac OS only" part.
According to this most recent report, a Mac only product addresses a small and declining 13.4% share of the market.
http://money.cnn.com/2013/10/10/technology/mac-pc-sales/
-
Sounded interesting till I got to the "Mac OS only" part.
A large part of our code is cross-platform, in fact I've developed the algorithms on a Linux system so we hope to provide a Windows and possibly also a Linux version eventually. We're a small company though so we had to choose one platform to start with and then aimed to provide the first release on the platform with the most potential users. We think Mac is much stronger among advanced photo users than it is in general, that's why we chose Mac. If we would look at the quotient of Mac users on this site for example I would guess it's more than 50%. But yes it was a bit of a gamble, don't know if we made the right choice, but I think so :).
We will primarily focus on supporting coming users and expanding functionality of the software, but we do desire to also provide a Windows version sometime in the future.
-
Just what I've been looking for, torger. Thanks for posting this. Have some questions...
How's color management dealt with? The manual makes it sound a bit confusing as to what's going on. Does the app read Pentax PEF and other not so popular manufacturer's Raw formats which don't have custom color profiles? Does it read ACR 4.4 default profiles (Adobe Standard?) or is it better to convert to DNG, embedding a custom DNG profile in ACR/LR prior to opening in Lumariver HDR? What is the color space source that drives the previews?
Is there a place on that site where we can see larger if not full size screengrabs of Lumariver HDR interface? (I won't be able to try it out for now since I'm on OS 10.6.8/2010 Mac Mini).
Looks really promising and quite useful for photographers. Good work!
-
> According to this most recent report, a Mac only product addresses a small and declining 13.4% share of the market.
This is the sale of computers overall. I have no figure, but I'm sure the percentage of Macs amongst photo enthusiasts is a good deal higher.
-
Hi,
If I check visit to my site, which is predominantly a technically oriented photography site, I can see that over 50% of my visitors have a Apple OS, MacOS X or iOS.
Nice to see that Anders Torger has developed a new tool, I see forward to testing it.
Best regards
Erik
> According to this most recent report, a Mac only product addresses a small and declining 13.4% share of the market.
This is the sale of computers overall. I have no figure, but I'm sure the percentage of Macs amongst photo enthusiasts is a good deal higher.
-
For DNG input and outut we use Adobe's DNG SDK. We base our proprietary raw decoding on the dcraw parser, which have built in color matrices (if not provided by the format, which raw formats usually don't) for the formats it supports. These matrices actually come from Adobe's DNG converter in general.
If Adobe's DNG converter is installed we get color matrices from the corresponding Adobe standard DNG. In this first release the DCP color correction code is not enabled since there was a few issues to iron out but we plan to enable that soon. All this is only valuable if you read raw input and write say TIFF output. If you write DNG output the color management will be taken care by the raw converter you open the DNG in. The internal color space used for raw files is Prophoto, same as the reference color space used by the DNG specification.
With TIFF input we support the typical matrix shaping profiles you would use ie sRGB, AdobeRGB or Prophoto, the software tunnels the icc from input to output, and displays colors properly according to the display profile.
We do support a large variety of cameras, but it's hard to make a precise list. We could copy Dcraw's list, but some cameras require some further fine-tuning to provide good quality. I can tell you that I'd really like manufacturers to adopt DNG :), lots of our development time has gone into parsing raw files. I intend to help out if problems do arise with a camera model, it's often just some fine-tuning fix required. If it's a huge reverse-engineering job I can't comply though, but that's rarely the case. We did run into problems with Leaf's new Credo models though, they use some new revision of the IIQ format which we don't have support for yet. I'm also a developer in the open-source RawTherapee project and there I have among other things contributed with support for various camera models. We do read .PEF. Note that we only support ordinary Bayer array cameras though, ie no Fuji X-Trans or Sigma Foveon unfortunately
To be more specific on the CM question. If you want to read raw and write TIFF output we do not yet have full color management support, as we don't apply the DCP color corrections. We do get matrices though, so you get okay color, but for me to say that we have full CM support I want the software to provide a possibility to choose a camera profile which is not yet possible. This feature would only be used for RAW in TIFF out though, and we suspected that most users would do "TIFF in TIFF out" or "RAW in DNG out" or "DNG in DNG out" and then it does not matter, so we postponed it for a later release. If you open DNG instead of proprietary RAW for input does not matter from a color management perspective in general, unless you attach some custom profile with a custom color matrix to your DNG.
When I use the software myself I usually open .mos from my Leaf Aptus and save to DNG for further processing in RawTherapee or Lightroom. Unfortunately some raw converters have a bit dodgy DNG support, so if you are for example a Capture One user you'd probably want to use a C1 -> TIFF -> Lumariver HDR -> TIFF -> C1, at least if you want to take part of C1's color rendering (which kind of sucks in the DNG case :( ). In the "fine art" case when I really want to fine-tune I want multipage TIFF output from Lumariver HDR so I can post-process further in say photoshop then I usually prepare TIFF input so color rendering is complete before Lumariver HDR is inolved. However if there's a merge involved I do that first, raw in raw out, as merges get more precise that way.
No screen grabs yet unfortunately, we wrote the manual at the same time the GUI was moving around a bit in design so I did not dare to make screengrabs then as I would have to redo that work :). The GUI is pretty basic though. We do merging and tonemapping with a few parameters and generate and display layers.
-
Let me know when you have a Windows version and I'll be happy to give it a try!
Mike.
-
Let me know when you have a Windows version and I'll be happy to give it a try!
Same here.
Cheers,
Bart
-
Let me know when you have a Windows version and I'll be happy to give it a try!
Mike.
+1
-
Let me know when you have a Windows version and I'll be happy to give it a try!
Mike.
+1
-
I'll give it a try tomorrow… Looks promising.
-
I'm just about to download it and give it a try on a 2013 Macbook Pro, Mavericks and processing Nikon D800 NEFs however I can't find a mention of the ultimate price. I'd hate to fall in love with a new piece of software only to find that I can't afford it when it gets a final release :)
How much??
-
OK, found it - on the download page - 50 Euro ;)
Sorry!
-
OK, so do you want feedback here on the forum or via pm or email?
I installed and opened - went to grab a string of 5 bracketed NEFs but it would not select the NEF files, either from the File/Open command or the Mac drag and drop.
I'm sure I read that you supported NEF files.
-
OK, so do you want feedback here on the forum or via pm or email?
I installed and opened - went to grab a string of 5 bracketed NEFs but it would not select the NEF files, either from the File/Open command or the Mac drag and drop.
I'm sure I read that you supported NEF files.
You need to "Add Images", it's a button on the right of the window. I had the same problem. Drag and drop doesn't work.
-
Oh for heavens sake ;)
I needed to scroll the right pane to see the menu items at the top LOL
Thanks, I'm now playing a little more.
-
OK, so I have managed to load up 5 bracketed shots - -2,-2,0,+1,+2
Firstly I try an Normal Merge and get "Too small well-exposed overlap between images to be able to match tonecurves" - I had set 'Noisy' to be 1.00 and Underexposed to be 2.00. I then tried again with the defaults of 4.00 and 6.00 and just got a very horrible mess of a dark underexposed result.
We do need some guidance on how to get this software to work please :)
-
…
We do need some guidance on how to get this software to work please :)
I agree 100%. Something like a video tutorial on Youtube/Vimeo/etc would be useful.
FWIW, I played a few minutes and got good results but I don't know how and reading the documentation makes me think that I missed a lot of features.
-
Yes we probably need to make a video :) , it's a quite technical piece of software. It's on the todo list for sure, as well as tooltips. And implement drag-and-drop sounds like a good idea too ;).
Concerning bracketing I'd recommend that you space the files about 2 stops. The typical input I use for merging myself is three shots, one ETTR shot, one +2 and one +4. Some more shooting tips is found in the "HDR shooting tips" section in the manual (http://www.lumariver.com/Products/LumariverHDR/Manual/).
When it comes to picking out well-exposed pixels the defaults are quite good. If you set the values too small on "noisy" and "underexposed" the merger won't find a overlap. The unit is "stops from saturation", so the default of 4.00 says that "all pixels withing 4 stops from saturation (=clipping) is virtually noise-free and can be used as-is". The closer to saturation you specify these values the tougher the task for the merger will be, so it's wise to set "sane" values.
A Nikon D800 has class-leading dynamic range so you could probably change 4 and 6 defaults to 5 and 7 and still get "virtually noise-free" results.
The merger part of the software is pretty straight-forward in terms of functionality, you can merge with the different algorithms and the clipping/noisy/underexposed settings, and import and export resulting layers, as well as save the resulting output in various formats, including raw DNG. You can export a merge layer, edit in for example photoshop and import it again and make a new merge with that mask if you don't like the merging algorithm's choice.
The idea of the merger is that it should provide you with a really good default, it shows the result to you and you'll be able to inspect it in detail, and if you're still not happy with the merge you can adjust it. It's not (yet) possible to edit the masks inside the program though, you need to export/import them. Being able to see the result and having good possibilities for export/import is a key design choice. I'm a perfectionist myself and I don't like it when software hides away what they've done or limits my abilities to control the result. When I do casual work I do with the defaults, but if I make that important fine art print there's almost always some fine-tuning to be done, regardless how great algorithms are.
On raw import there's also a "raw highlight reconstruction" which can be very useful for some pictures, if your darkest picture have clipped highlights we have an algorithm to reconstruct the highlights in raw. Unlike highlight reconstruction you find in raw converters our algorithm takes risks to be able to reconstruct more, ie it can fail (and then you choose standard reconstruction). The advantage of this is that you can get very good results in situations it works. It often works very well for partially clipped clouds and sun, as long as the clipping is not too heavy. Examples of that is found in the "Highlight reconstruction" section of the manual. If use it myself to reconstruct when I've been too daring with ETTR, or when I want to have a pale yellow in my sun center rather than just clipped to white.
-
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
-
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.
-
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.
-
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.
-
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.
-
@ 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!
-
> 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.
-
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.
-
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.
-
Thanks for the info. I'll give it a try next week when I have more than my ageing MacBook with me.
-
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:
(http://kirkt.smugmug.com/Photography/Link-Share/i-WqvwSms/0/O/ZNmask.jpg)
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
-
@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.
-
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:
(http://www.guillermoluijk.com/tutorial/zeronoise/calculo.jpg)
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 (http://www.guillermoluijk.com/article/virtualraw/index_en.htm).
So as other contents of your Manual such as zero noise HDR (http://www.guillermoluijk.com/software/zeronoise/zero.jpg) or 16 bit TIFF has more DR than you may think! (http://www.guillermoluijk.com/article/superhdr/index.htm).
Regards and good work
-
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.
-
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
-
For what it's worth, Mac OS represents 37.3% of LuLa readers over the past 12 months.
Michael
-
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.
-
+1
+1 here as well
Alan
-
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. ??
-
Problem solved. One has to click 'OK' at bottom right in the Raw Import Options window.
-
+1 :)
-
Sorry I've been missing out on this thread for a while, but it seems the issues been solved. We've unfortunately not had the time we'd like to make the windows and speeded up version to happen yet, but we're planning to get a maintenance release out with some new camera support etc.
-
Hi Torger
I post a problem here, since there does not seem to be much traffic on the Lumariver home forum.
I see a gross color shift between source images and a Lumariver merge, see attached screen shots. Lumariver 1.1.3, Mac OSX 10.9.5. Lumariver mode was 'Merge without ghosting'.
Color space is LargeRGB-elle-V2-g10, a ProPhoto with gamma 1.0.
What is going on? Is there something I've done wrong, or is this just the way it is?
Kind regards - Hening.
-
Hello Hening,
It's best if you send me a private message, mail me at my private address torger@ludd... or the support address we have on the Lumariver web, as I don't keep my eye on all forums here so I can be slow answering.
The merged result seems clipped by some reason. The best way to help if you send me files so I can rerun the scenario locally. I don't really know what the problem can be from the screenshots.
-
Hi Anders,
thank you for your fast reply. I'll try to send files in a couple of days. Right now I'm in a hotel, and the Macbook alerts me that another computer on the wi-fi network is using my IP address, so I dare not stay in that network.
Best regards - Hening.
-
I have now uploaded the files to Dropbox and entered your above e-mail address, is that OK? I'm not familiar with Drop Box, it says that you can VIEW the files, not sure if that includes download.
-
Thanks, got the files, tested them and it worked for me just running the defaults, but it could be that you've set the clipping parameter to 0? I've sent an email to you with more details.
-
Hi Anders,
thank you for the test you have performed in the meantime, and your PM. Yes indeed, I had set Clipping to 0. I thought I had given the parameters, but see now that I had missed this one.
Given your diagnosis, I have now successfully stacked this image.
Thanks again for your help, and for this fine program as well as DCamProf!
Hening.
-
Is there a Windows version of this software yet?
-
I tried a quick test of LumaRiver using three bracketed shots of high-dynamic scenes, handheld, on the ASP-C Ricoh GR (it's quick, easy and produces DNG as native raw format). The images were recorded at <1/200s so although there's probably some hand movement between the images in each bracket, they're not visibly much out of alignment.
I set white balance in LR then exported the DNGs and imported them into LumaRiver using default settings (I also tried using my own DCP for the GR).
The LumaRiver output images showed serious stitching issues easily visible at 1:1, especially misaligned vertical and horizontal edges.
Neither Photoshop nor LightRoom CC HDR merges of the same images showed the same alignment problems (different merging algorithm, I know). But the local quality of the output images (noise in the shadows) was lower than quality of the LumaRiver output images. The un-toned LumaRiver output DNGs were very suitable for tone/contrast curve management in ACR/LR.
Has anyone else seen the stitching problem? Perhaps it's specific to the GR or to small-sensor images.
-
LumaRiver does not do image alignment - the artifacts you are seeing are probably related to misalignment of the source images. LumaRiver works fine with my GR.
kirk
-
LumaRiver does not do image alignment
Sure it does.. sort of. On my trial version there's a button on the main dialog that reads "Align". The Manual says that LumaRiver does not align images itself but calls the "align_image_stack" tool in the Hugin distribution if available (it is, on my Mac).
I have since tried several .nef images (not converted, leaving it to LumaRiver to do the demosaicing, or at least to call some other d-m processor). The alignment issues I was having have not reappeared, fortunately.
Still trying to work out a good color-managed workflow with LumaRiver.
PWG
-
I revive this thread (on this christmas day) to find out if the people who are using Lumariver HD can chime in and can share their experiences with the software.
I did some initial testing and think it works very well.