GFS
-
Posts
316 -
Joined
-
Last visited
Posts posted by GFS
-
-
Thanks jhoy.
I was hoping I'd be able to quickly clear a mask
-
-
Is there any way to clear (or fill) a brush mask with a keystroke?
-
I'm currently using AFP a LOT (10 hours per day) having switched from a long time app and currently working on the post for a large book project.
I'd still like a DAM. As for AFP and AFD, I am carefully noting all the bugs I find along the way ... AFD I'm using a lot less, but dipping my toes from time to time.
-
But I've been following this thread since I was a beta tester and, frankly, waiting this long to make my choice (to wait or go elsewhere) is stretching users' dedication to the developers....
I have to say I agree. I'd like to know if they are actually working on something and to have some kind of timeframe. Choosing a DAM is not like choosing an imaging app. The time investment implications are far greater.
As for spreading their resources too thin, on too many apps ... I agree with that as well, but Serif are in business and so they want to make the best profit they can. I can't help feeling that producing the Windows version seriously slowed other development, but more than that ... each decision now has far greater implications as it has to be replicated across 3 platforms and 2 apps + perhaps a DAM and a Page Layout app.
-
Thanks for the info.
Perhaps I'm experiencing a problem with the way that AF is making gradients.
Here is a comparison from AFPhoto, AFDesigner and a very old app. I made black to white vector gradients at roughly 5000 pixels wide. I imported them into Apple Pages (which does a wonderful job of smoothing gradients) and this is what I see. Top one, inside the red line is AFPhoto. Directly beneath and pretty much aligned shows that AFDesigner is identical. Then underneath with the blurred edges is the old app one.
Pages is unable to smooth Affinity gradients, but the other one is very smooth.
-
Shannen,
in case you're looking for normal Wacom support ... it is not there yet.
You can't use your Wacom like a pen or pencil where continuous brushing builds opacity, although you can increase by pressing harder, but it's very clunky. I wish there was better support for Wacom, especially in Photo.
-
Indeed. But equally, the number of colours in a file, has nothing to do with the colour space that you have 'assigned' to that file. If your file has only black and white, then it will 'look' identical in any colour space you assign to it. You will only ever see changes in a file which you 'convert' to and from different colour spaces, if it contains colours that lie outside one or other of those spaces.
Bit depth is important for resolution independent graphics, because although they 'should' in theory be absolutely fine in 8bit, they are in fact more 'fragile'. So, if AFPhoto is performing all its internal operations in 16bit (which I expect it is) then a vector graphic output from and 8bit file, will be 16bit right up until the point at which it is rendered in 8bit and so should be okay. If, on the other hand, an 8bit document has already decided that a vector graphic is only in 8bits, then I'm concerned that at some stage during the working process, those bits are not enough. So I beg the question ... is it better to switch to 16bit, prior to output, so that you are in effect 'forcing' AFP to re-calculate the vector elements, or does in make no difference?
-
Sorry R C-R, I don't understand what you're saying. I'm asking about the point at which a resolution independent graphic is converted to a bit depth. This has nothing to do with colour profiles.
Is it calculated at the point of export, regardless of document bit depth, or is it dependent on chosen document bit depth?
-
With that, I think you have answered your own question. ;)
Well, you lost me there. :huh:
-
A color profile is more than a 'sticker.' The Cambridge in Colour article explains what happens during the color conversion process, which is quite relevant when you export the file & any gamut mismatch occurs. From the article (emphasis added):
Don't think I can explain it any more clearly ... but I'll try. You can convert or assign. These are not the same.
-
I was under the impression that working w. higher bit depths was generally a good idea because digital sensors would provide a better sampling at the higher bit depth for dark image areas. That way, detail might be brought out of shadow.
If one knows from the start that the final output will be limited, then I would suppose it doesn't hurt to work within those limits.
So far, I haven't noticed major slow downs unless I'm working w a few thousand vectors, or trying to paint w. brushes at 1500 px. But I'm not involved in production at this point, and so loosing a few minutes here and there is not crucial.
Higher bit depth at capture is essential, because you want as much data as you can get. There are differences of opinion about whether or not there is any actual difference between 12bit and 14bit raw data, but in the end ... 14bit isn't going to be worse, is it? :) There are many shenanigans involved in calculating these things too, i.e. 2+2=5.
I'm experiencing slow downs with large brushes, well, large for a pixel editor. My old imaging app can happily swish a 20,000 pixel brush back and forth across a 500Mp image ... in real time.
-
FWIW, the screen preview is neither JPEG nor PNG, both of which are file formats using compression. What you see in Affinity is an uncompressed screen render, which depending on zoom level may come from mipmaps stored in the native format file.
The difference between 8 & 16 bit for exports will depend in part on the color profile, as explained in the Cambridge in Colour article -- note in particular what it says about how the different rendering intents can & usually do make this a destructive process.
Interesting that the screen preview is uncompressed.
Regarding the Cambridge in colour article. He is simply not raising the question. You may like to take a look at an old friend's site. Joe has built colour processes at the application level in the past. He built this system for his own use, which uses icc profiles for non-destructive colour editing. As I explained previously, you can 'convert' to a colour space, or you can 'assign' a profile. A profile is essentially just a 'sticker' which says what space the file should be treated as being in. You can swap these around quite happily with no effect on the image data itself ... unless of course, the app you're using is actually converting each time ... hence why I'd like to know how AFPhoto handles this.
(Edit : for some reason the link wasn't published. Should be ok now).
-
So, it is always best to work at the highest bit depth available.
This is the question really, i.e. ... is it?
Since most of us work non-destructively these days (I have always done so) by using layers in pixel editors, nothing is actually applied to the image until you 'output' it for use somewhere. The image itself is just sitting there. All the edits are on layers and are only applied to the screen preview, which is a jpeg/png. So, since working in 16bit doubles files size and seriously slows the computing ... is there any difference in AFPhoto, to working in 8Bit (apart from the actual file itself) and then switching to 16bit prior to final output?
-
Thanks for the explanations R C-R. I've been working in digital imaging for almost 30 years and shooting digital since the 90s, so I have a reasonably good understanding of this stuff.
You raise an interesting point about colour profiles and I'd be interested to know how AFP handles them at output. FWIW, colour profiles should not be altering colour. Ideally they should simply be a 'sticker' that tells a colour profile aware application, what to do with a file. This is why they can be used in a completely non-destructive way for working with colour.
By way of demonstrating this, your Mac (used to be) delivered with a number of Applescripts which could be used for for applying icc profiles to images. Some of them will 'convert' to a specific colour space, whereas others will simply 'assign' the desired profile, without any loss of colour information, or any kind of conversion taking place.
-
Hi R C-R.
I can ask this another way. Is there any difference in AFPhoto or Designer, between vector graphics rasterised to tiff from a 16bit AFP/AFD file and/or an 8bit AFP/AFD file? Or ... if there was an option in AFP to have a 4bit file, would gradient vector graphics output from a 4bit file to an 8bit tiff, display 4bit banding? Just trying to establish at what point the calculation is made.
-
Can I add a bump to this feature request.
(2.5 years since it was on the list).
-
Are layered vector graphics in AFPhoto (and AFDesigner) calculated, internally, at the same resolution as the document settings, or are they at 16bit and if relevant ... how are they built out when saving to an 8bit file?
If the answer is that a document set to 8bit will have the vector graphics at 8bit all through the process ... then should I convert my documents to 16bit, prior to the final stage of building out to an 8bit tiff for client delivery?
-
Hi MEB.
Is it expected behaviour that Live Filters don't work correctly when nested into a Group of Adjustment Layers in this way?
-
Hi Lee D,
thanks for the pointers.
I was really asking how to maintain the transparency of the glass, but no worries ... after trying various methods, I found it can be done quite effectively using Blend Options.
(I couldn't get the masking of the biscuit crumbs quite perfect, but it's okay for the repro size. I do have a lot of trouble in AFP, with masking areas of fine detail which are being used on a different background. I wish there was a 'clean-up' tool to facilitate this).
-
MEB,
can AFDesigner invert vector masks easily?
-
-
Is there a way to group Adjustments within a vector mask, in the same way that you can with a selection mask?
In other words, can I apply a vector mask to a group of Adjustments ... or do I have to duplicate nest/embed for each Adjustment?
-
Hi MEB.
Thanks for the *complex* workaround. :)
I really feel that this should be a simple process in AFPhoto. Here is a screen-movie of how a very old app manages this.
As you can see, it is very simple to switch from a mask to a stencil and visa-versa. It is wonderfully easy to copy masks and stencils from one layer to another (with a modifier). I also show how easy it is to use *any* brush mask (the painted red ... could be any type of brushed in layer) and simply copy that brush mask onto any type of layer. NB ... the circle is a clipping mask/stencil, but the painted red one is a brush mask.
(R C-R ... thanks for the pointers. Perhaps I didn't express myself very well, but I've been working with masks and stencils for a very long time and do know and understand the difference. As you will see in the screen-movie, you can have stacked masks/stencils where the area outside/inside the mask/stencil is transparent ... pictures are easier than words. :) )
AFP- selecting multiple layers
in Pre-V2 Archive of Affinity on Desktop Questions (macOS and Windows)
Posted
Is there any way to select multiple, non-contiguous, nested (child) adjustment layers, in the same way as they can be selected when they are not nested, i.e. cmd-clicking the layer's name?
I don't really see the reasoning behind this behaviour being different when nested, but doubtless there is a reason.