Focus Breathing

Announcement of new releases, bugs, support, suggestions
Post Reply
bigmikek
Posts: 1
Joined: 25.02.2019 17:16

Focus Breathing

Post by bigmikek »

I have a Sigma 50mm 1.4 art lens that I recently discovered has noticeable focus breathing. Helicon focus seems to do a pretty good job of handling this but i was wondering how much image degradation i might expect from such a lens.
User avatar
Stas Yatsenko
Posts: 3850
Joined: 06.05.2009 14:05
Contact:

Re: Focus Breathing

Post by Stas Yatsenko »

Focus breathing is not a problem, Helicon Focus is designed to handle it. You shouldn't notice any problem unless breathing is severe, in which case expanding the autoadjustment limits (Helicon Focus preferences -> Autoadjustments) may help. But you probably won't need to change anything to work with this lens, just go with the defaults.
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Focus Breathing

Post by umbel »

Hi Stas, I've hit some cases where focus breathing can be a problem. Since Helicon chooses the frame order it thinks will work best there's an association between the focus breathing profile exhibited by a stack, the frame ordering, and therefore the scales assigned to specific frames in a stack. Since each project has its own alignment it's not guaranteed that stacking the same set of frames using different methods produces an identical alignment. Most of the time projects get the same alignment from identical sets of input frames but when differences do occur it prevents using the output of one project to retouch another project.

There seem to be three failure mechanisms.
  • The alignments match except for a scale factor. Since Helicon doesn't seem to include cross-project alignment transform as part of its retouching I think what happens here is Helicon sees the alignments as different and chooses not to make the other project output selectable for retouching. From what I can tell, the cause is the two projects end up with opposite ends of the stack defined as being scale 1.000, resulting one output where frames got resized to be smaller and one where frames got resized to be bigger. If autocropping's turned on this is hard to see but it shows up if one checks the pixel sizes of the outputs. It's easier to spot if autocropping's turned off. The main workaround I've found is to manually monitor the order selected and then ensure the frames are in the same order when starting the second rendering of the frames but I"m not sure this is 100% reliable.
  • The alignments actually do match but Helicon somehow loses track of this and doesn't enable output selection in retouching. Workaround is to quit Helicon and reopen the projects.
  • The alignments are actually different. With some stacks method B and C start off the same but compute different scale factors by the time they've gotten to the last frame. Not linking the two outputs for retouching is formally correct in this case but it's not great since it prevents retouching in areas where the alignment matches just because the alignments differ somewhere else. From what I can tell, Helicon always recomputes an alignment for a new stack so I'm not seeing there's a workaround for this other than redoing the stacks in Zerene.
None of these are a big deal for me but the pattern of issues suggests this might be a good area to look at for minor stability fixes to better support autofocus bracketing. Geometrically, I think these issues could also occur with stacks from linear motion rails but likely at lower probability.
User avatar
Catherine
Posts: 597
Joined: 29.04.2019 22:38

Re: Focus Breathing

Post by Catherine »

Hi, thanks for the detailed explanation / description, sounds like you may be onto something. Let me reply to each of the bullet points separately.

1. a) After processing a stack, you can see in which order it was processed quite literally: by inspecting the order of the images top to bottom in the list of source images. Pixel size, on the other hand, is not a reliable indication.
b) Unless you have altered the processing order yourself (via right-clicking an image in the sources list and selecting "Sort ascending" / "Sort descending"), the same set of source images should always be processed in the same order if the automatic sorting is selected, and in the same specified order if it's not automatic. If you have observed this not being the case, we'll be very interested in getting the source images that break the expected behavior. However, if you're not comparing the exact same stack to itself but two different stacks, even slightly, then it may not be a bug (and probably isn't).

2. Again, if this is with the exact same stack and parameters, it's a bug and we would very much like to study it (we'll need your stack for that). If they're not the same, there is probably an objective reason why the results are incompatible (for example, different alignment, different cropping).

3. We need to think about this, can you provide an example stack?
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Focus Breathing

Post by umbel »

Hi, 1, 2, and 3 are all for the same source images with default parameters for methods B and C and no other changes. So as consistent and standardized as possible while still having enough difference for selecting outputs as retouching sources to be meaningful.

I’ve uploaded a stack for issue 3 with method B and C projects showing alignment differences on the same source images. Based on some probing it looks to me like at least one component of the issue is no mechanism exists for coordinating alignment between two HeliconFocus.exe processes, the first employing one method and the second the other method. This suggests there may be a workaround in ensuring the same process always completes both stacks, either by manual operation of the UX or by ensuring this when a batch is set up. If so, the workaround unfortunately seems unlikely to extend to command line use as there seems to be no way to pass a batch on the command line, either in a general form or a minimal one like -mp:1,2.

I'll also upload the stack the next time I encounter issue 1 or 2 and bump this thread.
Post Reply