william7

Yep. Me too. I get what you're saying and can't say I'm any different, BUT if its important enough you'll do it anyways.

I am a little confused by this, AP is completely non-destructive. Next im not sure what you mean by photo-illustration vs photography, PS and AP are Editors and lightroom is storage with some editing tacked on.

That sounds cool but I'm willing to bet devs don't see several of those as they are busy pushing 5.6mil pixels all the time.

Agreed. It really doesn't need to have any editing capabilities, and in honesty I hope it doesn't let development on that focus on handling the DAM stuff and not worry about any editing stuff which will already be in AP. even if they use the same code not worth the time. besides AP + DAM (assuming same price as other Affinity products) < lightroom so its not a big deal to force users to get AP

its not about how metal works thats a software difference, this is about a hardware difference, in the ipad the cpu and gpu use the same physcial memory. in intel they each have their own physical memory and you have to copy stuff between them so they can work on the same things then copy it back when they are done

+1

I am not arguing that python CAN'T do it, just that we shouldn't use it that way and that the performance gain is worth it, even if it's only 8% because it adds up quickly.

Agree about iPP over macbook but MattP is saying that the iPP will be faster than the MBP!

Just to check, have you clicked the little triangle in the bottom right of the icon and clicked inpainting?

But that is cool, didn't know the iPP worked like that.

I am still going to disagree with using python for plugins, you can't compile an entire python program only modules which dramatically reduces performance, In the ipad pro thread Affinity devs are talking about how it will be faster than macbook pros due to the shared memory between cpu and gpu which will allow them to access the memory from the gpu without having to move it between discrete cpu and gpu memory a process which takes much less time than compiling human readable code to bytecode. they are focused on clock cycles and the difference we're talking about here is orders of magnitude more than clock cycles. However python IS fine for scripting IE invoking actions in the programs for automation purposes.

WELL THEN. Someone needs to go give intel a piece of my mind! ... I just got a new rMBP 2015 in may.............. I can't afford an iPP too......

if you mean that it will be faster because the user is faster great, if the code is running better on an arm than on a high end intel then there is a problem (yes I know the ipad pro is very powerful and approaching macs, but it is not as fast as the mbp or desktops yet)

If your script runs using only the core python module i could believe you, however as soon as you start using other modules the configuration problems get exponentially worse. Seeing as we are talking about python in the context of images, you would appear to be making my argument for me and arguing that I should disregard it. Additionally image rendering and graphic work is probably the most intense workload most users will put their computer under with professionals spend thousands of dollars upgrading their machines to save seconds, why would you want to use a language that is inherently (orders of magnitude) slower due to the aforementioned runtime compilation?

you shouldn't have to its just a message.

Yea even if it is actually them (which I highly doubt) this is not the appropriate place to handle this.

I should clarify, I didn't say it wasn't possible to create plugins in scripting languages, only that it shouldn't be done. Especially with python which should not be used in production. Additionally scripting languages, due to their "compile during runtime" nature, are inherently slower than a native precompiled program, as well as more prone to errors due to the lack of checks before being run. Finally in the case of python, python programs are difficult to distribute due to configuration and setup that are especially difficult for users who are not tech-savy and can be equally frustrating for people who are very tech-savy ie developers, due to poor configuration and setup handling that make it hard to replicate setups and even more difficult to recognize when setup is incorrect especially remotely ie a user complaining that your program isn't working.

True but I also like the idea of bowing when my ram upgrades will no longer affect the program

Dang... my laptop only has 16gb.... :(

Was that with 8gb or 32gb ram?

Yea my guess is that if you set it up to use less than what you have or exactly it would help the program to plan its usage better, although they should have the ability to detect ram and plan that way, my guess is that it only really matters if you need it to use less than you have available in your standard workflow ex. user normally has 4 gbs of free ram but only wants affinity to use 2 gbs.

As I am not the developer I cannot guarantee this, but my thoughts are this, 64 GB is the most RAM that affinity can use the way it was programmed and thus why it appears that way. Obviously if your computer can't magically use more RAM than it has so if you set the affinity setting higher than the maximum amount of RAM you have it will just use the maximum you have.

With regard to being new to photo editing and finding the tutorials confusing, this website is pretty good at explaining the concepts of photo editing. hope it helps. http://www.cambridgeincolour.com/photo-editing-tutorials.htm

I have to disagree whole heartedly with using a scripting language for plugins. Scripting languages should be used for what they were designed for: scripting. The way I see it a plugin adds a new feature ex. a new filter on an image and needs to implemented in pre-compiled languages as it will be interacting with vital program data. A script activates functions in the application the same way a user would by clicking something in the GUI thus allowing for automation of repetitive tasks, These are two very different things and should be treated as such IMO

Glad to hear I am not the only one, although my concerns are less about the privacy as they are about other things, still valid and we came to the same conclusion. :)