Whenever I export this file I'm working on it always comes out super glitchy (only way I can describe it). Anyone know a fix?

[sethtvl]

Sorry if this is posted in the wrong area but I'm really having trouble with this. I believe the file size is around 26MB if that's a problem. The image I uploaded is just a screen shot of what it looks like when exported. Obviously all the glitchy and black parts should not be there. Any possible fixes? Would help me a lot!

[NotMyFault]

Hi and welcome to the forum.

Please try to deactivate hardware acceleration in Preferences >Performance.

If this doesn’t help, could you upload the file, and give more details what OS, GPU you are using?

[markw]

At this point I can only echo what NotMyFault says regarding the export issue.
But as to the work itself, I see the second entry up from the bottom says Toldeo, Ohio. Should that not also be Toledo, Ohio?

[sethtvl]

Unfortunately that didn't work. I attached the file itself in a pdf (file I need) and I also attached a ss of the performance settings, you can see the gpu there. Using Windows btw.

schedule no filter.pdf

[sethtvl]

Forgot to mention this, Hardware Acceleration was never even on in the first place

 

[carl123]

17 minutes ago, sethtvl said:

I attached the file itself in a pdf

Can you upload the Affinity document?

If we can recreate the problem there's more chance finding out how to fix it

[sethtvl]

Sorry about that, heres the file, layers may be grouped weird, was trying different things to fix the export problem

schedule no filter.afphoto

[RichardMH]

Something weird is going on. When I Merge Visible on your file it scrambles, like your output. 

[carl123]

1 hour ago, sethtvl said:

Sorry about that, heres the file,

Good news, I can reproduce the problem

Bad news, you have some weird stuff going on with some of your pixel layers

For example, in the screenshot below, if you try to move any of the 3 highlighted layers or even rasterise them you get the glitches you see in your initial screenshot

But the problem is not just limited to those 3 layers, other pixel layers are also causing glitches.

At this point I'm not sure if the problem lies with....

1. The way you copy/create/import those various pixel layers
2. A corruption in the document (at some previous point in time, maybe?)
3. A bug in the program

Hopefully the official support staff can assist further but presently I can't see an easy fix other than to recreate a lot of the corrupt layers. But to be honest I would not trust that document and would probably start in a new one

 

[NotMyFault]

I think it is the combination of

• Enormous pixel size document (12k x 9k)
• pixel layers with masks and layer fx
• Huge pixel layers with a very small visible area (by mask)

I’ve chosen one of the layers and created a new document, giving me huge sized file, and black cutout areas / rendering artifacts.
to resolve, you would need to rasterize and trim the individual players to get rid of excess pixels. This means make a raw rectangular selection to cut of unneeded areas, rasterize and trim, the apply the detailed mask to keep reserves to play with.

I tried to use resize document on iPad, this gave me erroneous results (e.g. 1 or 2 digit pixel sizes).

[NotMyFault]

See 

 

[lacerto]

I wonder if this document just got glitchy at some point, as this seems to be a memory management related (app specific) problem so the document might have been working fine to some point, and there might be something that triggers the behavior, so there is a chance that the work could be saved "just" by removing/disabling that trigger, or simplifying the image. As such, even if the image is pretty large, I think that any modern image manipulation app should be able to handle these kinds of masked layers and effects (basically just shadows).

There does not seem to be anything wrong with individual layers and masks even if e.g. the bottom layer, when rasterized, cannot be saved without corruption. I have tested this on macOS and Windows, with and without hardware acceleration, on macOS both with Rosetta and native mode, even with software rendering, and the behavior is always the same.

The glitches (identical to ones that occur when exporting) are revealed on the two systems (Windows and macOS) that I have tested already when zooming in, as shown here (actually the first glitch is already showing at the start of the movie, the red artifact at lower right corner of the image):

 

It seems the document can be resized e.g. to 72 dpi without errors but only by using Bilinear resampling, all other methods cause the artifacts. I suppose the best method to rasterize the job if nothing else helps is to grab a screenshot at the maximum zoom state that does not show artifacts, like below (and then have it exploded to bigger size, if necessary, with something like Topaz Gigapixel):

schedule no filter.tif

[NotMyFault]

The issue is reproducible on single layers (with their masks). If you zoom out below 100%, the rendering gets wrong (blocky artefacts, mask not correct).

This happens in in case of no layer FX applied at all. Just a basic pixel layer and mask layer.

The only strange thing: most masks are far larger than required (larger than both the pixel layer and canvas).

Please note the rendering difference between navigator thumbnail (correct) vs. canvas (wrong).

When zooming >=100%, canvas gets correct again.

 

Edit: The mask layer have been rescaled (to different DPI) independently from the image layer (or vice versa). This probably explains the issue, all resample methods get confused. 

To rectify, you would need to rasterise these layers (including the mask) to regain identical DPI.

 

single layer.afphoto

[sethtvl]

Thanks for all of your responses, I didn't expect this much help lol. I'll try some of the things you guys suggested and if there's no fix, I'll just screenshot it. Thanks again!

[stokerg]

Hi @sethtvl,

First of all i'd like to say some great replies already in this thread, so thanks to everyone that has posted  

I've ran the file past our QA team and we have both stripped the file back to the pixel layer, by that i mean the layer of a baseball player in a new document without the mask and the same issue happens when zooming or rasterising/exporting.  It appears in the minimaps of the pixel layer are fine, which is why in @NotMyFaultfile it renders okay at different zoom levels.  So something has corrupted the main pixel layers themselves.  What that would be, it's very hard to say.  QA did notice you have a few layer names like paper tear(2)-standard-scale-2_00x-gigapixel.png and if thats a gigapixel image, its possible at some point this has been too much for your system to handle and corrupt the layers.

 

[NotMyFault]

during my tests, the masks having its share on the issues (nothing else), but could be repaired by a simple procedure:

• select defective mask
• use channel panel, click "create mask layer" from mask alpha.
• delete defective mask.
• job done.

I did this with a copy of one isolated layer, cannot guarantee that it will work in original file.

[JimmyJack]

I, on the other hand, took one random player:
No mask
No filter
No FX
put it in it's own document
.... and rasterized.
Yikes
(looks like it's, even after stripping it down, showing elements of the baseball stitching "background" image from the montage)

Edit: BTW, what's he swinging at?.... the ball that's past him super high on the inside?? I have to think that that's some serious action on a foul tip.... or he just got hit 🤔 🧐 😜. 

[NotMyFault]

Agree, this file is doomed.

[lacerto]

15 hours ago, NotMyFault said:

Agree, this file is doomed.

But can be "saved", either by downsampling with Bilinear (at least 72 dpi works), to get a low-res screen version, or taking a screenshot (and upsampling, if needed).

This one was created by taking a screen shot at 20% zoom level and then upsampled 4 times with Topaz Gigapixel. It of course has all the wrong fonts, and probably other problems, too, but might as a method be a useable work around (especially if the other option means more or less restarting from the scratch):

[sethtvl]

Unfortunately just had to go with the screen shot, darn corrupted file. Thanks guys for all your input!

[lacerto]

6 hours ago, sethtvl said:

Unfortunately just had to go with the screen shot, darn corrupted file.

Sorry to hear. Was it corrupt also at 20% zoom rate?

I think the corrupt parts are these seven layers, so hopefully you can fix the document just by replacing them:

[lacerto]

There were still a couple of more, the other paper tear element had a corrupt mask, too, and the pastime logos (one of which was totally corrupt). Then the image shown above by JimmyJack was itself corrupt (and not just the mask).

Try if you can continue with the one attached below. It was fixed by scaling down with bilinear to 72 dpi, then scaling up back to 300 dpi, and replacing the corrupt masks with the re-generated ones in the original high-res file. The single corrupt photo was replaced this way, too, so it has gone through less than ideal processing. I left the corrupt versions in file so the size has more than tripled.

One additional remark: the top two adjustments cause rasterization of all text (there may also be other features rasterizing some single text elements). At least on my computer creating a PDF takes a while (I think about an hour) and there is little point because everything gets rasterized this way anyway, so it is probably a good idea to just group everything and then rasterize it directly on the canvas (which takes only a few seconds) and then export the final print file.

It would be interesting to know if you exported successfully from this document during the time you were creating it to know if there was some specific point (and reason) for the file to have corrupt layers. The All Prospect Pastime logo that I fixed was so badly corrupt that this might have caused the glitch -- I have seen Affinity documents where only one corrupt layer may result in bad side effects, if not otherwise then in very long rendering times when exporting.

EDIT: Wolves.png (and other PNGs with transparency, without any external mask) might also get artifacts or incorrectly processed depending on whether you use export format that flattens transparencies (and there is a danger that the same errors happen whenever the final raster image processing happens). 

schedule no filter_fixed.afphoto

 

[carl123]

20 hours ago, lacerto said:

so it is probably a good idea to just group everything and then rasterize it directly on the canvas (which takes less than a minute) and then export the final print file.

Or flatten the document just before exporting

Note: There is still one corruption to fix

 

[lacerto]

4 hours ago, carl123 said:

Note: There is still one corruption to fix

Yes, that's in the image itself. The pixels are there but oddly the image gets cut when it is rasterized (flattened) and the kind of flag stripes replace the bottom of the image pixels.