very cool!

so how is this better than noise reduction software, like noise ninja? i am super happy with it after inspecting it with a critical eye.

an interesting note on my P25 back, i noticed if I OE a stop and pull it back in raw processing it get about 2 stops less noise. ie an exposure at iso 200 pulled back in brightness in raw has much less noise than if it was shot and processed normally at iso 50 the backs native iso.

GLuijk,

Finally I've be able to produce a ZN effect with ImageMagick. I've compared "visually" with your ZN software and it "looks" the same.

Here is an example with the "lounge" images which uses the camera WB and a compensation of -3.93EV.



...these should work for Linux/Mac and Windows...

The merge.tiff is a 16bits one so no gamma/contrast/brightness applied.

In term of tone mapping, have you got some magic curves which can be applied every where? :-)

I've replicated a similar Sigmoidal curve for the contrast but I don't know which settings you have used in your tutorial... contrast + mid-point
For the brightness, can you give me the settings for the curve?

Thank you again for your work, Guillermo.

I for one am very appreciative of your interest and dedication to this. I imagine that we will look back one day and recognize the significance of your contribution. I predict that every serious DSLR will soon perform your algorithm in-camera.

Best regards,
Bruce

Otra cosita, Guillermo... Aunque mi primer idioma es ingles, tambien soy fluente en el espanol. Ando casi siempre atrasado en mi propio trabajo como abogado de patentes. No obstante, estoy dispuesto de ayudarle con traducciones de espanol al ingles cuando lo necesite, ya con el acuerdo de que el trabajo probablemente no sea instantaneo.

Con estimo,
Bruce

He definitely should apply for a patent on the idea so that he's not going to get sued at some later date by some over-zealous manufacturer(or lose out on possible royalties)

GLuijk,

I've been able to reproduce your exposure calculation in C with the ImageMagick API.

I'm just wondering if you can explain the colors min and max values:


Another thing, is it possible to calculate the best blending ratio? for the time been I'm using 90%.


Regards,
Ced

Hi Ced, nice to see you are achieving the same things on Linux.

I have gathered my answers to your questions:

1. Exposure correction down, in linear state, is as simple as multiplying each RGB level by a <1 factor. For instance let L be a 16-bit level that has to be corrected 1 f-stop down: OUT = L * 0.5

2. The contrast and bright curves I apply are always made by hand. The proper curves deeply depend on the image's histogram in front of you, and the desired result. I don't think a 100% automatic process is possible here. However some algorithm to get a curve with which to start should be possible (RAW developers calculate this curve).

3. The min = 65536 / pow(2, 6); max = 65536 * 0.9; were just my criteria. I thought values higher than 90% of sat could start to be non-linear in certain sensors. In the low end pow(2,6) ensures the program will not consider values falling in the 7th or lower f-stop (they are surely very noisy).

4. The best blending ratio of course is 100%, or nearly, but depending on how linear is your sensor to allow a lower value is recommended. 99% means any RGB value less or equal to 99% of saturation in a given image will be considered right.





That would be nice, I planned to translate the ZN tutorial this August but found no time. Would you like to translate some part of it? wait first cause a new version of the tutorial (in SP) is coming soon since I added new features.

These days I could relax and add some features:

• Concept of "blending map": a GIF map file represents now which images are the pixels taken from. This map can be manually edited to perform a personalized blending.
• Possibility to do progressive blending with a radius parameter
• Anti-ghosting feature with radius parameter to minimise artifacts in presence of moving elements (leaves, water) in the scene and also when alignment is not perfect
• The process has been divided into 4 stages: Development, Relative exposure calculation, Blending map generation and Blending. Each stage can be re-run with new parameters without the need to recalculate any previous stage. This allows for instance user intervention to align images after development, or blending map fine tuning in PS after blending map generation
• Each stage gives an important amout of statistical info about the process such as absolute and relative exposures of each image, % contribution of each image to the result, % genuine pixels (pixels coming from one single image)
• New algorithm for relative exposure calculation based on median rather than on average (as until now), that will be more robust against moving parts of the scene
• For those familiar with DCRAW, any DCRAW command can now be included in the workflow (at your own risk)

This is the new GUI:




Blending map (in black those pixels coming from the most exposed shot, gray medium exposure shot and white least exposed shot):




200% crop of previous blending map (upper lamp): up without anti-ghosting nor progressive exposure (like ZN worked until now), down with 4px anti-ghosting radius plus 3px progressive blending radius.




200% crop (ground lamp) on how ZN seeks most exposed areas to obtain them from less exposed shots. With real tone pixels coming from the most exposed shot, in green tones blending map showing pixels coming from the medium and least exposed shots, with a progressive area in the borders where information from more than one shot gets combined:




I will try to upload the update when it is 100% ready before my vacation (I will visit NY/Boston next month).

Salu2

Guillermo: That would be nice, I planned to translate the ZN tutorial this August but found no time. Would you like to translate some part of it? wait first cause a new version of the tutorial (in SP) is coming soon since I added new features.

Bruce: Ok; please just email me the version that you want translated when you are ready, to: bhouston1@satx.rr.com.

Best regards,
Bruce

GLuijk,

Thank you for your reply...

With the mask technique (negate of the over-exposed image to the alpha channel of the negative corrected over-exposed image) which is described in the PS tutorial, I don't get the same amount of perfect gradient in the spot light area in comparison of your ZN software.
My experiment produces the mask and blend the original image with a threshold ratio. So I don't thing it's exactly the same result than your software, or maybe I've done something wrong with the mask generation.
Can I upload the 16bits TIFF files (around 50M for each file) somewhere so you could have a look and let me know what's wrong?

I've been using your "lounge" raw images for my test, so for your sensor which is the best blending ratio?

Could you shared your new algo for the "relative exposure calculation", so I can update my code.

Are you planing to release the code source when you hit version 1.0?


Regards,
Ced.

Surely they will never be 100% the same since there are always differences in implementation and rounding values. The important thing is if the solution works and provides a good result.

I have introduced progressive blending since just a small radius: 2 or even 1, will produce transition areas of 2+1+2=5 or 1+1+1=3 pixels wide with a smooth gradation between the images, usually enough to produce a soft effect in the border areas but still keeping most of the pixels genuine, i.e. coming from just one image to be optimum in noise reduction and avoid any loss of sharpness. In my example 98,6% pixels were kept genuine.



The 350D saturates at 4095 what makes me think (this is just an hypothesis) that its ADC actually clips the analogue output from the ISO amplifier making 350D's RAW files very linear up to saturation (at the cost of losing some highlight information captured by the sensor of course) because they have actually already been clipped to some threshold. That's why we can be very demanding with those sample images where very high thresholds can be set for blending.

I am not sure if other cameras where saturation does not reach the maximum of the RAW file range (for instance the 5D and 400D sat points are around 3500) are so linear close to saturation so they would need a lower threshold. The optimum threshold value cannot be calculated since it's hardware dependant; I have a feeling it could be kept very high for most situations but everyone should check how his camera works. I only have my modest 350D to do tests and it shows a very linear response in the whole range up to saturation.



That new alg is still just in my mind, but it consists in calculating an accumulative array of relative exposures. For each pixel pair, the relative exposure is calculated, weighted by the level of exposure of those 2 pixels, and then fed into the array with the index according to the relative exposure calculated. In the end we just calculate the median of the statistical distribution obtained. I think it will work fine.

I will keep the new code secret (there is not too much to hide anyway) since the plan in the end is to translate the entire code to a C/C# application with the possibility of a RAW DNG output that could be then developed on the user's favourite software. The two fellows that code in C are still on vacation, I am just starting with VS C#.

I insist again that if someone is reading this that can use the Adobe DNG SDK to produce a DNG file from scratch just contact me.


BR

Hi Guillermo!

I am looking forward to use your promising software! After studying the english article, I have a question:

The white balance should be the same in both shots. Would it be sufficient to adjust this post capture in the raw state? The white balance is the one exposure parameter that I prefer the camera to do automatically, since I can not see how I can do it better.

Despite my Zero Spanish, I also tried to extract some information from the tutorial, based on the pictures. Concerning fig. 4, 5 and 6: Does Zero Noise require to define the white balance based on an area in the actual picture?

Kind regards - Hening.

Hi Hening, the white balance in Zero Noise can be set:
- Camera: will take the camera's WB embedded in the RAW file. Not very recommended if you used auto, but you can try it and see what happens.
- Coeffs: linear multipliers for the RGB channels (not very intuitive)
- Preset: presets
- Patch: choose a rectangular or circle patch and WB will be calculated according to it. IF YOU SET THIS PATCH COVERING THE ENTIRE IMAGE, YOU WILL GET AN AUTOMATIC WB WITHOUT THE PROBLEMS THAT CAMERA'S AUTO WB CAN HAVE, so this could be a good option for you.

BR

Hi Guillermo,

thank you for your reply. - I can not quite see how this solves the problem. Make the patch cover the whole image - which one? The zero or the +4? The problem (with the camera AWB) as I see it is that light may shift between the 2 shots - So I thought one could adjust the one of them to the other post capture in the raw state before merging?

Kind regards - Hening.

Any of the shots is OK, but the most exposed is recommended to set the patch since it will have less noise and WB calculation will be more accurate. Don't worry about its blown areas since they do not participate in the WB calculation. Once the multipliers have been calculated they will be applied to the two shots so WB will be fine.

Light in the scene should not shift between your shots, why? you have to shoot them one right after the other, not wait for an hour

BR

PS: BTW we already found someone who can build a DNG RAW file from RAW data. A version of Zero Noise with a 16-bit DNG output free of noise is nearing. I.e. the user puts several RAW files and the program will mix them into a noise free RAW file that everyone will develop and/or tone map using his favourite software.

Hi Guillermo!

Thanks for your answer!

>Light in the scene should not shift between your shots, why? you have to shoot them one right after the other, not wait for an hour

I agree: light should not shift, but you know, up here in the North (Oslo), light is so unbehaved, it DOES shift, and it does not take it an hour to do so, it can do it i a split second! A typical shooting situation for me is that I stand behind the tripod, one hand on the cable release, waiting for the sun to peep through the clouds!

If, on the other hand, I am lucky enough to catch the same light for 2 consecutive exposures, then what is wrong with auto white balance? I thought the problem was that the automatism would apply 2 different white balances to shots due to light shift? But I have no technical understanding of how the automatism works, and I am open to learn.

(So far, I am satisfied with the result: I remember a day when I was shooting in the same place from about noon into the afternoon. Viewed one at a time, the images looked all natural. However, viewed side by side, those taken near noon were clearly more blue than those taken later in the afternoon. So the automatism does - fortunately - not wipe out the natural color shift in daylight entirely.)

>PS: BTW we already found someone who can build a DNG RAW file from RAW data. A version of Zero Noise with a 16-bit DNG output free of noise is nearing. I.e. the user puts several RAW files and the program will mix them into a noise free RAW file that everyone will develop and/or tone map using his favourite software.

That is GREAT news, and CONGRATULATIONS!

Hening.

Hi Hening, automatic white balance can never balance equally two different images if there are spatial differences in hue between them, i.e. if not all 100% of the surface of the image changes equally in white balance from one situation to another which is the common case. That is why any automatic white balance algorithm can be considered 'best effort' for these kind of situations.

I don't recommend to use camera's automatic white balance in Zero Noise, but you can do it: just select automatic WB in your camera and set Camera's WB in ZN, and see if the result is fine.

You can alternatively try DCRAW's automatic white balance by setting -a in the DCRAW command line dialog box, and each RAW file will be developed with DCRAW's auto WB algorithm. I did it over my example scene and you can see some slight differences in white balance (when they all should be the same):



When doing so it's however almost mandatory to set some progressive blending to avoid visible colour steps in the transitions:



BR

Guilermo, this is really great news!!!

Guillermo, thanks for your reply and instruction. Hening.