RobWu

If this is really the case, this a major issue. E V E R Y  application can work just fine with files from a external location.
I never had any issues working from my Windows Server with Affinity, but if this is really the case I might just stop using Affinity software until this madness is fixed.

What is this? the 90's????

If this is really the case, this a major issue. E V E R Y  application can work just fine with files from a external location.
I never had any issues working from my Windows Server with Affinity, but if this is really the case I might just stop using Affinity software until this madness is fixed.

What is this? the 90's????

@Chris B

Had a little bit of time to play around with settings and try to consistently see what AP is doing.
Again, let me start by saying we work with large 35K, 32 bit pano's. File size is appr. 7,5Gb per pano.  Also still using AP 1.9.2 due to 'reasons'.
I tweaked the performance settings a bit by upping the RAM usage for AP to 24Gb, and limiting the undo's to 24 before some tests.

- Opening a 35K pano isn't much of an issue, it just takes a while for AP to load it. You can see the progress slowly getting to 100% in the 'percentage ticker'.
- RAM or VRAM at this point isn't taxed at all.
VRAM is roughly holding on 2 Gb, and RAM used for loading the pano is slightly over 4 Gb. Now totaling appr. 8,6 Gb of RAM for the system.

- Now I add the live projection to the pano layer, and the RAM usage shoots up with appr. 20 Gb to almost 29 Gb. Rotating the pano around will add another couple of hundreds Mb's of RAM.
- So I end up with appr. 30 Gb of RAM in total used by the system.
Some paint actions might add add another few hundred Mb's of RAM to the mix. (RAM in the system is 64 Gb btw.)

- When done with editing, I release the Live projection, which also takes a while. Sometimes AP crashes on this.
Strange thing is the RAM usage after the projection release is way higher than before the projection. Often hovering around 20 Gb compared to 8,6 Gb.

- And after closing the pano, not all of this RAM is released.
AP often 'sticks to' the RAM usage, slowly going up and down a couple of hundred Mb's.
Or AP releases some, but 'sticks' to something around 16 Gb of RAM while not closed. So 'hoarding' over 11 Gb of RAM before we loaded the pano.
At this point AP will often crash when you close it. RAM will be released after a successful closing of AP. Or crash

I did this several times, and RAM usage and AP behavior is similar every time. Hope it helps.

rob

@Chris B

Had a little bit of time to play around with settings and try to consistently see what AP is doing.
Again, let me start by saying we work with large 35K, 32 bit pano's. File size is appr. 7,5Gb per pano.  Also still using AP 1.9.2 due to 'reasons'.
I tweaked the performance settings a bit by upping the RAM usage for AP to 24Gb, and limiting the undo's to 24 before some tests.

- Opening a 35K pano isn't much of an issue, it just takes a while for AP to load it. You can see the progress slowly getting to 100% in the 'percentage ticker'.
- RAM or VRAM at this point isn't taxed at all.
VRAM is roughly holding on 2 Gb, and RAM used for loading the pano is slightly over 4 Gb. Now totaling appr. 8,6 Gb of RAM for the system.

- Now I add the live projection to the pano layer, and the RAM usage shoots up with appr. 20 Gb to almost 29 Gb. Rotating the pano around will add another couple of hundreds Mb's of RAM.
- So I end up with appr. 30 Gb of RAM in total used by the system.
Some paint actions might add add another few hundred Mb's of RAM to the mix. (RAM in the system is 64 Gb btw.)

- When done with editing, I release the Live projection, which also takes a while. Sometimes AP crashes on this.
Strange thing is the RAM usage after the projection release is way higher than before the projection. Often hovering around 20 Gb compared to 8,6 Gb.

- And after closing the pano, not all of this RAM is released.
AP often 'sticks to' the RAM usage, slowly going up and down a couple of hundred Mb's.
Or AP releases some, but 'sticks' to something around 16 Gb of RAM while not closed. So 'hoarding' over 11 Gb of RAM before we loaded the pano.
At this point AP will often crash when you close it. RAM will be released after a successful closing of AP. Or crash

I did this several times, and RAM usage and AP behavior is similar every time. Hope it helps.

rob

Graphic cards..
One of the PC's still has an oldie GTX970, but that performs well for other software
The other one(s) I have to ask around, we're not all on the same location and I'm the tech head of the bunch...
Ah... Have to add we're doing 32 bit, full float 35K HDR panos. Not sure how that changes the equation...

We see this on various PC's, ranging from somewhat 'older' CPU's to the one year old setup. RAM is always 32-64GB, and VRAM is always 4GB+
We use dedicated disks for temp data where ever possible with lots of space to fill.
Looking at the Task Manager, we never tax the RAM of VRAM.

Unfortunately this project cannot be shared due to NDA's. I have to see if we can share a similar image for testing.
 

Tom,

https://affinity.serif.com/tutorials/publisher/desktop/
But if you start the application there's a image link too in the popup window.

And a question to the devs:
I understand this is beta, but will the file format change before the final?
I would like to start fiddling with this, but not have to redo all the work later on

cheers!

rob
 
p.s. Watched the videos, love the app already

Congrats to all of you! Well deserved, for the Store app and desktop applications.

Next year, another Ninja Cat for Affinity Publisher

Missed this one for some reason...

I'll just wait a bit longer to see if, and when Publisher is emerging from the alpha depths. ;-)
 
 
rob