I have an image consisting of 15 slices. The sharp foreground slices are neglected in the rendering. The map shows the plants in question very nicely, but the final image doesn't. Why? Can this image be rescued in any way? (Other than manual retouching, which is practically impossible.) Is there some trick or workaround that I could try?Mac 10.6.6, Helicon Focus 4.2.7 X64. Method B,1,3.Kind regards - Hening.

I would recommend to experiment with larger value of radius, up to 20. We are now reworking our algorithms and I would appreciate if you upload your images on our server (as described at http://www.heliconsoft.com/ftp.html). We would use it for tests.

Hi Stas, thank you for your fast reply. I will be happy to upload. However, the image consists of 16 focus slices, 125 MB each! Would they be useful for you if I lowered the color depth from 16 to 8 bit? And would you need all slices?

Increasing the radius will decrease the sharpness, so I think I will wait for your new algorithms

Thanks, 8 bit JPEGs would be sufficient for out tests. Finetunig algorithms is a tricky thing. It is like finding parameters for noise reduction that remove enough noise and leave enough details. That is why we need difficult cases like yours for testing.

At this moment, I am uploading a .zip of my files in 8 bit. I compressed the whole folder, hope this works.

I think one problem with the image is that the parts in question are dark. I have noticed that like the rest of us, Helicon does not see so good in the dark, and often fails to select the best slice in dark areas.

This leads me to a feature request I hope you will consider. Since retouching can not altogether be avoided, 2 things would help.

1- An option to lay out a grid over the image, so one could more easily keep track of areas one has worked on. Ignorant about programming, I imagine this would be easy for you to implement. Say a grid where the user could configure the grid size, and a..z and 1..x on the margins.

2- Probably more demanding if not impossible: an option to save the file in a state that would allow resuming work later, after the app has been closed and the system restarted. Often, considerable amount of work is lost and has to be re-done when I discover more failures in the final image after the fact. Very annoying!

We checked your images. This is difficult case because it is hard to handle sharp transitions from foreground to background. The program tries to smooth such transitions to minimized artifacts due to noise. And one more problem - the background behind forground branches is well focused. This means that the same pixel is sharp in two images and the program selects the sharpest. In your case it is background. I would say in such a case you will need retouching brush to get perfect result. Good news is that we are now improving retouching and it will be much more comfortable to use due to live preview feature.

> And one more problem - the background behind forground branches is well focused. This means that the same pixel is sharp in two images and the program selects the sharpest. In your case it is background.

This description of the problem gave me an idea I want to share even if it did not work.

1. I stacked the foreground slices separately, then stacked the result with all the other slices.2. I stacked foreground and background separately, then stacked the 2 resulting stacks.No improvement, on the contrary. Why not? I mean now the source images contain a sharp foreground, which Helicon could choose.

Asked in a different way: Even if my idea did not work right out of the box, does it contain something that could be used if you used it when working on Helicon?

This is far from the only image with this problem. On the contrary, it contains something that I almost systematically try to achieve: Try to make my images "rich" by finding views, where various "layers" are projected on top of each other.

Just merging parts of the stack separately does not give the program any additional information which pixel to use in the resulting image. We thought in this direction but had not found any advantages so far.

For the cases when the same area is sharp in several layers, no simple automatic algorithms exist. From out experience they produce too many artifacts. I would appreciate more samples so we can use them for tests.

I am uploading another image at this time. To keep upload size down, I included every second slice only, and set jpeg quality to 55%. Does this do? The zipped folder is called "2010.09.29 M2 f Helicon - jpegs. BTW, could you move my uploads into a folder called Hening, so I can keep track of them? Or maybe I can do this myself? I am just not familiar with FTP.

> Just merging parts of the stack separately does not give the program any additional information which pixel to use in the resulting image. [...] For the cases when the same area is sharp in several layers, no simple automatic algorithms exist. From out experience they produce too many artifacts.

You have probably thought and tried this long ago, and I am probably naïve, but what if HF in these cases just picked the slice which is nearest? I mean HF makes a depth map anyway? In real life, you can never look *through* the nearest objects, so the result would always look natural. - I understand that this leaves the problem of sharp transitions, though.

We experimented with the idea to make "nearest" pixel opaque. Alas, this produce more artifacts than useful info. Ideally the program should take the nearest image, make the sharp areas opaque and other areas transparent. You made selections for sure and you can imagine how difficult is to create correct selection based on color. Selection based on sharpness is even more complicated and unpredictable. Many objects have sharp contour (like leaves) but completely smooth internal surface. We experiment with different techniques but this is not an easy task. Thanks for the images, we will use them for tests.