Peter Werner

Photoshop has traditionally had the Select > Color Range command. There is also HSL keying inside the Hue/Saturation adjustment toolset, which, annoyingly cannot be used to create selections for use with other commands without clumsy workarounds (that I know much better than I would care to admit). 
 
What I am hoping to see is a non-destructive way to do masking based on luminance, HSL tools, as well as possibly more sophisticated keying algorithms that are found in video software (Primatte, Keylight, etc.). Most video-focussed color correction software (DaVinci Resolve, Speedgrade, Lustre, Baselight, FilmMaster, Assimilate Scratch) allows for non-destructive HSL keying already.
 
The most elegant way I can imagine this working inside Photo is that similar to regular layer masks, a new procedural mask layer type for non-destructive HSL/Select Color Range masks with adjustable parameters would be available. Like an adjustment layer, except that the result would be a mask instead of an RGBA image, to be used just like regular layer masks.
 
That way, it would be easy to adjust the selection parameters interactively after the fact, and, if need be, rasterize destructively to a regular raster mask layer. In additions to the keying in Luma, RGB, HSL, YUV and LAB, parameters for blurring the result, expanding/contracting the mask would be useful. The exact same functionality could then double as a vastly improved "Select Color Range" command as well.

When exporting, you can only tick the box for bleed to be included. On an ongoing project, I need to export different formats with different bleed options, i.e. 1mm vs. 3mm bleed. I was used to set a global bleed of 3mm in Illustrator and change the value to my liking when exporting to PDF. With Designer I need to fumble with the document’s bleed in order to change to and fro with 1mm and 3mm. Allowing for setting a bleed size in export settings would save me time again, and make Designer a little niftier than it already is :) . 

As soon as Publisher and multiple pages arrive, this is likely going to be an issue. Even when you're not embedding, but just linking, assuming Affinity will store a preview in the document. You'll get people with terabyte-sized files (not to mention photographers who edit hundreds of high-res pictures per shoot and store layered files).
 
Or take InDesign as an example – if you place a lot of images that have a DPI value of, say, 96 set in the file metadata, it will assume that the image is really big (in terms of physical area) and thus stores a close to full res preview, resulting in extremely large and bloated document files despite image files being linked.
 
I know of course nothing about the Affinity architecture, but I'd expect that file I/O bandwidth would really be the limiting factor and that decompression could basically happen in the downtime when the processor is waiting for the data to arrive from the drive, so the speed penalty should theoretically be minimal. Of course this might be different on platforms like iOS where storage is quite fast.
 
Recent Linux and now also macOS versions have a module that losslessly compresses memory pages before it starts going into swapping because it's still faster to compress and decompress data in memory on the fly than to save to and load uncompressed chunks from disk. I've always wondered why Adobe hasn't added anything like that to Photoshop's memory manager, but I guess the dev team is busy with stuff like coding HTML5 skins like Design Space.
 
Unless there is really a major slowdown associated with this, I'd definitely say that there should be an option (or alternatively a good behind the scenes mechanism) to stores the original compressed version in Affinity files instead of full uncompressed raster data. That way, it would also be possible to "unembed" the original image data, and not a huge uncompressed file or a lower-quality re-compressed one.

We hope to include a glyph panel in 1.6.

Yes, I think we will at some stage.

Digital Publishing in InDesign is also largely not very good, mostly due to Adobe trying to monetize the hell out of this market with their hosted solutions, or recently their push to the cloud system with their Publish Online feature – your client's publication stops working if you have an issue with your Adobe subscription or cancel it. You can't host it on your own server. Great. Before that, there was this horrendously expensive abomination called DPS with its Flash-based UI panels, ginormous files and messy bugs.
 
One thing where InDesign is particularly horrible is with authoring interactivity parts. In an effort to make it simple, they came up with this unnecessarily complicated preset-based system for animations, whereas a simple timeline like in Macromedia Director and its Behaviors (scripted procedural animations you could apply with a single click) would make everything so much more intuitive. Scripting basic interactivity inside the application? Not a chance.
 
Also creating slideshows, buttons, scrolling areas and any kind of multi-state object is a royal pain. It is really unintuitive to select objects after these compounds are created. It all feels like someone hacked a plugin onto the application instead of really thinking about how it could properly fit into the software architecture.
 
Another problem is that half of the interactivity features only work with PDF, others only with Flash, others are exclusive to ePub, others are for DPS, and so on. There is just no consistent concept that unifies all the interactivity features, there are all sorts of different previews for different workflows, and half of them are obsolete because Adobe had to change course.
 
While I do think Publisher should tackle print production features first, interactive digital publications are certainly an area where the experience in InDesign is severely lacking and a new product like Affinity Publisher could finally get things right.
 
Simple straightforward HTML5 output like the In5 plugin for InDesign offers (with support for Designer's constraints so that documents can adapt to the screen size), and ePub would cover the essentials for Affinity Publisher 1.0 I think. Features could then be expanded starting from there.

I'm using SVG as an exchange format for a project to get data into Affinity Designer.
 
The SVG standard does not support all blend modes that Designer supports, for instance the very useful "Erase" option is not supported.
 
It would be cool if the SVG importer would simply accept the non-standard blend modes that are supported in Designer but not officially part of SVG instead of reverting to "Normal".

Agreed, this has been an issue in Photoshop for years. Ideally, these keys would be bound to the keyboard layout so that even when you're changing between different keyboard layouts a lot while the application is running (like say, German, US English and Japanese), these types of shortcuts will still function reasonably well and not suddenly become impossible to press.

If you want to mimic what the old Ultimatte boxes used in television used to do, you can use Apply Image and use 
SG-MAX(SR,SB) as an expression for each red, green and blue (set alpha to 1 or simply leave it at sa). That's going to give you a grayscale mask. Clean that up with Levels, Invert, and then go Layer > Rasterize to Mask.
 
You can save that as a macro and it's as close as it gets to a one click solution.
 
An alternative approach that is also quite quick is to use is Select > Select Sampled Color. Can't test how well it works with green screen material right now, though, since I can't use selections due to this annoying bug, but it should work pretty well until Affinity gets a real HSL keyer.

Regarding point 3, this is how it is usually handled in most professional graphics software. Save and Save as are for native file formats that can be saved and re-opened without any loss of data and everything intact. Export is what you use when you want to get data out of the software for delivery or interchange with other software only.
 
One big reason why it makes sense to keep these separate is that you don't want to choose a format that does not support the full Affinity document model by accident when you do "Save as". If you did, your document would still be marked as "saved", and when you close the document, the software wouldn't ask you if you want to save it, meaning you would lose all the information that the file format you chose doesn't support.
 
Let's say you created an unsaved document and did some work on it, then "Save as" to JPEG, and then closed the document, you'd completely lose all your vector and layer information without any warning. Or even more subtle, if you did a "Save as" of a document to JPEG to send to a client as a proof, and then continued working on the document and in the end clicked "Save" (or pressed Cmd+S by habit), it would not only overwrite your JPEG proof file, it would also again discard all the information that keeps your document editable. Also, new users would have to know which file formats would preserve which editing capability or they would be bound to lose work by accident.

It would definitely useful to be able to use all transform and align tools on the control points as well. Not just the regular selection tools, but also things like flip operations, and possible future features like, say, bicubic mesh warp, selection brushes, Liquify-type warp brushes, noise-based displacement etc. if something like that is implemented. I think these type of features should always be designed from the get-go to work on both control point level and on object level.
 
Most 3D software actually handles that as some sort of global mode switch for toggling between object-level operations and component-level operations (control points, edges, faces etc.), and all tools in the applications support this switch, whereas most 2D software unfortunately limits the control point functionality to basic selecting and moving of points.

This is actually a really smart idea. Later when scripting is added, it would also be nice to have a corresponding "copy history steps as script" command.

Hi Peter 
 
Thanks fr raising this. I shall move this to our feature requests section for this improvement to be considered
 
Cheers

We have had these discussions in other threads already. Automating tasks is possible with Python as well, but Apple Script (which I personally find really confusing in terms of syntax) ultimately means support for platform-specific automation interfaces on the Mac, including support for tools like the discontinued Apple Automator. So depending on the intention of the feature request, Python may or may not be a viable alternative.
 
While I think Python would be fantastic because it is equally well-suited for simple and easy tasks that a beginner with very little programming experience might want to tackle, to complex seamless integration that would require lower-level C++ plug-ins in other software, I think it might be more constructive for us to talk about what type of automation and workflows we are trying to solve, rather than request specific technologies.
 
So looking at the original post, are we talking about requests for AppleScript because of Mac users' familiarity with the language? Or is it a request for a way to automate things where calls have to be made to multiple different programs, rather than just Affinity itself? Or is it simply about having robust scripting capabilities, regardless of language?

Well, I would even not compare javascript and Python ... Python is so much more powerful, easy to learn, efficient, more readable, and a standard for such softwares. Adobe is using Javascript, this should be a sign lol !

Most professional publishing software actually have a counterpart for text editing that is intended for the editors in an editorial workflow, like for newspapers and magazines. For InDesign, there is InCopy, for Quark XPress there is Quark CopyDesk. Editors can write their articles while accessing paragraph and character styles and seeing the text in context of the layout, including accurate text wrap. There are also locking mechanisms so people don't overwrite each other's work. Collaboration happens either via a file server or via something like Dropbox. These programs actually make fairly decent word processing programs, though they are of course not optimized for it, hence tasks like placing images, setting margins, and other layout operations are very limited.
 
As Affinity is going to be a professional suite, I expect that at some point in the future, there will be such a software that will take what I imagine would be a text editing persona from Publisher into a separate application, intended for editors collaborating with the layout department.
 
From my perspective, I think this should be a free or at least extremely low-cost program (say, 4,99€). That way individual designers could have clients or copy writers install that program, allowing these people to work on text inside the layout before the designer then makes final formatting touches. Much better than getting new Word files every day and manually re-applying all formatting in situations where there are a lot of frequent copy changes, but work has to start on the layout.
 
It could also serve as a free viewer for Affinity file formats that would allow people who don't have Designer/Photo/Publisher to display, export and print Affinity file formats.
 
I think a system like this could have one other really important use. For instance, many Designers are in the situation that the client has to come back to them for every single copy edit. Say, you are designing a brochure for a car company, and you want every dealer to have their address and their individual prices in there. With such a copy editing/viewer program, the designer could mark the corresponding text boxes as free to edit in the copy editing software. And then every single dealer could easily print or export customized versions every time their prices change (or address). There are solutions for InDesign out there, but they usually involve complicated and expensive server-based solutions that only make sense for large enterprise workflows. If Affinity Publisher/Designer/Photo were to provide a simple solution for that, that would be a godsend for many smaller workflows.

Most professional publishing software actually have a counterpart for text editing that is intended for the editors in an editorial workflow, like for newspapers and magazines. For InDesign, there is InCopy, for Quark XPress there is Quark CopyDesk. Editors can write their articles while accessing paragraph and character styles and seeing the text in context of the layout, including accurate text wrap. There are also locking mechanisms so people don't overwrite each other's work. Collaboration happens either via a file server or via something like Dropbox. These programs actually make fairly decent word processing programs, though they are of course not optimized for it, hence tasks like placing images, setting margins, and other layout operations are very limited.
 
As Affinity is going to be a professional suite, I expect that at some point in the future, there will be such a software that will take what I imagine would be a text editing persona from Publisher into a separate application, intended for editors collaborating with the layout department.
 
From my perspective, I think this should be a free or at least extremely low-cost program (say, 4,99€). That way individual designers could have clients or copy writers install that program, allowing these people to work on text inside the layout before the designer then makes final formatting touches. Much better than getting new Word files every day and manually re-applying all formatting in situations where there are a lot of frequent copy changes, but work has to start on the layout.
 
It could also serve as a free viewer for Affinity file formats that would allow people who don't have Designer/Photo/Publisher to display, export and print Affinity file formats.
 
I think a system like this could have one other really important use. For instance, many Designers are in the situation that the client has to come back to them for every single copy edit. Say, you are designing a brochure for a car company, and you want every dealer to have their address and their individual prices in there. With such a copy editing/viewer program, the designer could mark the corresponding text boxes as free to edit in the copy editing software. And then every single dealer could easily print or export customized versions every time their prices change (or address). There are solutions for InDesign out there, but they usually involve complicated and expensive server-based solutions that only make sense for large enterprise workflows. If Affinity Publisher/Designer/Photo were to provide a simple solution for that, that would be a godsend for many smaller workflows.

Most professional publishing software actually have a counterpart for text editing that is intended for the editors in an editorial workflow, like for newspapers and magazines. For InDesign, there is InCopy, for Quark XPress there is Quark CopyDesk. Editors can write their articles while accessing paragraph and character styles and seeing the text in context of the layout, including accurate text wrap. There are also locking mechanisms so people don't overwrite each other's work. Collaboration happens either via a file server or via something like Dropbox. These programs actually make fairly decent word processing programs, though they are of course not optimized for it, hence tasks like placing images, setting margins, and other layout operations are very limited.
 
As Affinity is going to be a professional suite, I expect that at some point in the future, there will be such a software that will take what I imagine would be a text editing persona from Publisher into a separate application, intended for editors collaborating with the layout department.
 
From my perspective, I think this should be a free or at least extremely low-cost program (say, 4,99€). That way individual designers could have clients or copy writers install that program, allowing these people to work on text inside the layout before the designer then makes final formatting touches. Much better than getting new Word files every day and manually re-applying all formatting in situations where there are a lot of frequent copy changes, but work has to start on the layout.
 
It could also serve as a free viewer for Affinity file formats that would allow people who don't have Designer/Photo/Publisher to display, export and print Affinity file formats.
 
I think a system like this could have one other really important use. For instance, many Designers are in the situation that the client has to come back to them for every single copy edit. Say, you are designing a brochure for a car company, and you want every dealer to have their address and their individual prices in there. With such a copy editing/viewer program, the designer could mark the corresponding text boxes as free to edit in the copy editing software. And then every single dealer could easily print or export customized versions every time their prices change (or address). There are solutions for InDesign out there, but they usually involve complicated and expensive server-based solutions that only make sense for large enterprise workflows. If Affinity Publisher/Designer/Photo were to provide a simple solution for that, that would be a godsend for many smaller workflows.

Hi Folks!
 
Would it be possible to get a divide blending mode? It gets used a tonne in vfx compositing where we want to separate different parts of an image so we can tweak things individually!
 
Thanks!
 
John

In general, I think it would be useful if all color corrections (Adjustment Layers), not just black and white conversions, could optionally be applied to vectors, i.e. baked into the vector stroke and fill colors instead of being essentially a raster post effect. Similar to the "Merge" command, only for merging into vectors.

In general, I think it would be useful if all color corrections (Adjustment Layers), not just black and white conversions, could optionally be applied to vectors, i.e. baked into the vector stroke and fill colors instead of being essentially a raster post effect. Similar to the "Merge" command, only for merging into vectors.

Photoshop has traditionally had the Select > Color Range command. There is also HSL keying inside the Hue/Saturation adjustment toolset, which, annoyingly cannot be used to create selections for use with other commands without clumsy workarounds (that I know much better than I would care to admit). 
 
What I am hoping to see is a non-destructive way to do masking based on luminance, HSL tools, as well as possibly more sophisticated keying algorithms that are found in video software (Primatte, Keylight, etc.). Most video-focussed color correction software (DaVinci Resolve, Speedgrade, Lustre, Baselight, FilmMaster, Assimilate Scratch) allows for non-destructive HSL keying already.
 
The most elegant way I can imagine this working inside Photo is that similar to regular layer masks, a new procedural mask layer type for non-destructive HSL/Select Color Range masks with adjustable parameters would be available. Like an adjustment layer, except that the result would be a mask instead of an RGBA image, to be used just like regular layer masks.
 
That way, it would be easy to adjust the selection parameters interactively after the fact, and, if need be, rasterize destructively to a regular raster mask layer. In additions to the keying in Luma, RGB, HSL, YUV and LAB, parameters for blurring the result, expanding/contracting the mask would be useful. The exact same functionality could then double as a vastly improved "Select Color Range" command as well.

It would be great to have global clipping warnings inside of the regular Photo persona.
 
Photoshop has implemented clipping warning overlays as part of a few tools, such as Levels and Curves, but it won't for instance help you when you are trying to use the dodge and burn tools to get a pure white or pure black background and other workflows.
 
Since I assume that this is already planned as part of the Curves and Levels improvements on the roadmap, I would suggest to make it a view option, accessible either from the View menu or in the Histogram/Scopes panels that can be used at any time, with any of the tools available instead of adding it only to two or meticulously adding it to all sorts of adjustments manually.
 
Holding Option inside Levels/Curves and on the Luminosity slider in HSL adjustments, Black&White etc. would then temporary toggle that option to the opposite of its current setting (i.e. on when it's off and off when it's on).
 
Video cameras often implement the overlay as a zebra pattern, and you can customize the threshold at which it shows up. That's actually a useful workflow for other areas as well. For instance, you could have your clipping warnings at 95% if you wanted to see which areas are reaching a range that while they might not be clipped, would not show detail when offset printing the image.
 
A preference to animate a zebra pattern inside the clipping warning, like the marching ants of selections do, would also make it help stand out when the image is visually very similar to the overlay pattern.

First off, hats off for a spectacular release, this is absolutely fantastic!!!
 
Sorry for bringing in my feedback at this point in time and in this form, but unfortunately I haven't had the time to take part in the Beta this time around. The following is all based on looking at James' excellent video demos, not on trying the features in practice, so my apologies if I'm overlooking things that are already there.
 
Here we go:
Having to activate the clone tool before double clicking a source seems kind of redundant. It would be useful if double clicking a clone source would also activate the clone tool as well if it is not active yet. In the Equations filter (which looks amazing by the way!), it would be useful to have a flyout menu that just offers to add the supported functions until a full expression builder is available. A button that takes the user directly to the corresponding help page with all the documentation might also come in handy. It would be nice if the Equations filter allowed to save equations as presets. This would also allow you to ship a few examples to get everyone started/inspired. Same situation for Apply Image. Macros are of course a workaround, but they are not as convenient if you want to use existing presets as a starting point for your own equations. When creating a new macro category, I think popping up a dialog asking for a name would be useful since pretty much everyone would likely want to name their categories right away. Those who don't want to could always just press the return key. I think the Pixel Art resize filters could be built into the regular image resizing dialog with an option to switch between regular resampling and pixel art resampling, and then changing the other options based on the choice. As the number of features increases, there will be lots of menu items, so this would keep the main UI less cluttered. It's also quite likely that a new user looking for the pixel art resizing feature would look for it unter the "Resize" command, and not think as far as to search for a separate command. Integrating it into the pre-existing dialog would also allow for readouts of the dimensions that, say, "4x" would result in (just re-use the existing input fields). For 360° editing, I think it would be infinitely more intuitive to add a 360° navigation tool (similar to the pan hand or zoom tools). In the current form, it's really hard to discover how to get back into the tool for someone who hasn't seen the video tutorial. The options bar could include an additional checkbox option for "Enable equirectangular 360° projection" for quick access (would be possible even in the current form). Since 360° projection viewing seems to be a per-layer setting, it would be useful to display a corresponding indicator icon in the layers panel for each layer that has the setting enabled. Or a separate checkbox column that can be shown and hidden via the flyout menu, or shown only when 360 projection is enabled for at least one layer. For macros, you are using the eye icon to indicate visibility of settings, but for layers in the layers panel, you are using a checkmark, which is a bit inconsistent. Might be wrong, but it seems to me that it is not possible yet to do HDR and panorama merge in one step, which would be cool since it would eliminate the need to manually export out the HDR files to EXR and re-import them to merge them to a panorama. For Apply Image, a small thumbnail in the dialog box would be useful to see what the source is currently set to and/or if a drag and drop operation yielded the desired result. In Apply Image, just like in Curves and other parts of the software (Channel selection in Adjustment Layers etc.), the color space choice is a drop down field, which, compared to, say, an NSSegmentedControl, requires an additional unnecessary click from the user. Drop downs are better suited for long lists like blend mode, but if there are only very few options, direct access buttons are much faster to use. This is really annoying in Photoshop as well. Also in Apply Image, the S in the variable names seems a bit superfluous – as far as I can tell, recursive operations don't make sense there, so just using r, g, b for the input color values would suffice I believe and make things slightly more readable. And if destination values should really be accessible, they would be differentiated by the D already, eg. DR = R + 50; DG = DR; (i.e. copy the result of the calculation for the red channel)  DB = B; In the video, EXR loading seems to occasionally take quite a bit of time – visual feedback in the form of some kind of progress bar would be useful, especially on slower computers. Seems to me that the histogram panel only shows values from 0..1 for now It would be cool if the Lighting Effect filter could access normals imported from EXR files for interactive relighting Tone Mapping: Need to play with this myself, but on first impression, it seems like an "Auto" button for Tone Compression would be useful. Simply look for the maximum value in the image and set the slider value so that all information is included in the result without any clipping. The first thing James does in every video is find this value manually, and then start from there. So if a button could do that work for us, that would save some time. I know it's too late for this release, and my apologies for just dumping all this in one solid block, but I hope it's still going to be helpful for future development.
 
Again, congratulations on entering the RC phase and thank you all for your hard work!

Photoshop has traditionally had the Select > Color Range command. There is also HSL keying inside the Hue/Saturation adjustment toolset, which, annoyingly cannot be used to create selections for use with other commands without clumsy workarounds (that I know much better than I would care to admit). 
 
What I am hoping to see is a non-destructive way to do masking based on luminance, HSL tools, as well as possibly more sophisticated keying algorithms that are found in video software (Primatte, Keylight, etc.). Most video-focussed color correction software (DaVinci Resolve, Speedgrade, Lustre, Baselight, FilmMaster, Assimilate Scratch) allows for non-destructive HSL keying already.
 
The most elegant way I can imagine this working inside Photo is that similar to regular layer masks, a new procedural mask layer type for non-destructive HSL/Select Color Range masks with adjustable parameters would be available. Like an adjustment layer, except that the result would be a mask instead of an RGBA image, to be used just like regular layer masks.
 
That way, it would be easy to adjust the selection parameters interactively after the fact, and, if need be, rasterize destructively to a regular raster mask layer. In additions to the keying in Luma, RGB, HSL, YUV and LAB, parameters for blurring the result, expanding/contracting the mask would be useful. The exact same functionality could then double as a vastly improved "Select Color Range" command as well.