rui_mac

I know that.
But it is just like a greyscale image, because the transparency mask is a set of values that goes from 0 to 255.
We should be able to use ALL paint/edit tools on a mask, just like we can, in Photoshop.

I know this method, Crabtrem.
I don't mean dodging and burning on an image.
I mean, on a mask.
For example, when I have a mask that I derived from a color channel, sometimes I need to darken or lighten some areas of the mask. And I mean, is a very specific way, not globally.
Check out this example I created sometime ago:
 
https://www.youtube.com/watch?v=W6H_8gjX-eI

My mask creation workflow (in Photoshop) requires that I use most paint/edit tools on a mask. After all, a mask is just a greyscale image.
So, why is it that the Dodge and Burn tools (two of the tools that I use more often when creating masks) don't work with masks?

Have you seen my video?
R C-R, I'm a image processing professional for more than 20 years. And I can assure you that dodging and burning a mask is A MUST for all professionals.
Don't think of a mask as simply a transparency. A mask can be used as a selection. I use masks/additional channels very, very often, because I need to create very precise selection for compositing or for color calibration.
So, I often start with a copy of a color channel or a combination of channels. Then, I have to edit that new, additional alpha channel.
To do so, I need to use ALL the arsenal of tools, adjustments, filters, etc, that I have available for a simple grayscale image. Because alpha channels/masks are just that: grayscale images.
If I can't edit an alpha channel/mask with all the tools, adjustments or filters, that will diminish the methods and techniques used by professionals.

I know this method, Crabtrem.
I don't mean dodging and burning on an image.
I mean, on a mask.
For example, when I have a mask that I derived from a color channel, sometimes I need to darken or lighten some areas of the mask. And I mean, is a very specific way, not globally.
Check out this example I created sometime ago:
 
https://www.youtube.com/watch?v=W6H_8gjX-eI

The native format is very structured, I know. And that means that is very compact when saved and also when in memory.
But, and this is a big but, if it is possible to paint or blur the alpha data, then it is possible to Dodge and Burn also.
If the alpha was stored in such a way that it was not possible to darken or lighten the values (in fact, dodging and burning are simply the increasing or decreasing of the values), then it would not be possible to paint on alpha too.

CMYK images are a set of four greyscale channels, each one defining the amount of Cyan, Magenta, Yellow and Black ink.
Internally, there is no difference in the way they are stored.
So, a greyscale image is a list of values.
An RGB image is a set of three list of values.
A CMYK image is a set of four lists of values.
And an alpha is a list of values, just like a greyscale image. Exactly the same. Stored in the same way.
The way you interpret or use that set of values may be different, but they are all the same type of data, internally.
So, we should be able to use all tools in the same way in all of them.

Hi Elvys,
Welcome to Affinity Forums
Yes, we are listening and aware this is something that must be reviewed/fixed as soon as possible. Now that v1.7 of Photo and Designer are out as well as Publisher we should get back to regular updates/fixes soon. I'm sorry for the inconvenience this is causing you all. Thanks for your support/understanding.

This was asked before.
I include a screen capture of all the options available in the Find & Replace and Select dialog from FreeHand.
It was great to have something like this :-)

I arrived late to this thread but the subject of adding scripting abilities to the Affinity suite has started a long time ago.
I can't wait to be able to make my own scripts inside any of the Affinity apps.
And I think python is, definetelly, the best way to go.
Multiplatform, lots of libraries available, easy and fun to code, very efficient,etc.

Having coded in BASIC, assembler, C, C++, javascript and python, I think python is the best one for scripting.

I arrived late to this thread but the subject of adding scripting abilities to the Affinity suite has started a long time ago.
I can't wait to be able to make my own scripts inside any of the Affinity apps.
And I think python is, definetelly, the best way to go.
Multiplatform, lots of libraries available, easy and fun to code, very efficient,etc.

Having coded in BASIC, assembler, C, C++, javascript and python, I think python is the best one for scripting.

Hi robinp,
All I know is that we plan to implement this feature at some point, however this feature never was in the roadmap which means there's no guarantees it will be here before v2.0. Features we already implemented were simply removed from the roadmap. The remaining ones should be added before v2. I understand people are a little frustrated with the long cycle/testing phase required for v1.7. This was mostly due to the integration with the upcoming Affinity Publisher which required quite a few adjustments to the whole suite of apps (file format compatibility, Personas, linked/embedded adjustments files etc etc). Now that we are approaching its release I think things will return to the initial pace with more frequent updates/new features. Hopefully this one may be one of them.

The main reason that I don't ditch Photoshop completely is the way Affinity Photo deals with alpha channels.
It is so much more intuitive in Photoshop, since alphas are just greyscale images and you can do to them whatever you can do to a regular greyscale image.

The main reason that I don't ditch Photoshop completely is the way Affinity Photo deals with alpha channels.
It is so much more intuitive in Photoshop, since alphas are just greyscale images and you can do to them whatever you can do to a regular greyscale image.

CMYK images are a set of four greyscale channels, each one defining the amount of Cyan, Magenta, Yellow and Black ink.
Internally, there is no difference in the way they are stored.
So, a greyscale image is a list of values.
An RGB image is a set of three list of values.
A CMYK image is a set of four lists of values.
And an alpha is a list of values, just like a greyscale image. Exactly the same. Stored in the same way.
The way you interpret or use that set of values may be different, but they are all the same type of data, internally.
So, we should be able to use all tools in the same way in all of them.

-

Have you seen my video?
R C-R, I'm a image processing professional for more than 20 years. And I can assure you that dodging and burning a mask is A MUST for all professionals.
Don't think of a mask as simply a transparency. A mask can be used as a selection. I use masks/additional channels very, very often, because I need to create very precise selection for compositing or for color calibration.
So, I often start with a copy of a color channel or a combination of channels. Then, I have to edit that new, additional alpha channel.
To do so, I need to use ALL the arsenal of tools, adjustments, filters, etc, that I have available for a simple grayscale image. Because alpha channels/masks are just that: grayscale images.
If I can't edit an alpha channel/mask with all the tools, adjustments or filters, that will diminish the methods and techniques used by professionals.

The debate is silly and futile. I completely agree with rui_mac ... Masking in AP is horrible and illogical and it is the main reason many people can not switch to AP despite its many advantages and their wish to do so.
The developers are going the wrong route here anyway. They try to make some magic masks for hobby user to remove birds from sky and cars from selfies. Completely useless for serious work ... And those insulting automatic hair masking examples that can be sold only to someone who never did work on hair with low contrast relation to the background ...
The odd thing is the blur and sharpen tool work so I gather there is little technical reason for other tools not to edit it in edit mode. Should simply become a grayscale layer in this mode - that would fix it ...

If this is implemented, those layer properties must also include an anti-aliasing on/off option. I've worked with many image editors, and the only one I am aware of that offers this level of control on a per-layer basis is PhotoLine. Would be nice to have in Affinity as well.
@Steps Psenda's suggestion is not as crazy as it sounds. Pure black and white (monochrome) images, for example, should be printed at 800~1200dpi, so a document could consist of layers with varying resolutions. Unfortunately none of the Affinity products support monochrome bitmaps at this point. Another reason why a layer setting for PPI would be handy is when a lower resolution image is imported at (for example) 72ppi (based on its PPI parameter) and by quickly changing the PPI layer setting to 300ppi its size is automatically set to the exact resolution required for 300dpi print.
Some layout and image editing applications actually have this an an option for objects to simplify the workflow.

If Serif leaves APub (and AD) the way it presently works, then I agree that there ought to be both a global and individual choice in interpolations.

DPI should only affect raster effects as per ID. QXP doesn't have such a thing and always handles effects at export only (which is the best method to me).

Well, that wasn't very clear in your previous reply, was it?
APub does resample in the case of an image that is placed if that image has a higher DPI than the document set up. Why then isn't there the same option as in AD for a choice? Or is that not what that set up item in AD is for?

It only resamples them destructively when you rasterise the layers.

Hi rui_mac,
It's probably doing the same as Photo/Designer: using bilinear from the nearest mip-map when scaling down and from the source when upscaling.

Each pixel layer should have an individual interpolation parameter so that each layer could be set to Nearest Neighbour, Bilinear or Bicubic (and, if possible, more advanced methods).
This way, different interpolation modes could be defined for each layer, as its size changes, or is deformed.
Sometimes, "softer" modes are required. And, sometimes, a more "pixelated" version is required.
This should be a parameter for all pixel objects, in Designer, Photo and Publish.