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

[Catherine]

is there a keyboard shortcut for zooming in and out ?

Helicon Focus supports the standard zoom shortcucts: Cmd + / Cmd -
Although Umbel is not wrong to say + and - are also common, there is no single standard set in stone and of the competing options for zoom shortcuts we chose the above one.

it doesn't seem to be documented or discoverable

Good catch indeed, we'll add it to the manual, and at the very least the shortcuts should be listed in the View menu so that they're easily discoverable - we'll address that as well.

The UX's inefficient use of screen space which motivates more zooming than really should be necessary is another.

Could you please elaborate, what stands out to you as insufficient and what would you like to be arranged differently?

Helicon's menus aren't navigable using alt+letter+letter+... keypresses.

Already added this to the to-do list.

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.

We certainly do use our products and especially Helicon Focus, and we all have either a mouse or a touchpad. None of us currently has a tablet so we haven't experienced first-hand some of the tablet-specific hurdles, but we very much want to improve the experience for those who do rely on a tablet for their work. Are there other tablet-related inefficiencies that you could highlight?
As for the menus - I personally very rarely find myself using the menu, other than for exporting something - the shortcuts for Preferences and for the basic Save / Save all actions cover my needs, but of course you've made a good point that all the menus should be navigable using keyboard.

[umbel]

Hi Catherine! Good to hear from you.

Already added this to the to-do list.

Cool, thank you. I think there may be other menu items which don't display corresponding shortcuts or mouse actions as well as some shortcuts and actions without menu items. Zoom fit, zoom 100%, and the retouching grid toggle come to mind.

I generally seek to avoid menus as well. Not sure things like File -> Open stack... (which I use for nearly every stack) and Edit -> Preferences -> Autoadjustments (where I change all the settings on and off depending on the stack) necessarily merit shortcuts, though. Anyone who wants to tidy up the tab order of the autoadjustment controls as well will be my hero.

Could you please elaborate, what stands out to you as insufficient and what would you like to be arranged differently?

I've written about this before, actually, so I made some crude mockups showing how I would remove most of the dead space on a 1600 x 900 laptop display and uploaded them to the ftp server. Potential use of docking aside, the base changes are all ones I've made in applications with similar layouts and are quick drag rearrangements in most UX editors. The use of window chrome to access title bar space is a little bit more work but it's been worth it in my experience.

None of us currently has a tablet so we haven't experienced first-hand some of the tablet-specific hurdles, but we very much want to improve the experience for those who do rely on a tablet for their work.

Awesome! I have just an entry-level Wacom (about 1500 hyrvnia when I got it some years ago) so I don't think I can comment as deeply as users with more capable tablets. My main observations, though, are

• Helicon's mouse based shortcuts don't translate because there is no right click or middle button with a tablet stylus. With my laptop's touchpad I can set three finger tap to middle click but it's awkward and the toggling between zoom fit and zoom 100% often doesn't go in the direction I want. It would be easier to have shortcuts like 0 for fit, 1 for 100%, and 2 for 200%. Since there are no middle button clicks, swipe up/down for zoom in/out is imprecise and often zooms too much. At the moment I'm experimenting with setting the stylus to ctrl+- and ctrl+shift+= for zooming but I think I'd still rather have single keys. I miss out on all the brush changing.
• It's not great to have to be moving the mousing hand back and forth to the keyboard for shortcuts but it's more awkward with a stylus. This is particularly true for shortcuts like ctrl+shift+= for zooming. It's a three key gesture with both hands when just pressing = with the non-tablet hand that's already on the keyboard would do. While this isn't technically correct since it should be shift+= to type + I've never had a user care ever.
• I want to bind ctrl+z and y to undo/redo stroke, not point. Points don't make enough of a change and my stylus is too basic to be flipped around and used as an eraser. For styluses with erase support it seems natural to bind that to Helicon's erase brush, though.
• In principle I can set the tablet for on screen controls, which could help with Helicon integration. However, Wacom's interface on this is invasive and laggy as well as a pain to actually get completely turned off due to OS interactions. So I look to Helicon or whatever other image tool I'm using the tablet with instead.

Picolay doesn't have retouching, so tablet use isn't relevant. Retouching in Zerene is so slow I haven't really done enough of it to make a good comparison, I think.

[Catherine]

Zoom fit, zoom 100%, and the retouching grid toggle come to mind.

All of those are already done/fixed.

File -> Open stack... (which I use for nearly every stack)

Will be Ctrl + Alt + O in the next release.

Edit -> Preferences -> Autoadjustments

That's Ctrl+Alt+P -> Ctrl+Tab. Seems quick enough to not require a separate shortcut?

Anyone who wants to tidy up the tab order of the autoadjustment controls as well will be my hero.

Alright, none of us noticed that one, we'll also try to fix it for the next update.

I made some crude mockups

Great suggestions indeed, thanks for the mockups! We'll discuss this, some of the changes are simple to implement. Although I don't think we'll be hacking the title bar in the near future (it's not portable, and more importantly, I don't think it will play nicely with the GUI library that we're using so it will require twice the effort compared to a barebone Windows application). But it's worth considering and keeping on the to-do list for sure.

And thanks for the list of the tablet-related hurdles, we'll discuss it as well. The only thing I can note right now is that zoom in/out is much more natural (in my opinion) with the plus and minus buttons on the numeric block of the keyboard, but that still requires both hand so is irrelevant to this discussion.

[umbel]

All of those are already done/fixed.

Nice!

Glad the mockups were helpful. On further thought, the minimum width of the source image list and brush controls on the retouching tab could easily be reduced. So I uploaded another mockup showing that. This would provide about another 100 pixels of image width, which is an 11% increase on a 1600 pixel wide display. Enough to make a noticeable improvement in retouching. The idea could be extended to provide additional image space by showing only unique parts of file names. Or allowing the size of stack icons in the lower tray to scale.

Given the number of applications which use title bar space I wouldn't say doing so is a hack. Even in UI frameworks with support it does tend to be relatively expensive to access, though. 7.6.1 has lots of easier pixels which could be used more effectively first.

The only thing I can note right now is that zoom in/out is much more natural (in my opinion) with the plus and minus buttons on the numeric block of the keyboard, but that still requires both hand so is irrelevant to this discussion.

It also requires a keyboard with a numeric block. Some laptops have a function key toggle to switch part of the keyboard over, but it's my impression most don't. And, on the ones I've used which do, it's often a two handed thing. It's my sense numeric blocks are slowly getting less common on desktops as well. (As an example, none of the desktops or laptops I've used regularly in the last 7 years or so has been set up with a numeric block.)

So when I assign key bindings I usually look at the numeric block as something extra which may benefit only certain users. With mouse or tablet intensive apps, the users who can most easily make use of such bindings are left handed and therefore have their right hand free for the block.

[Catherine]

Thanks! And I agree.
I've attached your new mockup to the corresponding ticket on our task tracker, so while I still can't say when we might get to implementing some of the suggestions, at least it won't be lost.

[Margaret Bartkowiak]

[*]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.
[/list]
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.

Hi there Umbel and Catherine

This is my first time joining a Helicon thread and I have a feeling won't be my last. I was just wondering and hoping if the "Failed to load project file: Brush source file not found" issue has been resolved. I am working with hundreds of stacks of museum specimens and would really benefit from being able to save a project file after retouching it with another output source image. My workflow involves stacking in Method B and C and then editing the halos out of Method B with Method C as my output source. First I saved the C Method stack in hope of Helicon "seeing" the output source in the same folder. Then I saved the project. Then I loaded the project, the error message came up and I wanted to pull my hair out. Right now I have to edit from start to finish if I want a resulting image and I don't have the flexibility to work with the project file later if I need to retouch further, create animations, export 3D models, etc. Is there anyway around this?

Many thanks
Margaret

[Catherine]

Thank you for reporting a problem. We did manage to reproduce it. Solving this issue will take some time and effort, but we're aware of it, we have it on our to-do list and we are working to fix it. We'll post an update once the fix is ready

[Margaret Bartkowiak]

Thank you for reporting a problem. We did manage to reproduce it. Solving this issue will take some time and effort, but we're aware of it, we have it on our to-do list and we are working to fix it. We'll post an update once the fix is ready

Hi Catherine

Holding thumbs you can resolve this issue. I have noticed the updated version Helicon Focus (Lite, Pro, Premium) 7.6.4 (27.07.2020) now shows a message warning the user that the project file cannot be saved so at least there are no surprises later trying to load a project file that cannot open.

All the best and many thanks
Margaret