rawtherapee.com

[blk]

Gabor, thank you very much for opening up RT - this is incredible! - seems my donation a few days ago was very worth it.. i'll certainly be donating again, once i actually start using RT

I wish you all the best (especially with your family) and hope to hear from you in a few months about the good and bad changes this opening brought to RT and the donation flow.

cheers
_________________
Everyday is a gift, that's why it's called the present.

[hoeri]

[ben_pcc]

Hey!

Update on what I've been up to. Past weekend was a stale, boring weekend which I knew would be that way, so I took the work laptop with me and after two days of work... it works!

I'd like to post samples but it looks like this place doesn't allow attachments, and I don't want to link to my own university space.

The main issue right now is that it's slow. On this 2007 laptop the average image takes 40 seconds longer (12 MPx images), and 100 if I enable working with logarithms as the paper suggests. I can try a few different things to speed it up but no guarantees. One thing that might boost speed is if I switch from 32 bit floats to 32 bit integers (16 bit isn't enough for intermediate calculations), but that'd be such a pain in the ass.



Some suggestions. I might fix some of these myself when/if I get SVN in order.

Compile warnings. Too many. There are 10000 or so, there should be zero.

Also: it looks like image memory is allocated per row. Very bad! This invites memory fragmentation which will result in overall poorer performance. It's better to allocate the whole image with one new command. This can be done with no change to code which uses image data, only code which creates and kills the data. Allocate the image, and also allocate an array of pointers to each row.

[DrSlony]

I would love to see some examples!

Creating & uploading screenshots,screencasts,code,files

[ben_pcc]

Sorry for not seeing that. Meh, screw it, I uploaded here:

http://web.cecs.pdx.edu/~ben_s/Linked/RTTest01/

In the directory, files ending with -1 have dynamic range compression applied.

It's overdone on purpose so you can see what it does. For best results less is used in combination with a tone curve. Despite lost overall contrast, typical problem spots are improved and noise is not magnified.

An interesting thing I noted is that if you look at the gradient of an image (not uploaded), blow highlights show up as unusual black spots. So if some smart individual who is more interested in the task then me wants to fill such black spots with, maybe, an interpolation over boundaries or something, then highlight recovery could be built into this.

I got integer solution half working but I'm not sure it's much faster.

[paul.matthijsse]

Hello,

Today I downloaded your photos and compared them on two different monitors: a modern but cheap lcd screen (with higher contrast) and an old crt (that is visually calibrated to the output of my photolab).

I am sorry to say that I do not see the added value of your algorithm. The highlights are somewhat reduced, the shadows are a bit lighter. Overall the contrast is less strong, but not strong enough imo. This is often - and logically - the case with attempts to make hdr/ldr images.

That first shot (the buildings at night) is a rather good shot, in technical terms, but your enhancement is in my opinion not a big deal. The enhanced version of the nice shot of those cars in the rain is less powerful (or meaningful, in photographic terms) than the original one. Because it is more flat. Didn't you want to reach the opposite goal? Same applies to the shot of the person who repears the wheel of a bike: the original is more natural and therefore - in my eyes only of course - better, because more pleasant.

I also played with your original (but small) jpgs in RT 2.4.1, especially with the Shadows/Highlights tool, including the Local contrast option. I could not really reproduce the things you did to the photos, but I think it was not far off.

Perhaps the effects of your algorithm are better visible with other kind of shots, I don't know. For now I think I'm not going to use your trick, even if it is available in RT one day. The latest Digikam (v1.0.0, no beta anymore) offers something like this as well (local contrast it's called there), but it doesn't convince me neither.

The best thing I saw so far in this field (I'm a Linux-only person) is enfuse.

Please no hard feelings, every suggestion to make RT better is very welcome, as I use this app on a nearly daily basis. I just gave my humble opinion!

Regards, Paul.

[ben_pcc]

No hard feelings at all. Like I mentioned it's overdone on purpose, and I've already been aware that best results come from light use of this (lighter then what I did) in combination with a tone curve. I think that a good tone curve is key to most RAW processing.

When used properly it's a very subtle effect, especially if the dynamic range is low. That you need to combine it with a tone curve is most obvious in the bike repair picture, some details are brought out but the whole thing has lost contrast which should be fixed with a tone curve.

The sample images do show a few high points, the night road scene does look better overall for me and that's probably because it has much dynamic range but almost no highlights blown (so the application is "appropriate"). In the daylight road scene the foreground looks better (it's a flash photo...).


I made it 3 times faster yesterday, still rather slow but not totally embarrassing, and there's still some room for improvement. When it's faster it'll be less of a pain in the ass to find optimal parameters so maybe I can actually provide some improved images.

[DrSlony]

Paul: digiKam's local contrast is actually enfuse :) I'm compiling 1.1.0 right now, can't wait to try out some of the fixed bugs I reported.

ben_pcc: unfortunately, like paul said, your samples didn't speak to me, but I think the problem was with the images you chose to demonstrate the effect. I wouldn't ever want to lighten the shadows in those shots! :] I will send you a sample RAW or two that I'd really like to see handled by your algorithm, I'll paste the link below soon once it's uploaded. I'd be most grateful if you could give it/them a go :]
The one with the tourists walking past, low-angle, was recovered best when using digiKam's local contrast. Using enfuse by itself caused too distinct halos once the shadows were lightened up to a level I was happy with, but digiKam's implementation handled it very well! I used 1.0.0 for it where the tool and preview were somewhat broken, will eagerly try it out again in 1.1.0.

[helmut]

I intended to make a donation to support RT via my credit card, however Pay Pal seems not to accept MasterCard (they did accept a couple of month ago). Since other people might have a similar problem, you should investigate the problem.
Kind regards, Helmut

[ben_pcc]

Ok. Maybe I should hold my mouth until I have decent things to show.

Let's try again. I'm now working with logarithms as the paper suggests. Output is less tragically flat now, but still it would benefit from before/after tone curve adjustment (which I can't do because the alpha I'm using doesn't have it).

So check this directory again:

http://web.cecs.pdx.edu/~ben_s/Linked/RTTest01/

Images aren't always improved. This is an effect which should be used lightly where appropriate. This one is my favorite improvement:





(top: without dynamic range compression, bottom: with)


Some commentary...

The tunnel looks ugly because of highlight clipping. Other then that, note details brought out of formerly black areas.

The hammer is saved from being a silhouette (though I personally like a silhouette and so wouldn't use it on this image!)

The next scene, shown above, I'm under lights. So naturally there's a lot of dynamic range to compress. I think it worked best on this. You can actually see the trees and lit areas aren't too bright, although some of the clipped highlights have become grayish which is yucky.

Bike repair: this could be nice but it's an over application. That's me by the way, I'm such a camera whore.

Last one: markings on road look bad but that would be fixed with tone curve adjustment. Looks nice otherwise.


Edit: adding this effect for the full size images now takes average 15 s more. For low res previewing it takes 0.1 s! I'd say it's now fast enough to be useable.

[janrinze]

Hi Ben,
It seems there are some people really working on new stuff. Is your code going to be closed source? if not, it might be nice to add the code to the SVN so others can experiment, give feedback and even help with optimizing the code.

Best regards,

Jan Rinze.
_________________
Pentax K-7, Pentax K-x, Tamron 28-75/F2.8, Sigma 50-150/F2.8, Pentax 16-45/F4.0
Core2Duo 8400, Debian Squeeze (64bit) , RT built from main repo and frequently updated

[blk]

the whole point of GPL is to keep changes public and under the same license so all this work will be enjoyable by all.. now the thing is that this doesn't mean that it's gonna land in SVN because gabor is free to take or leave any changes the way he likes to manage his project but if he doesn't take them someone might just open his own branch to the public and sync it to gabors. Or you can just apply the patches yourself once they're published (which they should be - best place seems to be the project page on google code). Now you'll just have to convince these devs to release/publish early and often
_________________
Everyday is a gift, that's why it's called the present.

[ben_pcc]

Oh, this is neither new nor original. I'm doing this:

http://www.cs.huji.ac.il/~danix/hdr/

But a few things different conceptually and everything different numerically. Not closed source, but not in SVN yet either. If you're curious or want to fool around here's what I have so far:

http://web.cecs.pdx.edu/~ben_s/Linked/RTTest01/DynamicRangeCompression.cc


QTPFS already has this but it's very slow and the results are very bad. I think due to poor numeric solution of the linear problem. I go with conjugate gradient:

http://en.wikipedia.org/wiki/Conjugate_gradient_method

[DrSlony]

Here's the url of a file I'd like you to try your algorithm on:
Mirror 1: http://filebin.ca/konfeh/0072.pef
Mirror 2: http://www.speedyshare.com/files/20796089/0072.pef



The original is on the left, the right shows the image after running it through digiKam's "local contrast" (enfuse).

Am I correct in understanding that you wrote code which can tonemap - compress the dynamic range of a scene so that you can show a high dynamic range scene on a low dynamic range medium while preserving local contrast?

Although the whole dynamic range of the scene in my photo was captured (almost nothing is over or under exposed) I was under the impression that what you were working on could brighten up such dark areas without producing halos.

---

Disclaimer: the people in that photo, "0072.pef", are random passers by on public ground. As far as that photo is concerned, they are not in support of RawTherapee, digiKam, or any other program mentioned in this thread. All rights reserved by me, use granted for testing RawTherapee, digiKam and ben_pcc's algorithm. If you would like to use the image for reasons other than those mentioned above, contact me for permission.

[ben_pcc]

I think I'll put some more time in this before trying your test... enfuse output looks hard to beat (I'd know... I use enfuse sometimes). This image is a lovely stress test :->