Helicon Focus 7.6.1 feedback and discussion thread (was Duration of holiday sale and development outlook?)

Announcement of new releases, bugs, support, suggestions
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Helicon Focus 7.6.1 feedback and discussion thread (was Duration of holiday sale and development outlook?)

Post by umbel »

Hi, I'm currently re-evaluating Helicon and Zerene under trial, having previously trialed both some years ago. Helicon Focus 7.6.1 is looking attractive for my current workflows so I was wondering two things.
  1. How long will the holiday sale run? I know with Zerene I have until December 31st to decide whether capture their 20% off. But, if Helicon's made a similar indication, I'm failing to spot it on the website or Facebook.
  2. Does Helicon provide an indication of development direction priorities to other photography and software companies (e.g. Canon, Fuji, Microsoft, Nikon, Olympus, Panasonic, ...)? I ask because I've encountered a surprising number of glitches in 7.6.1 on Windows 10. So it would be useful to have some sense of what to expect in future versions.
Since there'll probably be some curiosity as to what the glitches here's a subset of what I've noticed so far. Lest this be taken the wrong way, I'd like to also point out I'm considering a lifetime Helicon Pro license because there's a lot of things Helicon gets right around UI responsiveness, displaying progress on queued work, and balancing image quality with stack speed. The F9 source selection and color sensitive retouching are awesome.
  • If Ctrl+Z or Ctrl+Y is pressed too many times during retouching 7.6.1 crashes. From what I can tell this looks like a problem with running off the end of the undo/redo action chain, so it's surprising the unit or UI tests aren't catching this. (I can email some of the resulting crash dumps from %LocalAppData%\HeliconFocus to support if they're of interest.)
  • Ability to add multiple stacks to a project but only saving the most recent stack. Silently discarding a user's work is pretty much never a good idea. So it's a bit concerning the user interface allows a many to one stack:project configuration when apparently the project part of the system only supports 1:1. Limitations around saving projects to allow retouching after batch processing noted in a few other threads here seem corollary to this. Zerene's project generation during batch processing is more thought through than Helicon's present form and, for me, this is a substantial compete as improved retouching is one of the main things I'm looking for.
  • Missing accelerator keys and shortcuts. For example, Alt+F doesn't open the file menu, Ctrl+S doesn't save a file, the + and - keys don't zoom in or out like they do in most image manipulation software (either with or without control or shift), and so on. This slows basic, repetitive tasks such as moving around images during retouching, lowering productivity.
  • Pressing space toggles only the most recently selected frame in and out of stack rather than operating on all selected frames. As a result, it's faster to shred video by scripting ffmpeg externally from Helicon, review the resulting frames in IrfanView, delete them in Windows Explorer, and then import the resulting .jpgs in Helicon than it is to use Helicon's built in functionality.
  • Not providing a list of which outputs aren't saved in the exit warning. But also apparently forgetting that the outputs from batch processing are automatically saved. The latter is a basic state check so I'm surprised unit tests aren't catching the defect. I also see I'm not the only user to have noticed.
  • When stacking 8 bit TIFF input (generated from Hugin/PanoTools) output TIFFs are saved with malformed transparency channels and may or may not viewable in other software. So far it's been trivial to fix this by stripping the transparency channel in other software but that's not something which should be necessary.
I can live with or work around these and their companions but it'd be kind of nice not to have live with all of them indefinitely.

While most operations in Zerene are slower my experience is it's more robust and therefore potentially competitive when time lost to crashes or other software limitations is considered. More clearly assessing that tradeoff is something which will require spending some time using both tools, hence the curiosity as to when the holiday sale closes.
Last edited by umbel on 08.05.2020 04:08, edited 2 times in total.
User avatar
Catherine
Posts: 1163
Joined: 29.04.2019 22:38

Re: Duration of holiday sale and development outlook?

Post by Catherine »

Thank you for your detailed report, we need a bit more time to consider all of the points. The sale will be on till Jan-15.
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Duration of holiday sale and development outlook?

Post by umbel »

Thank you, Catherine, that's good to know. I need a bit more time to consider all of the points too as figuring out how to fit workflow around the speed-reliability tradeoff offered by Helicon-Zerene is both a compute and retouching time intensive process. 8)
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Duration of holiday sale and development outlook?

Post by umbel »

Lifetime license acquired. 8)

I've bumped a few other threads where relevant but have encountered some other things for the minor fix list if they're not there already.
  • While page up and page down allow for moving within the source images list after F9ing to a frame for retouching, additional shortcuts like ctrl+page up/down arrow for moving ±10 source frames would be helpful, as would something like shift+ctrl+page up/down to move between the source image list and output list when retouching. Having shift+drag like Zerene would also be helpful, though I'm not sure the current source image cache is entirely up to this. (It'd also be nice if shift+page up/down moved to the new end of the selection rather than requiring separate scrolling.)
  • Zooming in response to touchpad strokes is overly responsive, making it hard to get right size. Adding the usual +/- keyboard shortcuts mentioned above would avoid this problem but it's still an area for improvement. A keyboard shortcut for zoom to fit would also be something I'd use a lot (ctrl+0 is a common choice).
  • If you shift or control select a range of source frames and press space to toggle their checkmarks only the check for most recently selected frame changes state. Workaround is to remove the images, which is OK but slow, particularly if you want to add some of them back later.
  • Tab order hasn't been set in the control layout. For example, a routine task is to go Edit -> Preferences -> Autoadjustments and set vertical, horizontal, rotation, and scale all to zero to turn off autoadjustments. An equally routine task is then to go back and turn them on again. Doing either of these like one would in most programs by pressing tab to move from one control to the next and it's a miserable experience as everything in the dialog is out of order. This seems odd as most user interface frameworks I've used automatically establish a natural tab order without requiring any action on the UI designer's part. Workaround I use is a combination of mouse, typing, shift+tab in cases where adjacent controls are in reverse order, and tabbing if it's faster than mousing. This is way more complicated and time consuming than it needs to be.
  • If an error prevents Helicon from creating an output you get a placeholder output with red on it in the tray. Right clicking and removing this output deletes an adjacent output which does exist rather than removing the error. Workaround is to live with the error showing even after you've fixed it and rerun the stack.
  • If you do a stack, decide you're not going to use it, delete the directory with the files in the stack, and then go to remove the corresponding output by right click Helicon responds by crashing. Since there's no project or retouching autosaving or autorecovery you lose any unsaved work.
  • At least on Windows, seems to Helicon exceeds its configured memory limit (Edit -> Preferences -> Performance -> Memory cache limit) and will thrash disk. Not sure if this is just 0.5-1 GB of non-cache memory consumption or if Helicon computing its limit against at the total amount of virtual memory available (RAM + swap) rather than the actual amount of physical RAM. Either way, the workaround is to artificially lower the limit. However, because the slider moves in 10% increments, this a crude solution as the dialog offers only steps of multiple GB. Reducing the minimum step size of the slider from 10% to 2-5% would work for me.
  • Saving a project from the retouching tab without doing any retouching results in a malformed project which cannot be reopened. I was able to fix this by replacing the base64 encoded retouching blob in the project XML with a blob from another project without retouching.
  • Undo of retouching gets very slow after retouching for a while. Workaround seems to be to save the project file, so maybe having autosave would help here too.
  • Rendering seems to always use a number of threads equal to the processor's hyperthreaded capacity. This sometimes makes it unnecessarily slow to use a machine for other things while stacks are running. For example, if I'm working on a quad core HT machine I could sometimes get more done faster overall with Helicon running six threads rather than eight.
  • While revised to fit on laptop screens, the user interface layout still has a lot of empty vertical space and is cramped on smaller screens like a 14" 1600 x 900 display. The toolbar below the menu, render/retouching/saving tab set, and zoom controls at lower right are all easy areas to free up space. Allowing the source images panel to extend higher on the right hand side and moving the zoom controls into it to remove the empty space under the outputs would probably be a quick improvement. Since the current retouching interface forces use of the mouse for source frame selection it'd be particularly nice to have more than three source frames showing in the list.
  • Can't drag and drop to reorder outputs/projects in the output tray. This is a bookkeeping thing. For example, if you're working from left to right through a group of stacks (I seldom have only one open and often am working with four to eight) and find you need to run another version of a stack to support retouching or something then it ends up out of order in the tray.
  • No way to perform basic tasks on multiple outputs/projects at once. For example, I often have directories containing two projects, one for method B and one for method C. So I want to open both projects together but the current UX makes me open them one at a time. Once done with them, they have to be removed one at a time. As the number of stacks increases, the result is triplicate, quadruplicate, or more redundancy in performing routine tasks. This is mildly inconvenient so not a big deal. But it quickly gets old.
  • I have one stack where the retouching brush won't transfer pixels from the source to output in certain areas of the image no matter what tolerances I've set. Not sure what's up with this but it's only some of the pixels within the brush so maybe related to pattern noise in method B and C output.
Having run a lot of stacks over the past weeks, this should be (I hope!) the sizeable majority of the issues I'll hit in Focus 7.6.1. But I'll bump this thread if I find other things.

Also, two things about the performance table (https://www.heliconsoft.com/helicon_focus_benchmark/table_view.php).
  • It seems only the fastest result for a given chipset is reported. While I understand this choice, it would still be useful to be able to click into a particular chipset and see all of the results. That would give a sense of the performance distribution observed and provide some ability to pick up outliers, quantiles, mean, and variance. For example, a particularly maximum value might be the result of overclocking and therefore wouldn't be representative of the performance most customers would get from the same part. Similarly, turbo frequencies are variable and partially contingent on thermal environmental conditions but it seems table entries typically report base frequencies rather than the actual clock during the benchmark. I have enough of a performance profiling background to be used to disentangling such things and can therefore guard my expectations as to what particular hardware might deliver for method B performance but others may have a harder time with this.
  • For GPU results, it looks like the number of threads reported is what Helicon would schedule on the companion thread rather than the number of threads actually resident on the execution units. This is confusing but I assume Helicon schedules enough work to the GPU to fully utilize it.
Last edited by umbel on 02.02.2020 16:56, edited 2 times in total.
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Duration of holiday sale and development outlook?

Post by umbel »

Hi, two additional issues, one I neglected to mention earlier, one new.
  • Helicon's installer doesn't associate .hproj files with Helicon. Working around this by manually creating the association causes project load to fail with "Load image error: unsupported file format", which is strange as drag and drop is a supported way of opening .hprojs even though they're not mentioned in the "To add source images please drag images here or use 'File\Open images' menu command" message. (Aside: the resource string should be "use the 'File\Open images' menu command".)
  • I'm encountering "Failed to load project file: Brush source file not found" errors beyond the XML repair mentioned above. From what I can tell, the message this error is attempting to communicate is "Some retouching strokes could not be replayed because a linked project could not be found." If so, this is problematic because the message doesn't indicate which project could not be found, making it difficult for the user to action, and because it's treated as a fatal error. As a result, the user loses the ability to access anything in the project and therefore has to repeat the compute for stacking as well as all retouching from input images and any other projects which can still be found. It's also problematic because this error can prevent reopening projects when all of the result.tiff files in linked projects and are definitely available because those projects were saved before retouching began and were not deleted from disk. I haven't been able to find a workaround so it appears that once this happens a project is useless. It's especially pernicious because the user can continue saving the project to capture retouching without any error or warning from Helicon and therefore continues to invest time in retouching a project when the optimal course of action would probably be to abandon it and start over.
It's likely not necessary, but I've uploaded an example of the latter. I think the way users can mitigate the retouching fragility is to assume all retouching has to be completed. If Helicon happens to crash during retouching, as it often does, or you realize later you need to go back retouch a missed area, well, maybe it sucks to be you. Hopefully this can be improved in the next release. In particular, I notice Helicon places copies of stack results, depth maps, and opacity maps in %TEMP%\Helicon\{guid}. If the base64 retouching blob in the project XML points to these temporary files rather than where linked projects are saved that might explain some of the difficulties.

Also uploaded .dmps from assorted crashes.
User avatar
Catherine
Posts: 1163
Joined: 29.04.2019 22:38

Re: Duration of holiday sale and development outlook?

Post by Catherine »

Thank you for documenting your findings in such great detail! We're processing your previous post now - have confirmed some issues, while some other need clarification. We will post comments and questions when we finish going through all the points (it's taking a while).

As for the new findings:
1) We didn't consider creating this association (perhaps we should), but certainly it should be able to load the project file through such association, we've just fixed that for the next update.
2) I don't even recall ever seeing that particular message. We'll look through the source code to see what conditions trigger the message.
I have downloaded the files you provided, and I see three projects. The two that are in the same folder open without any problems whatsoever in Focus 7.6.1, and the other project (P1080004) is missing its source images so naturally it fails to load. Which one(s) of these projects were supposed to give the error in question? And I'm afraid that it's quite necessary, or at the very least highly desirable that you upload the sample project we could use to study the error because so far I don't know how to reproduce it, which means we'll have a very hard time finding and studying it.

Was this project saved in the same version of Helicon Focus you're using to open it?

P. S. The files in %TEMP%\Helicon are indeed temporary, and are deleted on program exit. The project could only possibly reference them by mechanical programming mistake - and I doubt the explanation is that simple.

As for the crash dumps, we're also studying them right now, it's tedious but they do seem to contain some hints as to where the problem might be.
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Duration of holiday sale and development outlook?

Post by umbel »

Hi Catherine,

1) Cool, that's awesome!
2) P1080004 goes with this thread (the other two projects were uploaded earlier for the misalignment issue of https://forum.heliconsoft.com/viewtopic.php?p=23280#p23280). I could reproduce the "Brush source file not found" without the images but they're uploading now since you need them (the connection is slow and currently projecting completion in 1h 45m though there are some problems with timeouts so it may be longer).

Debugging from .dmps isn't my favorite thing either.

For 2) I've also found a compact repro:

2.1) Stack some images with method B and C. Before doing anything else, save one of the projects. This gives a base64 retouching string of AAAAAA== which decodes to the bytes (0, 0, 0, 0).
2.2) Go to the retouching tab and select the output from the other stacking method. Without doing anything else, such as making retouching strokes, save the project. This gives a base64 of AAAAAQAAAAz/////AAAAAA==. Opening the project file in a new HeliconFocus.exe process will then fail with "Brush source file not found". The bytes for AAAAAQAAAAz/////AAAAAA== are (0, 0, 0, 1, 0, 0, 0, 12, 255, 255, 255, 255, 0, 0, 0, 0).

It seems to me it's unlikely the 12 added bytes suffice to indicate a durable location for a project which wasn't saved (!) and it's also strange that just selecting a retouching source without actually doing any retouching breaks the ability to reopen the project. You've likely noticed already, but monitoring the %TEMP%\Helicon\{guid} directory during the second step above shows selecting the other output for retouching prompts some files to be copied to the {guid} directory.

So I think maybe there is a retouching issue where temporary outputs are inadvertently getting treated as if they were durable source images. This seems like it could be fine for quick retouching where saving projects isn't done but I'm struggling to think of a way to make it work with saving project files. I suspect what this means for using 7.6.1 is projects are a way to save stacking results, retouching from source images, and text/scale settings. However, for retouching from outputs (which dominates my time spent on stacks), I should probably plan my work to maximize persistence of the HeliconFocus.exe process providing retouching. That's not great but I think I can make it work OK.
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Duration of holiday sale and development outlook?

Post by umbel »

Hi, hit another issue: high memory consumption on stacks requiring significant retouching. When I transferred this one off to a photo editor for the remaining cleanup Helicon Focus' memory consumption was 4.1GB with only the two needed stacks open. That's a 1.3GB increase over 2.8GB for just the two stacks. Considering the image is 8.3MP and most of its pixels are unaltered from the method C output, this seems high by perhaps 1GB (the remaining 300MB would still be enough to store six complete copies of the image in 16 bit color).

I've uploaded the projects and source images (P1080041C.hproj, primarily) though, as we've discussed, it won't be directly openable due to loss of the temporary files used by cross-output retouching. However, it may be helpful to look through the retouching information in the 1.6MB project file.

The retouching here also a good example of why I'd like to be able to bind the rocker switch of my tablet's pen to keyboard shortcuts for moving up and down in the stack. Would make verifying the best source image to retouch from so much faster.
User avatar
Catherine
Posts: 1163
Joined: 29.04.2019 22:38

Re: Duration of holiday sale and development outlook?

Post by Catherine »

umbel wrote: 21.01.2020 04:14 The retouching here also a good example of why I'd like to be able to bind the rocker switch of my tablet's pen to keyboard shortcuts for moving up and down in the stack. Would make verifying the best source image to retouch from so much faster.
Does your pen have customizable button(s)? In that case, bind them to PgUp / PgDn. If they're not customizable, they're probably emitting left/right mouse button clicks, and binding source image switch to mouse buttons doesn't seem like a good idea.
umbel wrote: 21.01.2020 04:14 hit another issue: high memory consumption on stacks requiring significant retouching.
I don't think there's any issue here, or at the very least, what you described does not indicate one, these are perfectly expected numbers. Images are not stored as a list of changed pixels, they're stored entirely. Retouching requires a few additional images besides what you see on the screen. And there's not one, but two levels of memory cache that will keep chunks of previously allocated memory for possible later reuse but will free it as the total available volume of system memory diminishes.
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Duration of holiday sale and development outlook?

Post by umbel »

Hi Catherine, thank you for pointing out page up and down as I'd somehow missed them when going through the help. Haven't had a chance to try a retouching session with the Wacom assigned to them yet but looks good on a quick check with the keyboard. My default pen button assignments are actually undo/redo, though that's more of an image editor thing and I had to disable undo as Helicon kept crashing.

I didn't mean to imply high retouching memory consumption wasn't by design. It would, however, be helpful if the design moved towards allowing more efficient use of memory. A forum's probably not ideal for detailed discussion of caching and memory footprints but one aspect of this might indeed be the apparent limitations in managing overall memory footprint noted upthread. I do see Helicon spin down to low levels when idle. (And I've implemented functionally identical image list navigation which also had attached layers; had no difficulty maintaining the entire application under 2GB at the same image size.)

As something of an aside, DIMMs are relatively inexpensive, sure, but my current hardware's already maxed out and increasing use of soldered configurations in laptops makes it not so simple when purchasing new hardware. This may be incorrect, but I'm kind of getting the impression Helicon's memory interactions come more from a desktop context rather than laptops where, at the moment, 8GB with no possibility of change is something of a de facto standard. On heavier laptops 8GB soldered plus one DIMM socket is common, imposing a maximum of 24GB, and manufacturers monetize aggressively by pushing up base prices for systems with more memory, charging 4-8x market rates for DIMMs, and voiding warranties if you install a DIMM yourself. There are some two socket laptops I'd interested in as a way to 32+GB but they have Nvida GPUs not supported by Helicon's OpenCL implementation. In comparison, 16-32+GB in a desktop is easy but the additional space and cost for a second system is not.
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Duration of holiday sale and development outlook?

Post by umbel »

Uploaded a crash dump with log for another crash pathway related to the need to have long running Focus processes in order to retain "project" temporary files across multiple stacks, some of which may be completed and removed and some of which are still in progress. Should be a straightforward fix, I think, so the user doesn't have to remember to remove completed stacks from Focus's tray before removing them on disk. All that's needed is to mark no longer valid project components for the user instead of crashing while trying to load them. (Perhaps I'm missing something but, in my experience, this is routine lifecycle management and it's something I've supported in every multifile project format I've ever coded. Zerene, for example, handles this by displaying an informative error and then prompting the user to relocate the images.)

Since previous months' dumps and images haven't been removed I'll delete them in a few days on the assumption they've been copied to a secure store. Please let me know if otherwise.
sunnywilson09
Posts: 1
Joined: 14.04.2020 20:48

Re: Duration of holiday sale and development outlook?

Post by sunnywilson09 »

I need a bit more time to consider all of the points too as figuring out how to fit workflow around the speed-reliability tradeoff offered by Helicon-Zerene is both a compute and retouching time intensive process.
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Duration of holiday sale and development outlook?

Post by umbel »

Yes, I found 30 days to be just enough. But only because I'd worked out quite a few things using Picolay first and intentionally started the Helicon and Zerene 30 day trials during a period when I knew I'd have both a lot of time to use the stackers and plenty of images available to test on. 30 days is great compared to Adobe's 7 days and Affinity's 10 days, though Affinity's doing a 90 days at the moment as a coronavirus support thing.

In general, I would say if you're doing a lot of stacking the productivity of Helicon Focus Pro is worth sorting out how to avoid its quirks. For less frequent stacking or shallow stacks Zerene's relative slowness is less of an issue and its greater reliability probably more of a benefit. I have also a Zerene license and continue to use Picolay on occasion, though I try everything in Helicon first and check the other stackers mostly on problematic images. Usually Helicon is extremely close to the others in image quality and usually I don't have so much retouching to do that it's a problem to leave Helicon running to work around the project limitations described above.
Nick 13
Posts: 5
Joined: 29.04.2020 14:50

Re: Duration of holiday sale and development outlook?

Post by Nick 13 »

I am new to Helicon and wasn't sure how to start a new topic on the forum, but my simple question, as referred to in this post, is - is there a keyboard shortcut for zooming in and out ? I do not have a mouse, instead I use a Wacom tablet on my Mac. It would be greatly convenient to be able to use a shortcut for zooming
Thank you
User avatar
umbel
Posts: 34
Joined: 12.12.2019 08:26

Re: Duration of holiday sale and development outlook?

Post by umbel »

Hi Nick, it's the new topic button at the top (much like any other forum). To my knowledge there isn't a keyboard shortcut (and, if there is, it doesn't seem to be documented or discoverable). What I do as a workaround is tablet with one hand and touchpad zoom in/out strokes and arrow key presses for panning with the other. It feels silly but it kind of works. The resulting lack of reliable zoom stepping is one of the many issues noted previously in this thread. The UX's inefficient use of screen space which motivates more zooming than really should be necessary is another.

It seems very strange to me the = and - keys aren't bound to zoom in and out, as they are in most applications, or that Helicon's menus aren't navigable using alt+letter+letter+... keypresses. Zerene implements routine menu keyboarding and well defined zoom levels but, bizarrely, makes changing zooms even more tedious than it is in Helicon. Picolay is slightly less terrible about this but still doesn't bind keys to zoom in and out. I know the developers all use their own software so I'd be curious to know their workflows and understand why these issues aren't slowdowns for them. From Helicon's shortcuts it seems like maybe there's an assumption of a scroll wheel mouse, which strikes me as a somewhat unrealistic constraint but also consistent with some of the apparent orientation towards desktop computing noted upthread.

Helicon's been in development for 15+ years but, maybe someday, the developers will find the minutes to add keyboard bindings to its zoom in and out commands and then the rather longer amount of time needed for adding tests and localization. Seems like it'd be an easy compete over some of the other stackers.
Post Reply