How to Prevent GIF Export 'Spatter' ?

[Etheiy]

Hi there! Been using your programs for a few years now and I love them; I did all the graphics for my masters in architecture with your suite.

Anyway, I've recently started doing pixel art again, and since I own your trio, I thought I'd use Photo rather than what I used to use (the GIMP). I've had some issues in the past with my exports being blurry, which was corrected by helpful souls on this forum saying to use 'Nearest Neighbour'. Great! No more blurring. 

But now I'm having a new issue and I don't know the keywords to search for the answer.
At the moment I'm just making a pair of simple, banded gradient images. Each band is 1px. The layers are rasterised. When I zoom in prior to export, they are clearly distinct 1px colour bands.
When I export, however, to GIF (RGB 8-bit, Nearest Neighbour, colours palettised - I have tried 64 colours, 256 colours, and 'Windows' palette) for some reason there is a kind of 'spatter' effect introduced. What I mean is, where before I had neat 1px bands of seperate colours, I now have those bands but also pixel splatter and mixing between the bands (several bands also appear to have been merged into one colour, whilst in the .afphoto source file they are distinctly different colours; at least, their RGB or HSL values are different from one another; this file is 156px high and should produce a palette of 156 colours which is well within the 256 limit so I don't understand why I'm not getting a true-to-original export).
ETA: Also I am not scaling the image on export.

Also please forgive my total lack of knowledge on the proper words; I feel certain this has a term I just don't know, and I'm also half-sure this is just something I've messed up in my export settings.

Attached is the 256-palette export version, also a snip of the export settings. (ETA: Also a couple of snips; one shows how the bands look zoomed in AP and one how they look zoomed in the export.)

(I'm using Windows 10, haven't updated AP yet today, but I am on Affinity Photo 1.9.2.1035 according to my About splash ... I usually wait a week or two before I update in case of Problems as I had a stressful experience with exporting my work before a deadline a while back.)

Edited August 8, 2021 by Etheiy
More details

[MikeTO]

This isn't unexpected for GIF - do you really need to use that format? GIF is limited to 256 colours so gradients often look dithered (what you referred to as splattered).

JPEG or PNG (for online) or TIFF (for print) would provide better results.

[Etheiy]

Well, as it is to be part of a GIF animation, I would prefer to work with GIF format. 
(As I said, there are only 156 different colours used in the image, tho; it isn't a true gradient, it's a bunch of 1px lines I've tried to make look somewhat like a gradient to represent dawn in an animation I want to make)

So, wait... the 256 palette is a specific SET of colours separate to the file?
I thought the palette's colour set was from the image... Is it more like 'you can only have some or all of these predefined 256 colours, and anything outside those is remapped to suit'? Like how when I was a kid using paint on Windows 3.1 you only had maybe 28 colours and anything else was a pattern that blended two of those colours to give the overall effect of the colour you wanted (for example, purple was actually red crosses with blue around them, if I recall correctly).

If that's the case (which it seems would make sense now I think about it), is there a way to make Affinity give me a palette of only those 256 colours to work from?

[MikeTO]

10 hours ago, Etheiy said:

So, wait... the 256 palette is a specific SET of colours separate to the file?

It's a palette of 256 colours from a 24-bit colour space. Dithering is used to simulate more colours than can be stored in single image. Dithering was very popular in the eighties and nineties before 24-bit graphic cards and appropriate monitors became common.

[Fixx]

Affinity very much prefers to dither colours, even when it could optimize used colours to a palette. Thus I have found gif/png export to be quite unreliable. There seem to be no way to turn dithering off.

[iconoclast]

I made some experiments with GIF-animations many years ago with GIMP and PhotoImpact. So I'm not really an expert. As far as I know, GIF is an outdated file format (that is only still popular for nostalgists), because of its 256-colours-limitation and no blending to alpha. Today there are some alternative opportunities to create such small animations in higher quality. For example PNG-Animations. As far as I know also the new WEBP-format supports animation, but I don't know how it works and if the quality is good. For the web, many animations are made with javascript. Last but not least, also SVG supports animation. I saw a verry cool svg-animation some time ago, with rotating gears. Think it was made in Inkscape. But that might be a little more complicated, possibly with scripting. Don't really know. As I said, I'm no expert in animation. Especially I don't know how to do it with Affinity-Software.

[Etheiy]

Whilst I do appreciate attempts to suggest alternative formats, I specifically and with full knowledge of other graphic format options available (well, I don't know much about WEBP yet but it's not an available option for the end destination of these animations) have chosen to work with GIFs and wanted solutions for GIF image dithering (though, I admittedly didn't know the term at the time). 

I also didn't realise they had some kind of limited external library of colours from which the palette was taken, and assumed the palette was sampled from the colours within each image/frame, and I'm surprised at being told this as wikipedia states that "color definitions in the palette can be drawn from a color space of millions of shades (2 to the power of 24 shades, 8 bits for each primary), but the maximum number of colors a frame can use is 256" which to my understanding means that the colours should not be getting resampled unless there are more than 256 being used, and as I previously stated, there are only 156 in the image I'm showing in my example which is being dithered. That said, I can't really comprehensively imagine just how many colours 2 to the power of 24 IS. Like imagining that many beans - the human brain just ain't designed for it eh?

It would be very nice if some attention could be paid to Affinity's treatment of GIF and PNG exports in future, as I know I'm not the only person in the world still using GIFs. 
Literally every chat service I use that allows animated icons or memes uses GIFs, and most of the people I know personally who stream (admittedly, small streamers) use GIF animations for a lot of, if not all, their animated stream graphics such as alerts, as well as their channel-specific emotes. As it is, I suppose I will have to switch entirely over to using my pixel art animation program (even though it's in alpha and rather buggy at times) for these graphics from start to finish, rather than enjoying the reliability and power of AP to produce the static parts and then importing and animating them as a sprite sheet within Pyxel afterwards. That's fine! I can still do some simple mockups in Affinity, and at least I know not to dedicate too much time to working things up which I will then not be able to process later.

If anyone does have a way to prevent this dithering when exporting from AP* I would appreciate it, though. <3
* again, bearing in mind I am fully aware there cannot be more than 256 colours per image and as stated there are only 156 in my example and it is still being dithered
Thanks all :3

[iconoclast]

58 minutes ago, Etheiy said:

Whilst I do appreciate attempts to suggest alternative formats, I specifically and with full knowledge of other graphic format options available (well, I don't know much about WEBP yet but it's not an available option for the end destination of these animations) have chosen to work with GIFs and wanted solutions for GIF image dithering (though, I admittedly didn't know the term at the time). 

I also didn't realise they had some kind of limited external library of colours from which the palette was taken, and assumed the palette was sampled from the colours within each image/frame, and I'm surprised at being told this as wikipedia states that "color definitions in the palette can be drawn from a color space of millions of shades (2 to the power of 24 shades, 8 bits for each primary), but the maximum number of colors a frame can use is 256" which to my understanding means that the colours should not be getting resampled unless there are more than 256 being used, and as I previously stated, there are only 156 in the image I'm showing in my example which is being dithered.

It would be very nice if some attention could be paid to Affinity's treatment of GIF and PNG exports in future, as I know I'm not the only person in the world still using GIFs. 
Literally every chat service I use that allows animated icons or memes uses GIFs, and most of the people I know personally who stream (admittedly, small streamers) use GIF animations for a lot of, if not all, their animated stream graphics such as alerts, as well as their channel-specific emotes. As it is, I suppose I will have to switch entirely over to using my pixel art animation program (even though it's in alpha and rather buggy at times) for these graphics from start to finish, rather than enjoying the reliability and power of AP to produce the static parts and then importing and animating them as a sprite sheet within Pyxel afterwards. That's fine! I can still do some simple mockups in Affinity, and at least I know not to dedicate too much time to working things up which I will then not be able to process later.

If anyone does have a way to prevent this dithering when exporting from AP I would appreciate it, though. ❤️
Thanks all :3

It's true that the palettes for GIFs can be sampled from millions of colours (from 8 Bit RGB images as far as I know=16,7 mio colours). But in the end, the palette of the certain GIF will not be able to contain more than 256 colours. And that is not verry much, because we are not only talking about hues, but also about the varieties of saturation and brightness that normally should blend seamless into each other. If and how this works depends on the certain photo you choose. How many colours it contains, if it contains long smooth gradients (that often can't be displayed without ugly steps with so few colours) and so on. This limitation is, by the way, not specific for Affinity. It is the same in Photoshop, GIMP and other programs, if I'm not mistaken. 

Usually GIF-animations are small and short (f.e. animated icons, as you say), not to fill the whole screen. And often they are drawings. So it doesn't matter too much that there are only 256 colours in it, cause you don't really see it. By the way, I'm not sure if Affinity Photo is even able to write GIF-animations. Have you tried it?

I remember a thread about the same topic on the german GIMP Forum some years ago. It came to the same conclusion.

Edit: One annotation: You wrote that you chose the Resampling-option "Nearest Neighbour". This is the hardest and most graphic resampling method. Have you tried the others. The last three should be the smoothest.

[iconoclast]

1 hour ago, BofG said:

I was far too lazy to recreate your file with all those bands, but taking your screenshot of the file and saving that out as a gif (8bit RGB, 256 colours, nearest neighbour) produces this:

So the export format isn't the issue. Are you doing anything a bit odd with the source document? How exactly have you produced these bands of colour?

I tested it too, but I took the whole image, applied a horizontal motion blur to it and exported it as a gif. In fact I get the same spatter, no matter what Resampling-Method I choose. Must have to do with the GIF-Export, because it only happened to the samples on the left. The one on the right (enlarged by factor 3) is a JPEG. I also tested it in GIMP. The result is smoother (the right one, its a GIF). But the settings differ from Photo.

         

[Old Bruce]

Back in the day of dial up modems GIF was a useful format because you could restrict the number of colours in the palette to only the three or seven (or 23 or what ever...) that you used for your icon or picture. This meant that you didn't have to send the whole maximum 256 colours in the palette if you didn't need to. Lots of tiny files back then.

[R C-R]

On 8/8/2021 at 8:15 AM, Etheiy said:

As I said, there are only 156 different colours used in the image...

You may have drawn with only 156 colors but unless everything you drew was perfectly pixel aligned, the image will almost certainly contain many more due to antialiasing.

[Etheiy]

Yes, I am aware Affinity doesn't animate GIF; I intended to use it for the static images and then animate in a separate program (called Pyxel, but it's really new and quite buggy and simply not as nice to use for the actual drawing as Affinity - for instance its handling of swatches/palettes isn't too hot).

R C-R: I drew it with Force Pixel Alignment turned on using the Pixel tool (in the same place as the brush tool).
In a separate file, I opened up a photo of the dawn sky. I sampled about five colours and made swatches of those in my file that I wanted to be a GIF later.
Then I begin drawing each band in that to-be-a-GIF file 'by hand' using said pixel tool, and adjusting the colour of the next (by eye) to create the gradient.
Unless the tools I used don't do what they're supposed to, it should indeed be pixel aligned. It is one single pixel/raster layer. 

Well, actually, the original file has two gradients created using this method, but I have the other turned off and am only exporting one at a time, so it should only be sampling the colours in the layer which is on... I just did a test by making these into new, separate files - each with only one layer, the pixel banded layer, and it still dithers. So I think the extra hidden layer isn't having any effect.

As BofG found- a smaller version with less colour bands exports without dithering. But 156 should still be within the 256 limit so it should not be happening at all?
I tested it by making one with only 40 colours and that one doesn't dither. But, as said, there are only 156 in the original file (in fact, there may well be slighly less because some look quite similar) so it shouldn't be dithering at all, surely?

Iconoclast- I want the hard bands and edges of 'nearest neigbour' and do not want any smoothing to be done between my bands or to my intended-for-GIF work in general. I don't use nearest-neighbour setting for any other type of export (in fact, I didn't know it was there until I started exporting small GIFs from Affinity and was super unhappy at the loss of my crisp pixels - the scroll image attached below, for instance, was absolutely ruined by any other setting.. shading on the scroll is done by hand and carefully curated to give a hint at texture which is more visible in the 4x scaled version).
Also, you can make animated GIF in the GIMP, it's just a little fiddly. I seem to recall I used to have to type in the frame details for each layer and then when I exported it as GIF it would work if I did it right, but these days there's a nice wee checkbox and it'll do that part from the settings you enter on export (great- unless you want variations in the animation's disposal type or speed, in which case it's best to still do it by typing them in yourself). The GIMP isn't the first tool I ever used to make animated GIFs but it is the one I've used most (I don't actually remember what the first program I used was, as it was about 20 years ago!). But yes, the colour limit is part of the challenge/fun in creating good animated GIFs and that's not the issue here - it's that something is going wrong in an export which should be fine and within the rules.

Essentially, if anyone is vaguely interested, I'm making a set of what will be very simply animated backdrops but 'higher resolution' and this gradient is only a part of one. 
My intended process was to draw them in Affinity, then import them into my GIF animating software (Pyxel), create/tweak the animated parts therein, and then I tend to export the image with the 'pixel scale' set to 4x. So the original file (not animated yet) is the first attachment, and the second attachment is the 4x pixel scale version (again, not animated yet). I drew this particular image wholly in Pyxel (literally pixel-by-pixel, except the moon, which is from a photo massively scaled down, imported, and then tweaked) and, due to how limited the program is (very early development) it took about six hours. I'm sure I could have created this in maybe, two, if I could take advantage of AP's tools and, well, lack of crashing, tbh. :')
This image is produced at 480x270px and gets scaled up by Pyxel with the pixel scale setting, once finished, to 1920x1080px. The setting just makes the pixels bigger, and doesn't create any blurring or smoothing, which is really great. Before I got hold of this I was working in GIMP and drawing each 'pixel' at 4 myself by hand and it was a nightmare making sure everything was aligned to that imaginary 4x grid.

[iconoclast]

AES

24 minutes ago, Etheiy said:

Yes, I am aware Affinity doesn't animate GIF; I intended to use it for the static images and then animate in a separate program (called Pyxel, but it's really new and quite buggy and simply not as nice to use for the actual drawing as Affinity - for instance its handling of swatches/palettes isn't too hot).

R C-R: I drew it with Force Pixel Alignment turned on using the Pixel tool (in the same place as the brush tool).
In a separate file, I opened up a photo of the dawn sky. I sampled about five colours and made swatches of those in my file that I wanted to be a GIF later.
Then I begin drawing each band in that to-be-a-GIF file 'by hand' using said pixel tool, and adjusting the colour of the next (by eye) to create the gradient.
Unless the tools I used don't do what they're supposed to, it should indeed be pixel aligned. It is one single pixel/raster layer. 

Well, actually, the original file has two gradients created using this method, but I have the other turned off and am only exporting one at a time, so it should only be sampling the colours in the layer which is on... I just did a test by making these into new, separate files - each with only one layer, the pixel banded layer, and it still dithers. So I think the extra hidden layer isn't having any effect.

As BofG found- a smaller version with less colour bands exports without dithering. But 156 should still be within the 256 limit so it should not be happening at all?
I tested it by making one with only 40 colours and that one doesn't dither. But, as said, there are only 156 in the original file (in fact, there may well be slighly less because some look quite similar) so it shouldn't be dithering at all, surely?

Iconoclast- I want the hard bands and edges of 'nearest neigbour' and do not want any smoothing to be done between my bands or to my intended-for-GIF work in general. I don't use nearest-neighbour setting for any other type of export (in fact, I didn't know it was there until I started exporting small GIFs from Affinity and was super unhappy at the loss of my crisp pixels - the scroll image attached below, for instance, was absolutely ruined by any other setting).
Also, you can make animated GIF in the GIMP, it's just a little fiddly. I seem to recall I used to have to type in the frame details for each layer and then when I exported it as GIF it would work if I did it right, but these days there's a nice wee checkbox and it'll do that part from the settings you enter on export (great- unless you want variations in the animation's disposal type or speed, in which case it's best to still do it by typing them in yourself). The GIMP isn't the first tool I ever used to make animated GIFs but it is the one I've used most (I don't actually remember what the first program I used was, as it was about 20 years ago!). But yes, the colour limit is part of the challenge/fun in creating good animated GIFs and that's not the issue here - it's that something is going wrong in an export which should be fine and within the rules.

Essentially, if anyone is vaguely interested, I'm making a set of what will be very simply animated backdrops but 'higher resolution' and this gradient is only a part of one. 
My intended process was to draw them in Affinity, then import them into my GIF animating software (Pyxel), create/tweak the animated parts therein, and then I tend to export the image with the 'pixel scale' set to 4x. So the original file (not animated yet) is the first attachment, and the second attachment is the 4x pixel scale version (again, not animated yet). I drew this particular image wholly in Pyxel (literally pixel-by-pixel) and, due to how limited the program is (very early development) it took about six hours. I'm sure I could have created this in maybe, two, if I could take advantage of AP's tools and, well, lack of crashing, tbh. :')
This image is produced at 480x270px and gets scaled up by Pyxel with the pixel scale setting, once finished, to 1920x1080px.

Yes, as I already said in my last post, in fact the GIF-export of AfPhoto causes such odd dithering - whatever Resampling you may use. I don't know if it is intended. I don't think so. But I couldn't find a way to prevent it, except using another software for it (like GIMP f.e.). Sorry!

But what about creating the static image in AfPhoto, export them as PNG, open them in GIMP and export them as GIFs from there?

[Fixx]

PNG export uses same dithering algorithm as GIF exporter so the same artifacts persist. I would recommend using some other app for indexed colour work.

[iconoclast]

18 minutes ago, Fixx said:

PNG export uses same dithering algorithm as GIF exporter so the same artifacts persist. I would recommend using some other app for indexed colour work.

OK, that might be, don't know. But it does with a much wider range of colours. So you don't get this spatter if you export as PNG. Just tested it, and it doesn't happen.