aitte

The names of these filters are well-established in software, precisely because they're the names of the algorithms. It's like when you go to apply an "Unsharp Mask" or a "Gaussian Blur". You have learned what those mean, and you know that they mean the same thing regardless of what application you use. It's not "sharpness" or "blur", which would be too vague and generic.
 
Unfortunately, people are much less aware of how various scaling filters look. I mentioned the differences at the bottom of my post:
 
"And if people are interested in the difference between nearest neighbor, bilinear, bicubic and lanczos for enlarging, it's basically as follows from worst to best: Nearest neighbor = jaggy pixels (extreme aliasing), Bilinear = smooth pixels (the values are blended together; produces no ringing), Bicubic = sharper but has visible ringing, Lanczos = sharper than bicubic and rounder handling of diagonal curves than bicubic (less aliasing), similar amount of ringing." (Ringing means "halos" around contrasting edges between colors, such as at the edges of objects.)
 
I think the best thing Affinity could do is provide a graphical selection screen for beginners, with small, zoomed-in previews of each filter, all using the same test image (not the user's own image). They would then see that Nearest Neighbor = "big, ugly, square pixels; only useful for enlarging pixel art", "Bilinear" = "smoothed out pixels", "Bicubic" = sharp but has halos (ringing) around all contrasting outlines, "Lanczos" = even sharper *and* has smoother handling of diagonal curves (less aliasing/stair-stepping), and has a similar amount of ringing (halos).
 
Anyone just doing general resizing will probably always want Lanczos. Its quality is very good. If you get too much ringing, use Bilinear resizing instead and manually apply an Unsharp Mask filter with a ringing-free Radius to make it sharp again.
 
If the resize panel ever gets an "Advanced" mode, I'd also want to have access to 2-lobe, 3-lobe and 4-lobe versions of the filters so that I can choose how sharp or blurry the Lanczos resize should be.
 
I still hope the "non-separable" (Slow, 2D) version of Lanczos is removed, if indeed proven superfluous (as it was claimed by all the reference books and material I looked through): https://forum.affinity.serif.com/index.php?/topic/9378-what-is-the-difference-between-lanczos-seperable-and-non-seperable/&p=53992

It makes zero business sense to merge them. Buying both Designer and Photo is still a lot cheaper than buying ONE of Photoshop or Illustrator.
 
But to make matters worse:
* If they merge Designer and Photo then they will have to raise the price from $49 to something like $79, but that means a *lot* less of the casual users buy it. And it's still less than they would have made from 2 separate sales. So less income means they may have to fire employees and cripple product development.
* If the products merge, the GUIs become more cluttered and confusing.
* If the products merge, they will have to delete one of them from the app store, and only half of their users would get the merged upgrade - the ones from the deleted product would have to re-purchase the other one. The app store does not support license migration.
* If they had released the product "merged from day one", then they would have given a free "Photo" upgrade to every Designer user and would not have received any reward for their 5 years of hard work creating Affinity Photo. Alternatively, they could have made it a paid "Designer 2.0" update and piss off all the designer users who have been promised that their purchase includes free updates for 1-2 years to come.
* An alternative solution would have been to sell Designer and then have a $49 in-app purchases to unlock Photo, but that makes no sense either. People who only want pixel work would have to buy Designer which they don't even want. And Designers may feel cheated paying $49 for extended pixel editing power. So that option would just piss off both userbases.
* A merge would constrain all features and keyboard shortcuts in a way that makes sense for both vectors and pixels, instead of allowing each app to develop its own workflows.
 
It's horrible for business in 100% of the areas that matter. And it's not even an issue; people have happily worked with Adobe's separate software suite for decades.
 
A merge will not happen until *all* users are willing to pay $100, and to buy the software in the exact same sales volume as today.
 
The lack of a merge is not Affinity's fault. It's your fault. It's my fault. It's all of the users who would not pay a fair price if they're merged. So let's never talk about this again, and let's instead celebrate that we're getting awesome Adobe-killing software at $49 each for *perpetual* licenses and none of Adobe's monthly subscription fee bullshit. We're already getting a mindblowing deal, and we're used to working with individually specialized apps. Everything is perfect.

Not all users take advantage of the functionality of all three apps. A photographer will find no use for Publisher tools. So why to pay for them?
Having them as separate apps will help to spread app use, keep prices accessible, fill users specific needs, reduce app complexity/development and learning curve. It also allows widen/deepen the scope of the tools for each area. For example Designer can be used in graphic design, illustration, web design, UI design, typography each of these requiring specific tools/functionality. Publisher also cover several uses/workflows from print to digital publishing which also require a wide spectrum of functionality. Keeping them separate allows to develop advanced tools without bloating the apps too much.
 
Changing between them - if you need to use more than one - is also relatively easy if you use the menu command File ▸ Edit in... to switch between apps. There's no need to save/open the file first to swap the document between them. All edits/history are kept when you do it. We believe this is the best compromise between having the advantage of using all functionality from the three apps without sacrificing price, performance, learning curve, complexity that one integrated app would imply.

Deja vu...   I'm sure this conversation has been had already.... many times.  And I think Petar made exactly the same point last time... and the time before... and the time before...
 
I don't think we are going to change our strategy.  Get Adobe to give you a single all purpose app, and then come ask us again.

@MikeFromMesa: Happy to have helped a fellow AP user! I was honestly blown away when I discovered this feature. My Photoshop workflow was always slow and convoluted due to its limitations: "Take 5/whatever layers, duplicate them, merge the duplicates to 1 layer, hide the 5 originals, apply static effects to the merged layer" - and I could never edit the applied effects since they were all static, and if I wanted to tweak individual layers I had to delete the merged layer, unhide all the originals, do the edits and then repeat the whole FX process.
 
Now with Affinity Photo I just use Live FX on the group of layers, and I can even change the blend mode and opacity of the effect (avoids having to duplicate layers for FX too). It's already revolutionized the way I work. The documents I make now only consists of *actual valuable layers* and not hundreds of hidden "step by step" layers.
 
Launch day is tomorrow and I'm ecstatic, knowing that's it a total Photoshop replacement and that it will just keep getting better and better! :-D Serif are my heroes.

Try this instead of duplicating:
 
* Select the layer
* Add new Live Filter (hourglass-icon at the bottom of the layers panel) > High Pass Filter
* In the bottom right of the open window, set the Blend Mode to Soft Light or Overlay
* Now just adjust the Radius

Thanks for this information. MBd posted a message in my thread showing that my bug report is related to this one, so I am bumping yours with a backlink to my thread too:
 
https://forum.affinity.serif.com/index.php?/topic/19065-affinity-photo-puts-sensitive-data-in-png-output/

I just discovered that when I export a PDF from Designer, it creates a "title" of the page which is the file path to where I save it and this is embedded in the PDF. I can get rid of it by opening Acrobat and removing it, but that is cumbersome.
 
I don't want people seeing this information on publicly distributed PDFs.
 
I've attached a screen shot of the "Properties" panel in Acrobat which shows the title attached with the PDF when exported from Designer.

Count me among the people who haven't coded resampling filters and didn't know what "separable/non-separable" meant.
 
Here is the answer:
 
* A separable filter is one that is capable of first running in the X axis (width) and then in the Y axis (height). This means it's applied in two steps; first the image is made wider, and then it's made taller. Separable filters are faster than non-separable, because their time usage is proportional to the width (and then the height) of the image, instead of the whole area of the image.
* A non-separable filter is one that runs on both the X and Y axis at the same time. It's applied in a single step and the time usage is proportional to the whole area of the image.
 
Basically: It's a lot faster to resize an image in two steps using 1-dimensional passes (width first, then height), than to do it all in one step using a 2-dimensional pass (width and height at the same time).
 
Separable filters have to be specially written to support this two-step operation.
 
So:
 
Lanczos (non-separable) = slow
Lanczos (separable) = fast, up to 10x faster
 
PS: You guys proposing a rename to "sharp" / "sharper" don't get it. It's still the same algorithm. There's no "sharper" setting in one of them. If one of them *looks* sharper it's pure accident due to some algorithm differences between Affinity's 1-D (separable) and 2-D (non-separable) modes.
 
So I don't know what the proper solution is. A dev would have to explain why they decided to show us both options.

I've seen this topic repeatedly appear. Why not add a line to the error-window that explains that if they've updated to the latest MAS version it makes any older betas obsolete? That way they don't have to ask on the forums why the beta is "invalid" suddenly. :p I've never seen the message so maybe it already explains that. But we sure see this topic a lot...

@MEB: Cool, I didn't know about that option. It's Preferences > Tools > Tool UI Size. Putting it on Smallest is helpful.
 
What I hope for is being able to disable the tool helpers completely, but easily enable them again. Via a view-menu dropdown option, or in the "Assistant" window. And have it bound to the keyboard too. Something like Shift+Spacebar to toggle the entire square frame + all the little balls permanently on/off so that we see no guides whatsoever. I realize that newbies may accidentally hit that, though.
 
I also hope for something like this: " ctrl+drag = scale, ctrl+alt+drag = rotate, so that we can permanently work without the blue outlines. "
 
Thanks for the temporary workaround MEB. It makes the problem better at least.

I've seen this topic repeatedly appear. Why not add a line to the error-window that explains that if they've updated to the latest MAS version it makes any older betas obsolete? That way they don't have to ask on the forums why the beta is "invalid" suddenly. :p I've never seen the message so maybe it already explains that. But we sure see this topic a lot...

Hi laneallen,
I agree that the control box handles can get in the way in certain circumstances. Have you tried to reduce their size in the Preferences? Although not a solution it may help to ease things out until this can be looked at.

Hehe, check out what I just found. A dark photography theme. Imagine this with a custom Affinity background. Slick slick slick, and its responsive design works on all devices:
 
http://www.xenfocus.com/skins/aperture/index.php
 
In use:
http://xenfocus.com/demo/index.php?misc/style&style_id=17&redirect=/demo/index.php
 
Example of a thread (there's only one demo user posting, it'd be even better with lots of different avatars):
http://xenfocus.com/demo/index.php?misc/style&style_id=17&redirect=/demo/index.php%3Fthreads/this-is-the-topic-title.1/
 
And you can do tagging of threads in XenForo which seems to be the way Affinity links threads to bug reports.
 
Best of all?
https://xenforo.com/help/importing/
 
You can import all current IP.Board users, threads, tags, etc to XenForo. It can even redirect all old forum traffic to the new one (see the bottom of the last link).

The current forum isn't optimal but it's pretty good, even on mobile. Despite what you say, it has a mobile theme.
 
Discourse is very modern looking and out of the ones you list above, it is the one I'd pick. But it feels very disjointed to me. Just scroll through this example thread. I find it hard to follow who is talking to who, etc:
 
https://discourse.omnigroup.com/t/omnifocus-vs-2do/13882/

Please add an option in the assistant menu, for "show handles around selected object", to disable this.
 
And make it possible to scale/rotate objects just by hovering in the vicinity of where the ball would have been if it was visible.
 
Or better yet, something like "ctrl+drag" = scale, ctrl+alt+drag = rotate, so that we can permanently work without the blue outlines.

With all due respect to the OP, Windows users have plenty of options.
Forgive us if we're not all overflowing with sympathy. 
 
Two quotes stand out:
1. "I don't feel like paying 5x the amount the hardware is worth.."
So... your company buys gear that costs 5x what it is worth?! Wow!
I worked at a publishing company and asked the head tech why we were Mac only.
His answer: "For what we do, Macs just work better. What other reason do you want?"
 
2. "..you all develop exclusively for Mac!"
http://www.serif.com/Company/AboutUs/
 
Again, with respect, I find these sort of comments all over the web from PC users. 
Short answer; If you're a pro, you'll use the right tool for the job.
For what I do, that tool is a Mac.

Sweet thanks Andy. I have to say at first I thought this thread was a joke but once I saw your comment about git I realized that this would be really useful. I am looking into doing some web development as a side project (I am currently an embedded systems developer). Additionally @aitte, little off topic but you may want to check out https://git-lfs.github.com/we are currently considering using this to store entire software binaries in git.

Hello again guys,
 
Sorry about this - I'll be honest and just tell you that it got overlooked in the run-up to the 1.4 update to both apps..
 
Don't worry though - the beta programme will start up again soon and I'll make sure it gets done as soon as possible then :)
 
Thanks,
 
Andy.

The names of these filters are well-established in software, precisely because they're the names of the algorithms. It's like when you go to apply an "Unsharp Mask" or a "Gaussian Blur". You have learned what those mean, and you know that they mean the same thing regardless of what application you use. It's not "sharpness" or "blur", which would be too vague and generic.
 
Unfortunately, people are much less aware of how various scaling filters look. I mentioned the differences at the bottom of my post:
 
"And if people are interested in the difference between nearest neighbor, bilinear, bicubic and lanczos for enlarging, it's basically as follows from worst to best: Nearest neighbor = jaggy pixels (extreme aliasing), Bilinear = smooth pixels (the values are blended together; produces no ringing), Bicubic = sharper but has visible ringing, Lanczos = sharper than bicubic and rounder handling of diagonal curves than bicubic (less aliasing), similar amount of ringing." (Ringing means "halos" around contrasting edges between colors, such as at the edges of objects.)
 
I think the best thing Affinity could do is provide a graphical selection screen for beginners, with small, zoomed-in previews of each filter, all using the same test image (not the user's own image). They would then see that Nearest Neighbor = "big, ugly, square pixels; only useful for enlarging pixel art", "Bilinear" = "smoothed out pixels", "Bicubic" = sharp but has halos (ringing) around all contrasting outlines, "Lanczos" = even sharper *and* has smoother handling of diagonal curves (less aliasing/stair-stepping), and has a similar amount of ringing (halos).
 
Anyone just doing general resizing will probably always want Lanczos. Its quality is very good. If you get too much ringing, use Bilinear resizing instead and manually apply an Unsharp Mask filter with a ringing-free Radius to make it sharp again.
 
If the resize panel ever gets an "Advanced" mode, I'd also want to have access to 2-lobe, 3-lobe and 4-lobe versions of the filters so that I can choose how sharp or blurry the Lanczos resize should be.
 
I still hope the "non-separable" (Slow, 2D) version of Lanczos is removed, if indeed proven superfluous (as it was claimed by all the reference books and material I looked through): https://forum.affinity.serif.com/index.php?/topic/9378-what-is-the-difference-between-lanczos-seperable-and-non-seperable/&p=53992

@JDW. No... Sharpness is a separate parameter of the filter, regardless of mode...
 
You could have this:
 
Lanczos (non-separable; smooth)
Lanczos (non-separable; sharp)
Lanczos (non-separable; very sharp)
Lanczos (non-separable; extremely sharp)
Lanczos (separable; smooth)
Lanczos (separable; sharp)
Lanczos (separable; very sharp)
Lanczos (separable; extremely sharp)
  So it makes no sense to rename "non-separable" as "sharper".   I guess what the devs *could* do, is to throw away the slow non-separable version (why is it even there?!), and instead tweak the sharpness parameter of the faster separable version to provide both a smooth and a sharp version of the fast 1D implementation.   The sharpness of a Lanczos filter is defined by the number of "lobes".  
Further investigation showed that a Lanczos filter is fully separable, meaning that non-separable and separable are capable of identical output. The existence of the 10-15x slower "non-separable" mode means Affinity seem to have misimplemented Lanczos. There is no reason for the non-separable version of that filter to exist.
 
If all of this is correct, then it would be best to delete the non-separable (slow 2D version). Keep the separable (fast 1D version). Tweak the number of lobes to provide a few presets with varying sharpness, as such: http://avisynth.nl/index.php/Lanczos_lobs/taps
 
(Taps = affects the down/upscaling scale; Lobes = affects the sharpness; common values are 2 lobes = the best compromise between sharpness and low amount of ringing, and 4 lobes = more ringing but extra sharpness).
 
Why non-separable filters are slower: Upscaling in 1D only requires two 4-tap filters. Upscaling in 2D requires a single 16-tap (4*4 taps) filter, which is an order of magnitude slower. There is no reason to have a non-separable version of a Lanczos filter.

Being a software developer myself, I know that even a small thing like "not embedding massive thumbnails" can be very hard to get to when every day is filled with critical fixes and features. I see that this got (rightfully) put to the side to deal with the countless important fixes in Designer. Congrats on getting ready to ship the next Gold Master for the App Store! Could you please let us know what'll happen with vector filesizes, though? Any potential timeframe for when a fix can be investigated? Knowing even a rough estimate would be helpful. Thanks :)

Being a software developer myself, I know that even a small thing like "not embedding massive thumbnails" can be very hard to get to when every day is filled with critical fixes and features. I see that this got (rightfully) put to the side to deal with the countless important fixes in Designer. Congrats on getting ready to ship the next Gold Master for the App Store! Could you please let us know what'll happen with vector filesizes, though? Any potential timeframe for when a fix can be investigated? Knowing even a rough estimate would be helpful. Thanks :)

With this, I could design so many LSD snailshells!

@MEB:

Thanks for replying. The question wasn't about SVG though, and I see now that the post I linked you wasn't 100% clear on that and could have been interpreted as relating to SVG... Sorry :-(

The problem is the size of .afdesign files. Let's say I create a logo with *only* a few curves and layer effects. I and others have noticed that if we save it as .afdesign we get a file that is hundreds of kilobytes (seems to depend on document resolution used, and graphical complexity).
If we export it as as SVG we get just the vectors (maybe 1-2kb). That solves the filesize issue, but then we lose the ability to easily edit the file later.

Since .afdesign always adds hundreds of kilobytes of "fluff" to the filesize I suspect that it is saving an embedded Finder thumbnail jpeg?

With multiple .afdesign files stored in a Git repo (for revision tracking) it really balloons the repo filesize. Every revision of a file adds hundreds of kilobytes to the repo. I would happily skip the embedded thumbnail to make .afdesign files (with just vectors and layer FX settings) in the 1-5kb range instead.

I would love an advanced option for this, if you would consider it. There is already "File - Save history with document" to toggle undo history on/off. How about "File - Document setup - Advanced - Embed Finder document thumbnail"? If documents have no thumbnail, it would just show a default document icon for that file. For backwards compatibility with old versions of Affinity products it could embed a 1x1 pixel white jpeg, so that old Finder extensions/apps can still preview and open those files. So this is totally solvable, and I sincerely hope you will consider it.
 
Edit: PROOF! :)
Here is a document with *just* a single rectangle shape.
In one file, I set the fill to pure black and saved it as "blackrectangle.afdesign": 4,439 bytes Then I set the fill to a complex circular gradient: "gradients.afdesign": 166,142 bytes. Next, I exported them as SVG to see what happens: "blackrectangle.svg": 502 bytes. And "gradients.svg": 1,056 bytes. To think about this in context: SVG is a very verbose, text-based XML format which is extremely inefficient at saving designs, needing up to 10 bytes per vector coordinate. Meanwhile, .afdesign is a binary format with extreme efficiency. And yet the afdesign file for a black rectangle is 8.8x bigger than an SVG, and for the colored gradient rings it's 157x bigger than an SVG. This huge afdesign filesize is a problem for some of us (and a very big problem for me). Could we please disable the document preview thumbnail? It's making .afdesign filesizes massive for no worthwhile reason at all.  :( blackrectangle.afdesign
blackrectangle.svg
gradients.afdesign
gradients.svg