Luminous Landscape Forum > ZERO NOISE technique

Iliah

Mar 30 2008, 07:03 PM

Dear Guillermo,

QUOTE (GLuijk @ Mar 30 2008, 11:50 PM)

Right, but I necessarily have to go to 16-bit integer TIFF in the end.

Photoshop works with RGB TIFFs in floating point quite nicely. Even better, you can use http://www.openexr.com/ as an output format. Native support on NVIDIA cards allows for much faster calculations over bitmaps. There is a Photoshop plugin that allows to open EXR files.

barryfitzgerald

Mar 30 2008, 07:56 PM

Intersting thread, have to say though..noise that is grain like, is not really a problem to me. I fear the meltmaster plastic look too much I am afraid.

ejmartin

Mar 30 2008, 08:12 PM

QUOTE (ejmartin @ Mar 30 2008, 03:29 PM)

You can find the equations for converting among color spaces at

http://brucelindbloom.com/

under the "Math" section.

Note that there are matrices M for converting among color spaces, in particular for converting from XYZ to rgb. Furthermore, it sounds like you want to do a manipulation of the luminosity data in Lab space; the transformation between Lab and XYZ is more complicated than a simple gamma transformation, as you can see from the formulae on the linked site.

Jonathan Wienke

Mar 30 2008, 09:14 PM

QUOTE (barryfitzgerald @ Mar 31 2008, 02:56 AM)

I fear the meltmaster plastic look too much I am afraid.

The plastic look is the result of noise reduction eliminating detail along with noise. Improving the S/N ratio of the capture with actual image data instead of mathematical guesswork will not cause a loss of detail; you get more actual subject texture instead of noise.

dave unwin

Mar 30 2008, 10:31 PM

Very interesting thread and i'm looking forward to the official release!

As a bit of an aside, i have been very pleased with the Timothy Ames Enfuse plugin for lightroom which can provide a similar noise reduction, although without the control that your program seems to offer.

cheers

Iliah

Mar 31 2008, 08:46 AM

QUOTE (Jonathan Wienke @ Mar 31 2008, 02:14 AM)

The plastic look is the result of noise reduction eliminating detail along with noise.

Not only, it is quite often the result of suboptimal colour transforms and reducing colour gamuts beyond reasonable. In some cases it is CFA properties too.

Iliah

Mar 31 2008, 08:48 AM

QUOTE (ejmartin @ Mar 31 2008, 01:12 AM)

Note that there are matrices M for converting among color spaces, in particular for converting from XYZ to rgb. Furthermore, it sounds like you want to do a manipulation of the luminosity data in Lab space; the transformation between Lab and XYZ is more complicated than a simple gamma transformation, as you can see from the formulae on the linked site.

To convert to high gamma space on a PC one needs a destination space and http://www.argyllcms.com/

GLuijk

Mar 31 2008, 08:30 PM

One interesting issue that arised on a Spanish forum: a Canon 30D user experienced these artifacts when blending 4 RAW files with ZN: transitions in the blend switching areas are visible:

ZN calculated wrong relative exposures because DCRAW does not apply a correct saturation point for this camera (I found out is also wrong with 40Ds), so the RAW developments went wrong. DCRAW uses saturation 4095 on Canon 30D while it is 3398. We can see that in the pure RAW histogram of a saturated file:

I have set an option on ZN to set the saturation point which makes use of the wonderful option -S in DCRAW, recently introduced by David Coffin. Now relative exposures are correctly calculated:

Calculating relative exposure...
1.tiff: 1 (+0 EV)
2.tiff: 4,17 (+2,06 EV)
3.tiff: 17,06 (+4,09 EV)
4.tiff: 69,78 (+6,12 EV)
DONE

So final image before tone mapping (same exposure as 1.tiff):

Simple 2-curve tone mapping:

The transitions are now perfect, impossible to distinguish exposure gap.
Sample of SNR improvement with respect to 0EV shot (the only one that preserved the window):

And we can see a respectable real 13 f-stops of DR were captured.

CONCLUSION: saturation point of the camera is very important. For those experiencing this kind of problems (30D, 40D) I will implement a camera combo box in the next version of ZN with proper adjustments to fix this. Also the user will be allowed to manually enter the saturation point.

GLuijk

Mar 31 2008, 09:08 PM

A brief step by step screenshot taken from Dpreview (thanks to the signatory in the Kodak SLR forum):

BruceHouston

Mar 31 2008, 09:29 PM

Thank you again, Guillermo!

I look forward to the camera combo box version as I have a 40D.

Best regards,
Bruce

Iliah

Mar 31 2008, 11:21 PM

Each camera sample may have its own saturation point. More, they depend on ISO settings sometimes. It is better to test both floor and saturation points of any given camera then to rely on the constants hardwired into a programme.

GLuijk

Apr 1 2008, 03:15 AM

QUOTE (Iliah @ Apr 1 2008, 05:21 AM)

Each camera sample may have its own saturation point. More, they depend on ISO settings sometimes. It is better to test both floor and saturation points of any given camera then to rely on the constants hardwired into a programme.

I agree. The problem is that this is a bit advanced for regular users.
What do you think commercial RAW developers such as ACR or Lightroom do? have a huge table of saturation points for each camera/ISO pair, or just trend to clip highlights with a conservative low saturation point?

Iliah

Apr 1 2008, 10:12 AM

QUOTE (GLuijk @ Apr 1 2008, 08:15 AM)

I agree. The problem is that this is a bit advanced for regular users.
What do you think commercial RAW developers such as ACR or Lightroom do? have a huge table of saturation points for each camera/ISO pair, or just trend to clip highlights with a conservative low saturation point?

Normally converters use both approaches, meaning a table of conservative values

Two shots at each ISO setting, one with a lens cap on, the other - fully blown in each channel allow to make a table. Interesting that points for both green channels are not always the same. Next, camera serial number and a table of floor and saturation points make a nice base for improvement of raw conversion.

GLuijk

Apr 1 2008, 11:23 AM

QUOTE (Iliah @ Apr 1 2008, 04:12 PM)

Two shots at each ISO setting, one with a lens cap on, the other - fully blown in each channel allow to make a table. Interesting that points for both green channels are not always the same. Next, camera serial number and a table of floor and saturation points make a nice base for improvement of raw conversion.

Yes the first thing I thought of when I discovered the saturation point was not always 2^N-1, was that a very accurate RAW development could 'recover' a good amount of information in those shots that were erroneously taken with too high exposure values. In that way, commercial developers would not always be optimum.

Regarding the black level, I thought all cameras had hidden pixels so it was best let the developer analyse them to find the more precise black point to be substracted. At least DCRAW always worked fine for me in calculating that figure that varies quite a lot depending on exposure conditions.
Some cameras (like Nikon) unfortunately substract that offset in-camera, right?

BTW a friend of mine who has a Fuji S3 Pro has reported several times magenta casts in the highlights when using ACR to develop Super CCD RAW files. Probably the reason is a bit too high saturation point in ACR for the R captors in that camera model.

Plekto

Apr 2 2008, 07:54 PM

QUOTE (GLuijk @ Apr 1 2008, 09:23 AM)

Yes the first thing I thought of when I discovered the saturation point was not always 2^N-1, was that a very accurate RAW development could 'recover' a good amount of information in those shots that were erroneously taken with too high exposure values. In that way, commercial developers would not always be optimum.

Regarding the black level, I thought all cameras had hidden pixels so it was best let the developer analyse them to find the more precise black point to be substracted. At least DCRAW always worked fine for me in calculating that figure that varies quite a lot depending on exposure conditions.
Some cameras (like Nikon) unfortunately substract that offset in-camera, right?

BTW a friend of mine who has a Fuji S3 Pro has reported several times magenta casts in the highlights when using ACR to develop Super CCD RAW files. Probably the reason is a bit too high saturation point in ACR for the R captors in that camera model.

Wow. Digital photos that look like old-school film. I'm impressed at how the largest three problems - dynamic range, noise, and fringing are gone with your software. You do need a way to manually enter the saturation point of a camera, since I suspect that each camera is a tiny bit different as well due to manufacturing and optical changes.(perhaps slightly different with each lens, even, though I suspect it's a very small value)

Q: what camera was used? It's impressive to say the least.

I love the idea of applying this to a scanner as well.

Q2:Could you possibly change it to have "slots" that you put the files into, and then you can select which one is what value? (so it knows what order to properly blend everything if you have lots of pictures) That way you could have 3 or 4 or even 12 exposures to blend together.(why not, digital "film" is not a factor here - most cards will hold 10-12 raw pictures)

This has honestly made me reconsider whether I should be looking at digital or not.

P.S. could someone who has a film scanner show an example of this as well? Preferably a Minolta Pro with MF slide film?(probably have to use Silverfast, right?)

Jonathan Wienke

Apr 2 2008, 11:23 PM

QUOTE (Plekto @ Apr 3 2008, 02:54 AM)

Wow. Digital photos that look like old-school film. I'm impressed at how the largest three problems - dynamic range, noise, and fringing are gone with your software.

Welcome to the real world, Neo. Digital has obviously come a long way since you used it last; for most subjects, blending images is not necessary to keep shadow noise acceptably low. The only time you really need it is for high-DR situations like backlit subjects, interiors with brightly-lit windows, etc.

QUOTE

Q2:Could you possibly change it to have "slots" that you put the files into, and then you can select which one is what value? (so it knows what order to properly blend everything if you have lots of pictures) That way you could have 3 or 4 or even 12 exposures to blend together.(why not, digital "film" is not a factor here - most cards will hold 10-12 raw pictures)

There is no point in blending more than 3 images. 3 images 3 stops apart are very difficult to blend into a single natural-looking image. There's a limit to how much you can compress DR. See the "do you hate HDR too" thread for examples and discussion of this. 2 images is more than adequate in the majority of cases, and the more images you have the greater problems you have with alignment. And add a zero or two to your estimate of card capacity; the larger cards available can hold hundreds of RAW frames, possibly over 1000.

QUOTE

P.S. could someone who has a film scanner show an example of this as well? Preferably a Minolta Pro with MF slide film?(probably have to use Silverfast, right?)

Film does not lend itself to DR blending as well as digital. Film has a non-linear response curve, which makes calculating the correct blend values accurately much harder. And if the film isn't perfectly flat when exposed and scanned, aligning multiple frames to blend becomes problematic.

GLuijk

Apr 3 2008, 04:00 AM

QUOTE (Plekto @ Apr 3 2008, 01:54 AM)

You do need a way to manually enter the saturation point of a camera, since I suspect that each camera is a tiny bit different as well due to manufacturing and optical changes.(perhaps slightly different with each lens, even, though I suspect it's a very small value)

Lens does not affect camera's saturation point. I am planning to introduce a 'Calibrate' button, so just by providing ZN a saturated picture it would calculate the exact saturation point to optimise RAW dvelopment for each particular camera.

As far as I know, they don't seem to differ too much between units of the same model: I have tested saturated RAW files from two 40D's and both saturated exactly at the same level (13000 something).

QUOTE (Plekto @ Apr 3 2008, 01:54 AM)

Q: what camera was used? It's impressive to say the least.

If you mean in the sitting room sample, my Canon 350D.

QUOTE (Plekto @ Apr 3 2008, 01:54 AM)

Q2:Could you possibly change it to have "slots" that you put the files into, and then you can select which one is what value? (so it knows what order to properly blend everything if you have lots of pictures) That way you could have 3 or 4 or even 12 exposures to blend together.(why not, digital "film" is not a factor here - most cards will hold 10-12 raw pictures)

The present version of the program allows for up to 10 RAW files (autolimited, I thought more is simply stupid) and they don't need to be ordered. The program will order them by exposure level and calculate (not read the EXIF) the relative exposure between each pair of images. If the program allowed the user to enter the EV differences between the shots, the result would probably be wrong and transitions would become visible due to exposure differences.

QUOTE (Plekto @ Apr 3 2008, 01:54 AM)

This has honestly made me reconsider whether I should be looking at digital or not.

Digital cameras have become really nice devices Plekto. Their Aquiles heel today is DR and they are continuously improving. With this technique you can avoid the limitations in DR, but with the important limitation that it requires a tripod and a static scene.

Jonathan, I remember you would be interested in a blending with a 16-bit DNG output. Many people have shown a lot of interest for this option. To do that is no problem as long as we know how to build a DNG from scratch, so anyone who knows about the DNG format and would like to make a pure RAW blending tool, just contact me. I think it is not that difficult.

However, in such an approach, it would be a must to have the possibility for anti-ghosting and allow progressive blending in the border areas, since the result will be difficult to correct making use of the original RAW files. I want to try mi anti-ghosting and progressive blending ideas in the next weeks.

MichaelEzra

Apr 3 2008, 09:39 AM

Hi Guillermo,

you could probably contact Ed Hamrick (hamrick.com) regarding DNG output. His VueScan software has that capability, as well as blending of 2 exposres from a scanner input, but not from individually shot raw files. There is probably room for cooperation;)

Best,

Jonathan Wienke

Apr 3 2008, 09:49 AM

QUOTE (GLuijk @ Apr 3 2008, 11:00 AM)

Jonathan, I remember you would be interested in a blending with a 16-bit DNG output. Many people have shown a lot of interest for this option. To do that is no problem as long as we know how to build a DNG from scratch, so anyone who knows about the DNG format and would like to make a pure RAW blending tool, just contact me. I think it is not that difficult.

The complete DNG format specification can be found at http://www.adobe.com/products/dng/pdfs/dng_spec.pdf. It doesn't look that hard to write a DNG file once you have created all of the 16-bit linear RGB image data. I look forward to a version of Zero Noise that outputs DNG files with great interest.

GLuijk

Apr 3 2008, 06:11 PM

Just a sample of why I consider important to calculate the relative exposures ourselves, from whithin the code. The sample image (dinning room) was obtained from a {-2,0,2} camera bracketing, so to adjust exposure of the 0 shot to the -2 we would correct exposure by -2EV.

However ZN calculated less exposure correction: -1,91 to be exact:

Calculating relative exposure...
3.tiff: 1 (+0 EV)
2.tiff: 3,77 (+1,91 EV)
1.tiff: 15,06 (+3,91 EV)
DONE

Let's find out the difference in the final result when applying a -1,91EV correction, and what would have happened if we decided to apply -2,00EV:

The -2EV reveals the transition area (best seen in the bottom pictures that were processed with a curve to enhance contrast) while the -1,91EV correction yields a much better gradation.

To be honest, I didn't care too much on optimising this calculation; I think it can even be improved to focus on the relative exposure on those image areas where the transitions are to happen.

BR

Plekto

Apr 3 2008, 07:20 PM

QUOTE (Jonathan Wienke @ Apr 2 2008, 09:23 PM)

Welcome to the real world, Neo. Digital has obviously come a long way since you used it last;

2 images is more than adequate in the majority of cases, and the more images you have the greater problems you have with alignment. And add a zero or two to your estimate of card capacity; the larger cards available can hold hundreds of RAW frames, possibly over 1000.

Dang. I must have chosen the wrong color...

Yes I know about the capacities, too. But even if you had to hold a 100MB raw file from a digital back, you could fit a ton of them on a single card these days. Of course, this all isn't cheap.

I want the multiple exposures as an option for scenery and the like. Setting it on the camera and then messing with this free software... beautiful results when you want it to look like film. (I've even seen focus blending - which is also amazing)

QUOTE (Jonathan Wienke @ Apr 2 2008, 09:23 PM)

Film does not lend itself to DR blending as well as digital. Film has a non-linear response curve, which makes calculating the correct blend values accurately much harder. And if the film isn't perfectly flat when exposed and scanned, aligning multiple frames to blend becomes problematic.

I figured as much for the film. I'd obviously need software to automate the process so that I don't have to touch anything. But it also seems to be possible, and a cheaper alternative than digital MF backs.

QUOTE (GLuijk @ Apr 3 2008, 02:00 AM)

As far as I know, they don't seem to differ too much between units of the same model: I have tested saturated RAW files from two 40D's and both saturated exactly at the same level (13000 something).

Nice to know.

QUOTE

If you mean in the sitting room sample, my Canon 350D.
The present version of the program allows for up to 10 RAW files (autolimited, I thought more is simply stupid) and they don't need to be ordered. The program will order them by exposure level and calculate (not read the EXIF) the relative exposure between each pair of images. If the program allowed the user to enter the EV differences between the shots, the result would probably be wrong and transitions would become visible due to exposure differences.

Very slick. Just drop in and it figures it out. Very good. Yeah, that is easier than my idea. Pay no attention to my ramblings... these are not the droids you are looking for....

QUOTE

Digital cameras have become really nice devices Plekto. Their Aquiles heel today is DR and they are continuously improving. With this technique you can avoid the limitations in DR, but with the important limitation that it requires a tripod and a static scene.

This I can probably deal with as the shots that I care about are exactly that sort of thing. Some house or car or sunset whatnot that looks dreadful because of the shadows and the wide swaths of nearly continuous tones - often with the sun bouncing off of something or in the distance.

It does look like 3-5 exposures are needed, though, for best results. Adding that third midrange shot cleaned up the middle tones quite considerably. If you notice, 95% of the pictures that we enlarge or want to be large enough where this matters tend to be static pictures.

I'm now looking for a camera that can do quick bracketing like this - so I don't have to mess too much. But few seem set up for this - either they are limited to single steps instead of +/-2 or they only go to +/- 2 maximum(too limited), or can only do three shots.

But I'll find something, I'm sure

Being able to have it fire off 5 shots under in a second would make it much easier as alignment wouldn't be an issue(ie - I wouldn't touch it at all to change settings). Just press the remote shutter release button(this is a good use for them - who would have thought... )and presto - I can blend 2 or 3 or 5 as it requires. Then dump it into Photoshop or whatnot to get it ready to print.

Oh - I did have one other suggestion - one that I think you could actually charge money for if you put it in the program(I'd pay money for this):

- Have an option to automate the process. Save a set of settings and that way you could tell it to process every three in a folder at a time or some other method. Possibly by photo number if the camera names them as xxxA, xxxB, etc. I don't know how to do this, but I suspect it wouldn't be so difficult.

Set it up - drop all of your multi-exposure pictures in the input folder, it spits out blended images to the output folder. Come back after getting lunch and all of them are done. Like your own automated mini-lab

GLuijk

Apr 5 2008, 02:40 PM

QUOTE (GLuijk @ Mar 30 2008, 09:39 PM)

Then I should do:

sRGB(gamma=1.0) -> XYZ
XYZ -> sRGB(gamma=2.2) ?

but if I am not missing something, in the end this means:
R' = R^(1/2.2)
G' = G^(1/2.2)
B' = B^(1/2.2)

which does not preserve the ratio between the colours, so tones change, don't they?

I am sorry for pushing up again this thread, but I did some checks to find out how the delinearization of a linear image happens in PS, and I am happy with the findings so I wanted to share.

1. I developed an image in DCRAW (linear output converted to sRGB)
2. I opened it into PS and converted it now to non-linear sRGB (PS should apply a 2.2 gamma)
3. I used a program I wrote some time ago that with Image 1 and Image 2 as input, calculates the RGB curves to go from Image 1 to Image 2. If the correspondence between both images is independent on each channel, the curve calculated will be exact to convert Image 1 into Image 2. Otherwhise it will just be an approximation.

Well, the curve calculated was this (see RED plot):

RED: PS application of gamma 2.2
BLUE: pure 2.2 gamma

Exactly the same for the 3 RGB channels. That means the proper way to apply gamma is the easiest possible! good news. Probably you were already telling me this guys, but It was not clear to me.

I then calculated a pure 2.2 gamma curve to check if the curve that PS applied is a perfect gamma:

R'=R^(1/2.2)
G'=G^(1/2.2)
B'=B^(1/2.2)

R,G,B normalised values [0..1]

And it is was plotted in BLUE colour in the previous graph. It's very close to what PS did, just PS seems to lift deep shadows a bit less than the pure gamma curve. But the approximation is very good so I will use those simple formulas in my program and with the maximum floating point precision, no matter if it's a bit slow.

To allow the user to choose to apply the gamma before the final TIFF file is generated is important to improve a lot the robustness in the shadows and the maximum achievable DR expansion, which now can be greater than 16 f-stops!

BR

cedricb

May 7 2008, 09:44 AM

Hi GLijk,

I'm a Java/C software developer. I'm just wondering if you could send me the main source code? So I could write a tools which can be used on every platform. I've tried to use wine on Linux with no success...

Or if you want I could be at your service to produce a cross platform tools instead of your VB software... I can be your dev monkey!

Please let me know.

Regards,
Ced.

GLuijk

May 7 2008, 08:41 PM

hi cedricb, it seems some C developers have got a lot of interest in writing Zero Noise in a more proper way in a Spanish forum; I have encouraged them to forget about developing the input RAW files but to output a DNG 16-bit RAW file. Any help with the DNG format (we just need the needed routines from the DNG SDK to build a 16-bit DNG file from the partial RGGB data) is VERY WELCOME.

Moreover we plan to write first a GUI for DCRAW; not just another front end for it but a very technical RAW developer (with a philosophy close to Gabor's RAWnalyze) to really exploit DCRAW's capabilities so as some new features.
It will focus on:
- A very precise display of the image
- Total control of pure RAW development tasks not caring at all about those (curves, saturation,...) that are best done in PS
- Before/After comparision splits for any of the settings

A very basic approach of the GUI and functions could be:

If you know about DNG please let me know.

BR

PS: this is not related to the answer, but wanted to show how well DCRAW's highlight recovery performs with bright areas on skin. Left is the result using -H 2 (neutral) option, same result as with ACR/LR recovery routines. Right is the active tone emulation performed with -H 9 in DCRAW, not always works but here was fine (no PP at all in either of the recoveries):

MichaelEzra

May 8 2008, 04:01 PM

GLuijk, I just tested v 0.91 and it worked great! (I had some problems with v0.9 before)

dwdallam

May 9 2008, 06:45 AM

It would be great if we see a PS plugin for this great tool. If you could do something like that, surely you could sell it to a software developer and retire. lol

Nice work.

I'll bet the ACR guru who works for Adobe is already on it as we speak. I mean, why not?

GLuijk

May 9 2008, 09:57 AM

QUOTE (dwdallam @ May 9 2008, 12:45 PM)

It would be great if we see a PS plugin for this great tool.

what would be the advantage of having this program in the form of a PS plugin? people not using PS could not enjoy it, and anyway would offer no advantages since it uses DCRAW for the RAW development.

Wayne Fox

May 9 2008, 02:40 PM

QUOTE (GLuijk @ May 9 2008, 07:57 AM)

what would be the advantage of having this program in the form of a PS plugin? people not using PS could not enjoy it, and anyway would offer no advantages since it uses DCRAW for the RAW development.

I agree that doing it as a plugin only may not be ideal., but, I wish all RAW developers would offer a plugin option so I could work inside of bridge and photoshop. I use ACR most of the time just because of the simplicity of the workflow. If I could load C1 or some other RAW processing software as a plugin (or file format module) to operate like camera raw I would most likely try them, for now the workflow is just too easy with ACR that I default to that most of the time.

MichaelEzra

May 9 2008, 07:48 PM

I think the idea here is that Zero Noise could use some sort of plug-in architecture for use of different RAW converters, based on user's preference.

Another approach would be to have a raw output from Zero Noise, as was discussed before, and then any desired raw converter could be used:)

Andy M

May 19 2008, 02:37 PM

Is the software available for Mac?

dwdallam

May 20 2008, 02:22 AM

QUOTE (GLuijk @ May 9 2008, 02:57 PM)

what would be the advantage of having this program in the form of a PS plugin? people not using PS could not enjoy it, and anyway would offer no advantages since it uses DCRAW for the RAW development.

Why not both DCRAW and PS as a plugin?

Plekto

May 20 2008, 12:48 PM

Because Adobe does its own funky ting when it converts/imports data and then does more "tweaking" with it when you save it back.

It's much easier to just keep it as it is - a stand alone app that does one thing better than any of the multi-tasking ones out there.

dwdallam

May 21 2008, 01:31 AM

QUOTE (Plekto @ May 20 2008, 05:48 PM)

Because Adobe does its own funky ting when it converts/imports data and then does more "tweaking" with it when you save it back.

It's much easier to just keep it as it is - a stand alone app that does one thing better than any of the multi-tasking ones out there.

Ah ok. I was thinking something else. That's why someone asked if it could be coded to DNG output? If so, yeah that would be fine.

Plekto

May 21 2008, 07:21 PM

http://luminous-landscape.com/forum/index....showtopic=25484

Specifically this. Yes, adding more options for output is always a good thing.(I'm not a fan of "Photoslop" as you might gather.

dwdallam

May 22 2008, 02:15 AM

QUOTE (Plekto @ May 22 2008, 12:21 AM)

http://luminous-landscape.com/forum/index....showtopic=25484

Specifically this. Yes, adding more options for output is always a good thing.(I'm not a fan of "Photoslop" as you might gather.

I'm not a fan of any legalized monopoly, including Microsoft, Adobe, or Oil Companies, and Power distribution companies. I really do wish there were more options to both increase quality and to drive down price.

hassiman

May 26 2008, 10:04 PM

Hi,

Has anyone here tried the really graet ENFUSE GUI front end BRACKETEER which is great at extending dynamic range and reducting noise by blending bracketed exposures.

If so how does it compare with ZERO NOISE and where can I get ZERO NOISE for MAC?

GLuijk

May 27 2008, 04:25 AM

QUOTE (hassiman @ May 27 2008, 04:04 AM)

where can I get ZERO NOISE for MAC?

Nowhere, but if you would like to write Zero Noise for Mac, I will share with you all the algorithms.

Zero Noise is very demanding with correct image alignment, but regarding noise is very optimised, I would dare to say that noise cannot be reduced more than Zero Noise does. This is not because Zero Noise is wonderfully coded, just because of the way it works, selecting individually the less noisy pixels.

cedricb

Jun 3 2008, 01:57 AM

GLuijk,

Can you post the link of the Spanish forum so I can have a look at the ZN rewrite.

Regards,
Ced.

GLuijk

Jun 3 2008, 04:51 AM

QUOTE (cedricb @ Jun 3 2008, 07:57 AM)

Can you post the link of the Spanish forum so I can have a look at the ZN rewrite.

There is no ZN rewrite yet, we are designing first our own RAW developer: Perfect RAW.

cedricb

Jun 4 2008, 06:45 AM

I would like to use your ZN technique on Linux and for the time been there is no image editor which handles 16bits images (GIMP will do that in the future).

I don't really need a GUI to merge a set of RAW (I'll do with the default camera WB), so could you share your code for the exposure calculation and the blending?
I'm just wondering I can do the same thing (for the time been) with ImageMagick (http://www.imagemagick.org/script/index.php) and dcraw... Linux/Mac/Windows users should be able to use it...

With ImageMagick, you can blend two images with a percentage ratio (http://www.imagemagick.org/Usage/compose/#blend)

GLuijk

Jun 7 2008, 06:16 PM

QUOTE (cedricb @ Jun 4 2008, 12:45 PM)

could you share your code for the exposure calculation and the blending?

sure, here you are:

exposure calculation:

CODE

Function CalcularExpRelativas() As Integer
Const rUmbralMin As Double = 65536 / (2 ^ 6) ' Ponemos el mínimo 6 diafragmas más abajo para asegurar 2 diafragmas completos de intersección
' entre tomas con sobreexposiciones de hasta +4EV
Const rUmbralMax As Double = 65536 * 0.9 ' Nos quitamos de encima la zona de comportamiento no lineal, 20% superior del rango dinámico

Dim i As Integer, j As Integer, N As Integer
Dim lX As Long, lY As Long
Dim Color0 As GFL_COLOR, Color1 As GFL_COLOR
Dim rSum0 As Double, rSum1 As Double

On Error GoTo CalcularExpRelativas_Error

CalcularExpRelativas = 0

N = UBound(GflBitmap)
SetStatus "Calculating relative exposure..."

' Cálculo de exposiciones
ReDim rFactor(N)
i = 1
rFactor(i) = 1# ' La primera imagen es la toma menos expuesta, la referencia final de exposición
SetStatus EliminaRuta(sFileTIFF(iPos(i))) & ": " & _
Round(1 / rFactor(i) * 100) / 100 & _
" (+" & Round(Log(1 / rFactor(i)) / Log(2) * 100) / 100 & " EV)", ADD
For i = 2 To N
rSum0 = 0#
rSum1 = 0#
For lX = 0 To lWidth - 1
For lY = 0 To lHeight - 1
gflGetColorAt GflBitmap(i - 1), lX, lY, Color0
gflGetColorAt GflBitmap(i), lX, lY, Color1

If Gfl2Long(Color0.Red) >= rUmbralMin And Gfl2Long(Color0.Red) <= rUmbralMax And _
Gfl2Long(Color1.Red) >= rUmbralMin And Gfl2Long(Color1.Red) <= rUmbralMax Then
rSum0 = rSum0 + Gfl2Long(Color0.Red)
rSum1 = rSum1 + Gfl2Long(Color1.Red)
End If
If Gfl2Long(Color0.Green) >= rUmbralMin And Gfl2Long(Color0.Green) <= rUmbralMax And _
Gfl2Long(Color1.Green) >= rUmbralMin And Gfl2Long(Color1.Green) <= rUmbralMax Then
rSum0 = rSum0 + Gfl2Long(Color0.Green)
rSum1 = rSum1 + Gfl2Long(Color1.Green)
End If
If Gfl2Long(Color0.Blue) >= rUmbralMin And Gfl2Long(Color0.Blue) <= rUmbralMax And _
Gfl2Long(Color1.Blue) >= rUmbralMin And Gfl2Long(Color1.Blue) <= rUmbralMax Then
rSum0 = rSum0 + Gfl2Long(Color0.Blue)
rSum1 = rSum1 + Gfl2Long(Color1.Blue)
End If

Next lY
Next lX

If rSum1 = 0# Then
SetStatus "Too wide exposure gap", ADD
SetStatus "DONE", ADD
CalcularExpRelativas = -1
AvisoError ("Too wide exposure gap between " & _
EliminaRuta(sFileTIFF(iPos(i - 1))) & " and " & EliminaRuta(sFileTIFF(iPos(i))))
Exit Function
ElseIf rSum0 > rSum1 Then
SetStatus "Too narrow exposure gap", ADD
SetStatus "DONE", ADD
CalcularExpRelativas = -1
AvisoError ("Too narrow exposure gap between " & _
EliminaRuta(sFileTIFF(iPos(i - 1))) & " and " & EliminaRuta(sFileTIFF(iPos(i))))
Exit Function
Else
rFactor(i) = rSum0 / rSum1 * rFactor(i - 1) ' Acumulamos factores y lo mostramos en pantalla
SetStatus EliminaRuta(sFileTIFF(iPos(i))) & ": " & _
Round(1 / rFactor(i) * 100) / 100 & _
" (+" & Round(Log(1 / rFactor(i)) / Log(2) * 100) / 100 & " EV)", ADD
End If
Next i

SetStatus "DONE", ADD

CalcularExpRelativas_Resume:
DoEvents
Exit Function

CalcularExpRelativas_Error:
MostrarError ("CalcularExpRelativas")
CalcularExpRelativas = -1
Resume CalcularExpRelativas_Resume

End Function

blending:

CODE

Sub FusionarImagenes(sRuta As String)
Const MAXINT65535 As Long = 65535
Dim sResult As String
Dim i As Integer, N As Integer
Dim lX As Long, lY As Long
Dim Color As GFL_COLOR
Dim lTH As Long
Dim rIGamma As Single

On Error GoTo FusionarImagenes_Error

N = UBound(GflBitmap)
SetStatus vbCrLf & "Blending into a noise free image...", ADD

' REPLICAMOS CÓDIGO SEGÚN GAMMA SEA 1.0 Y OTRA PARA GANAR VELOCIDAD
rIGamma = 1 / (frmMain.hscGamma.Value / 10) ' 1/Gamma

' Tomamos el color del píxel de la toma más expuesta que cumpla las condiciones
lTH = Round(MAXINT65535 * frmMain.hscTH / 100) ' Umbral de fusión

If rIGamma = 1# Then
For lX = 0 To lWidth - 1
For lY = 0 To lHeight - 1
i = N
gflGetColorAt GflBitmap(i), lX, lY, Color
' Bucle para elegir la imagen que prevalecerá
Do While i > 1 And _
(Gfl2Long(Color.Red) > lTH Or Gfl2Long(Color.Green) > lTH Or Gfl2Long(Color.Blue) > lTH)
i = i - 1
gflGetColorAt GflBitmap(i), lX, lY, Color
Loop
' Solo corregimos valor si no hemos recurrido a la toma menos expuesta
If i > 1 Then
Color.Red = Long2Gfl(Round(Gfl2Long(Color.Red) * rFactor(i)))
Color.Green = Long2Gfl(Round(Gfl2Long(Color.Green) * rFactor(i)))
Color.Blue = Long2Gfl(Round(Gfl2Long(Color.Blue) * rFactor(i)))
gflSetColorAt GflBitmap(1), lX, lY, Color
End If
Next lY
Next lX
Else
For lX = 0 To lWidth - 1
For lY = 0 To lHeight - 1
i = N
gflGetColorAt GflBitmap(i), lX, lY, Color
Do While i > 1 And _
(Gfl2Long(Color.Red) > lTH Or Gfl2Long(Color.Green) > lTH Or Gfl2Long(Color.Blue) > lTH)
i = i - 1
gflGetColorAt GflBitmap(i), lX, lY, Color
Loop
'If i > 1 Then ' Solo corregimos exposición si i > 1
Color.Red = Long2Gfl(Round(MAXINT65535 * (Gfl2Long(Color.Red) * rFactor(i) / MAXINT65535) ^ rIGamma))
Color.Green = Long2Gfl(Round(MAXINT65535 * (Gfl2Long(Color.Green) * rFactor(i) / MAXINT65535) ^ rIGamma))
Color.Blue = Long2Gfl(Round(MAXINT65535 * (Gfl2Long(Color.Blue) * rFactor(i) / MAXINT65535) ^ rIGamma))
gflSetColorAt GflBitmap(1), lX, lY, Color
'End If
Next lY
Next lX
End If

' Guardamos imagen final generada
sResult = "ZN_" & Format(Time, "hhmmss") & "_" & _
Sust(frmMain.cmbProfile, " ", "") & "_G" & Sust(1 / rIGamma, ",", ".") & ".tif"
SetStatus "Saving result as " & sResult & "...", ADD
GuardarGflBitmap GflBitmap(1), DimeRuta(sRuta) & sResult

' Liberamos las imágenes cargadas
For i = 1 To N
CerrarGflBitmap GflBitmap(i)
Next i

SetStatus "DONE", ADD
Beep

FusionarImagenes_Resume:
DoEvents
Exit Sub

FusionarImagenes_Error:
MostrarError ("FusionarImagenes")
Resume FusionarImagenes_Resume

End Sub

button

Jul 10 2008, 08:01 PM

Hey Guillermo,

I've followed this thread over the past year, and I must say BRAVO! I have two questions for you:

1) Does ZN v0.91 have your previously mentioned corrections for the Canon 40D?

2) When I open the noise corrected file (the "ZN" file generated by Zero Noise), it seems to have significantly lower resolution and detail than both the original RAW files and the TIFF files that your program creates prior to blending. What am I doing wrong?

Thanks, and keep up the superb work!

John

Edit: Ignore question #2. There is no problem with your program's resolution! Somehow, I had my resolution settings different in camera RAW (ACR) for the ZN files and the RAW images, even when opened at the same time. Sorry for the confusion. I would, however, very much appreciate an answer for question #1.

GLuijk

Jul 11 2008, 11:06 AM

QUOTE (button @ Jul 11 2008, 02:01 AM)

1) Does ZN v0.91 have your previously mentioned corrections for the Canon 40D?

Not exactly corrected (since it's a fault of DCRAW's source code), but you can now in v0.91 easily solve the problem just by entering the right saturation value for your camera in the 'Saturation' text box.

I have detected 2 cameras so far that need to be corrected:
- Canon 30D: 3398
- Canon 40D: 13823

I am quitting my job in August and taking some kind of sabbatic year. I will devote a lot of time to getting used to code in C/C# and rewrite Zero Noise in this languages with another two guys introducing some needed improvements as the anti-ghosting and progressive blending. The idea is to produce a 16-bit DNG output file out of Zero Noise instead of a TIFF file so I again ask for help: if any coder is able to generate a DNG file from scratch using the Adobe DNG SDK just contact me.

We are already developing a new RAW developer based on DCRAW but with a powerful graphical interface and other new features for high precision RAW development (just development, no processing). If you want to track that project: Perfect RAW.

BR

docmaas

Jul 11 2008, 11:17 AM

Hi guillermo,

If possible pleasse continue with the tiff output as well. Sigma cameras do not do dng.

thanks,

Mike

QUOTE (GLuijk @ Jul 11 2008, 09:06 AM)

Not exactly corrected (since it's a fault of DCRAW's source code), but you can now in v0.91 easily solve the problem just by entering the right saturation value for your camera in the 'Saturation' text box.

I have detected 2 cameras so far that need to be corrected:
- Canon 30D: 3398
- Canon 40D: 13823

I am quitting my job in August and taking some kind of sabbatic year. I will devote a lot of time to getting used to code in C/C# and rewrite Zero Noise in this languages with another two guys introducing some needed improvements as the anti-ghosting and progressive blending. The idea is to produce a 16-bit DNG output file out of Zero Noise instead of a TIFF file so I again ask for help: if any coder is able to generate a DNG file from scratch using the Adobe DNG SDK just contact me.

We are already developing a new RAW developer based on DCRAW but with a powerful graphical interface and other new features for high precision RAW development (just development, no processing). If you want to track that project: Perfect RAW.

BR

GLuijk

Jul 11 2008, 12:14 PM

QUOTE (docmaas @ Jul 11 2008, 05:17 PM)

If possible pleasse continue with the tiff output as well. Sigma cameras do not do dng.

Hi Mike, I didn't explain myself well: the RAW files to be fed into Zero Noise will be any vendor supported by DCRAW, just like now.
Only the output would be a DNG 16-bit RAW file free of noise with the optimal blending of the information contained in the original RAW files, and ready to be developed with your favourite RAW developer.

I wonder why no company has done this before; perhaps market researchs indicate that what people demand are programs where you just click a button to obtain a finished "HDR" image with no extra effort.

BR

button

Jul 11 2008, 01:09 PM

QUOTE (GLuijk @ Jul 11 2008, 11:06 AM)

I have detected 2 cameras so far that need to be corrected:
- Canon 30D: 3398
- Canon 40D: 13823

Thanks very much for that. Please continue the outstanding work!

John

feppe

Jul 11 2008, 02:07 PM

Guillermo, how would you recommend combining Zero Noise Technique software with making panoramas (I'm using Autopano Pro)?

Example: I have a panorama with three shots. I shoot each of these 3 shots twice, bracketing 4 stops apart to use for Zero Noise, ending up with 6 shots.

I'd imagine it would be better to make the panoramas first, then do the blending in Zero Noise. My understanding is that ZN only reads RAW files, and since Autopano only produces TIFFs and PSDs, I'd have to find a way to convert those to DNGs. Or is there an easier way to approach this?

Or would you recommend doing the blending beforehand, and stitching afterwards? The potential problem with this is big panoramas where exposures are wildly different at the different edges of the final image.

GLuijk

Jul 12 2008, 08:06 AM

QUOTE (feppe @ Jul 11 2008, 08:07 PM)

I'd imagine it would be better to make the panoramas first, then do the blending in Zero Noise. My understanding is that ZN only reads RAW files, and since Autopano only produces TIFFs and PSDs, I'd have to find a way to convert those to DNGs. Or is there an easier way to approach this?

Or would you recommend doing the blending beforehand, and stitching afterwards? The potential problem with this is big panoramas where exposures are wildly different at the different edges of the final image.

Forget about converting TIFF to DNG, it's conceptually wrong since DNG expected by ZN is a RAW undemosaiced file.

I think you can blend each of the three pairs in ZN (same WB is a must). If you shot the least exposed RAWs in each pair with the same exposure (aperture/shutter/ISO), they should be ready for Autopano straight out of ZN.
Otherwhise you can open the TIFF files and match their exposures with the 'Exposure' option of Photoshop or easier with a simple curve like:

Another option is to forget about ZN and blend the images yourself following this tutorial, which performs conceptually the same operations as ZN but into Photoshop: Yet another method to reduce noise with two exposures. This process can be applied after performing the 2 pano stitchings of 3 images each, as long as those stitchings match perfectly pixel to pixel.

BR

Plekto

Jul 14 2008, 04:52 PM

QUOTE (GLuijk @ Jul 11 2008, 10:14 AM)

I wonder why no company has done this before; perhaps market researchs indicate that what people demand are programs where you just click a button to obtain a finished "HDR" image with no extra effort.

Because since it is pure mathematical conversion, it essentially isn't able to be patented or made into a piece of software for them to sell at vastly inflated prices to professionals.(it's all about the money)

cedricb

Aug 15 2008, 04:42 AM

GLuijk,

Sorry to be a pain but... I've just found some free time to carry on my Linux experiment...

What's the mathematical formula applied to the RGB matrix for the negative exposure compensation?

Regards,
Ced.