v_kyr

The Serif support people will usually recognize this, since they too read over the threads here in the forum. BTW and in case you didn't tried, RawTherapee does support Monochrome Cams... See the Demosaicing page on RawPedia for further infos.

If you mean with unlinking removing a connection between frames (?), just select a connection handle with the move tool, the cursor icon then changes to red connection symbol and then click on a text frame. That removes the connection. - Moving aka dragging around on a page with the move tool?

See: Straightening Images Refining Selections Generally take a look here at the tutorials ... Official Affinity Photo (Desktop) Video Tutorials

See the Publisher tutorials (Linked text frames etc.).

Ok than transfer just all what you need for a graceful showup, or if you determine that the file to load is not local and instead from a network connection fetch it first to a local temp storage and then load as much as you need from that. Either way they have to deal with this, since they seem to have NAS access, cloud drive etc. problems with reading/writing files. So they need some mechanism around that which ensures a correct file handling. I believe there are different scenarios possible to somehow overcome with the actual limited accessibility situation here. That would be something for me where I would start looking into, to (re)use some of the stuff for recovery on failures when writing across network boundaries. So that the actual state can be safely recovered in case of timeouts and failure. The point here is just to not loose the work (editing state) a user might already has done so far in the apps working memory, if the data can't be written over a network. Usually you don't want to close your document and maybe loose your last editings then due to some fail of network connectivity or an unreachable network drive. - For reading a file there shouldn't be a data lost here anyway, since either a file can be read in (loaded) or not, as far as the file isn't altered/damaged one can retry until some time interval is reached, if always timeouts do occur abort and let the user reinitiate another load file operation on demand.

Keep on doing these tutorials, with time I believe you will find the right balance for the right length of specific tutorials. Further better longer than too short, since not everybody is advanced in using the tools and newbies will for sure benefit from more detailed and descriptive representations!

File streams (as here in C++ for example) are a pretty basic still lower level way of opening a file for read/write operations. What you write there in and how that data is built up or structured depends on you. You don't have any clues of programming or? - I think you didn't understood my above suggestion at all or I didn't explained that well. I said just use a buffer Affinity's software uses a bunch of buffering everywhere in their programs. How do you think they perform read/write/copy and other operations? Nothing, you can only collect the data until that page is downloaded on your computers temp store for show up. If the connection breaks away you retry to continue where you left off. That's exactly what I sketched above for a open file mechanism over a network, I gave a suggestions for a different mechanism to ensure that the data is transferred completely and buffered before loading into the workspace memory.

It's an elite club, that's the reason why expensive. Though you can also try to DIY with cheaper equipment.

Ok it's a longer one, but hey therefore you explained a lot of things, made tryouts and shared thoughts how to make that statue in Affinity Photo a better one. So I believe it's valuable for other people to get some of those deeper insights you shown there in this tutorial. IMO good and educational valuable work!

Well it's size is shown as being 678 MB (?).

How does my web browsers download manager can re-establish a connection or resume a download from a partly disconnected web or cloud service etc., use the same technique or a similar method here. - If you open a file (local or over the net etc.) from a location you determine its size and start to read (transfer) its data, buffer the data and count the amount of bytes you've read so far, hold that in a var. If you loose the connection you will get an error and knowing that, but you also know how much data was read so far into the buffer. Now until some meaningful timeout period try to re-establish the data reading, if the connection is again there this continous data reading until all bytes are in buffer, load the buffer contents into the apps memory and free the buffer. If the connection doesn't re-establish and you get the final timeout period, inform the user that the file couldn't be read due to lost net connections.

See: affinity pen tool video

The apps have a history and crash restore mechanism at least until the crash point occurs. Further loading a file is nothing else than reading in already available data from a file via buffered streams (chunks) into the working mem. It can be (re)initiated when timeout errors occur, either on demand or automatically etc. You can also seek, remember and use positioning in streams in order to get/put (read/write) data etc. So things can be programmatic fine tuned here. - You can generally use some fitting design patterns in order to observ and get notified if certain read/write operations do fail, need to be reaccessed/restarted or recovered, in order to build up a better overall file load/save management. And? Those (memory handling/sharing etc.) are common things all software and the operating system itself always do deal with. For apps most of that is already encapsulated in reused abstraction layers/frameworks, you just have to use it and set it up in a more intelligent and foolprove manner.

Well for bitmap patterns the gradient fill tool can be slightly used for this. It's easy to do and reusable with styles here.

Probably more a bug.