bvz

Sorry for the delay getting back. I was out of the office sick for a few days. One thing that occurs to me is that our entire pipeline is Linux based, so the ocio profile has Linux style paths in it. I rebuilt this file to have a windows style path in it, and also rebuilt it to use windows style line endings, but all still to no avail. I tried the adjustment layer, also without any luck. I suspect the issue is somewhere in the formatting of the file and the fact that it is designed for our Linux based pipeline. I'd like to send you our config file, but I'm not sure I am allowed to publish it publicly (can't image why not, but just to be safe I'd rather not). If you could supply an internal link I would appreciate it. Thanks!

Hello, I am trying to switch to Affinity Photo from Photoshop (for a number of reasons, but OCIO support is the primary motivator at the moment). I have gone into my (Windows) preferences and selected the Color tab. Under OCIO I have selected the same OCIO config file that the rest of our pipeline currently uses successfully. Note: This is a config that we successfully use for every other application, so it is a valid config. I have also tried a number of other config files that we use on a regular basis. I have restarted Affinity Photo and then re-checked the preferences. It correctly shows this OCIO config file as being the one that is loaded. I have opened an EXR file, and checked its info. It shows RGBA/32 (HDR) - sRGB IEC61966-2.1 (Linear). When I go to the 32-bit Preview panel, it is currently set to ICC Display Transform. Here is where I get lost. The OCIO Display Transform is grayed out. I can't seem to get it to be active no matter what I do. I need to see my image under the correct OCIO LUT. How do I get OCIO to activate for this image? Is there some specific feature of OCIO that is unique to Affinity that I need to implement? Thanks for any and all help!

Or is it "swim against the current?" Actually, it is all three: https://idioms.thefreedictionary.com/swim+against+the+current I have also used all three OS's and then some. My first days doing this work was on SGI onyx and onyx2 before moving on to the Irix and O2. I still have my old O2 case that holds my thermos now. I can't make myself use the motif theme though. I hated it back in the day and I hate it even more now. I am not absolutely against Windows (and we are certainly drifting off topic now, but this is fun ). The issue for me is that our entire pipeline is *nix based. Every last bit of it. That includes the applications that we use that, even if they are generally cross platform, the 3D performance is best under Linux because of their better OpenGL stack. But more importantly it also includes a ton of custom written "glue" that makes the pipeline work. Nearly all of that is in python, QT, C, C++, with a bunch of bash, tcsh, and even a smattering of perl scripts for good measure. This pipeline is nearly 25 years old now and while rickety at times, has been worn pretty smooth such that we can turn large projects around in fairly short order. We can barely make parts of it work under OSX. It breaks completely in Windows. At home I dual boot Windows on my XPS laptop because why wouldn't I? I rarely do it because I rarely need Windows (and I have a Mac Mini for those times that Linux doesn't cut it - and WTF is up with Linux and battery life? Sheesh). But everyone needs to find their own best workflow. If I didn't have all this daily exposure to our Linux workflow, I would probably find running Linux at home to be less than ideal. In fact, even now, if Apple weren't such a crap company when it comes to high end computing, I would drop Linux in a heartbeat for OSX. But since nearly all of my work goes through a Linux pipe at work, I find it much easier to maintain some sort of continuity at home. If it weren't for that I might switch to Windows for my freelance as well. I still don't like it because I am really really much happier with the scripting and file system integration that I have under Linux, but it isn't a make or break thing for me. Ultimately I understand why Affinity targets Mac and Windows first. I would never suggest that they don't, nor would I suggest that anyone else should go Linux first. But I am completely willing to say that we are nearly a Linux only shop (of about 150 people, but only a fraction of whom actually use Photoshop) that would adopt a Linux version of Affinity in a heartbeat because it would mean that we could: A) Drop Adobe and their asinine color management in favor of OpenColorIO. Also, have you ever talked to Adobe's lead color engineer? I'm not going to name him, but if you have ever dealt with him, you will know what I mean. That is a reason to abandon Adobe in and of itself. B) Drop Adobe and their asinine subscription only model (we haven't upgraded past CS6 specifically for this reason) C) Drop our secondary windows machines which only get used when we are in Photoshop D) Drop Adobe because, c'mon. I know we can already do A,C, and D now on our windows machines, but it is nearly impossible to get an artist to switch tools absent some external pressure. Having only a single, Linux box would be the impetus to make the changes. I'm not holding my breath. I just wanted to state my preference.

That is very good news for you then. I'm happy that you get to use your preferred app on your preferred OS.

I have no way to officially say one way or another, but I would highly doubt it. From what I understand, Affinity uses hardware acceleration for their apps. From what I read on another thread here about Linux they indicated that it was fairly unlikely to work (or, at least, work well). I'm 100% with you on the wanting to completely ditch Windows, but for now I don't think you can do that and still use Affinity products. Edit: A minor correction: You can ditch Windows and still use Affinity products if you use a Mac. That is what I do at home. Two Linux machines (my primary desktop is a 12 core, 24 thread machine with 72GB RAM running CentOS and my mobile machine is a Dell XPS-15 running Ubuntu), and an old Mac Mini (2012 i5 with 16GB RAM) because I used to be all OSX all the time (before Apple completely insulted its "pro" clientele with their "pro" machines) and I still need one consumer friendly machine to run the SW that I bought over the years that doesn't work under Linux - SW like Affinity.

One more vote for a Linux version. (I know I know... Affinity is not considering it. But I would like to make my opinion heard regardless). I would buy it. So would my company. We do 3D content creation using nearly 100% Linux machines. We have a few Windows machines in order to run Photoshop, but the combination of Adobe's terribly incompatible color management and Windows 10 being the weird, only partially supported OS in our pipeline makes me want to tear my own hair out. We also have Affinity running on a few of these machines and I really like it. That said, with PS available, it is hard to pressure our artists into switching. The one thing that would make them switch would be the ability to work exclusively on their Linux boxes. I've read some of the comments on this thread (but nowhere nearly all of them) and I want to point out that we are sticking with Linux because that is the best OS for all of our other content creation software as well as all of the common, custom pipeline work we have done. Zealotry has nothing to do with it. For our purposes, Linux is simply faster, more reliable, more of an industry standard, and offers us the tools we need to get our work done more so than Windows or MacOS (though MacOS would be the next most logical choice if they would just up their OpenGL game). Affinity (or Photoshop) are tiny pulls in the direction of non-Linux systems that are swamped by the pulls from our other tools that run much better under Linux. Affinity running under Linux (snap package? flatpak?) would make me incredibly happy. Affinity with a python scripting language would make me break down in tears of joy.

Yay on scripting! Major bummer on the language choice for us though. In vfx everything is done in python (and JavaScript isn't used at all), so none of our libraries will work... which will significantly limit the usability of the scripting language for us. But I'll take what I can get! If ever there was a notion to allow multiple scripting languages, we would almost drop dead with excitement if you included python in the future. And if you allowed python AND ran on Linux... well now. That would be a day to rejoice.

Thanks for the quick answer. I think that when I get back to my computer after the holidays (I am getting 10 well earned days away from computers) I will try to put together a document that does exactly what I am looking for. I will maybe make a posting here with the things that I come up with and maybe others can chime in as well.

I just purchased Affinity Photo and I am excited to get started. That said, there are enough differences between it and Photoshop that I quite quickly get stymied. That isn't really a problem in and of itself as any new software carries a learning curve with it. That said, it would be very helpful if someone could put together an "Affinity Photo for Photoshop Users" video or document. It would have to be very very quick - i.e. I don't need to learn what an adjustment layer is, or how photo editing works. What I need to know is where my color swatch palette is located, and how I go about selecting a color when painting (holding option in the brush tool doesn't seem to work). Just a quick mapping between "In Photoshop you do this common thing this way, in Affinity Photo you do it this slightly different way." I tried to watch the tutorial videos but they are very very long when all I am trying to do is get an overview of the UI (I already know about the fundamentals underlying photo editing). The key here is quick. Just two or three sentences for each mapping. Of course I will figure this out eventually on my own, but when I am on a deadline (which is almost all the time) taking time to learn really really basic UI things makes me jump right back to Photoshop to finish my work. Having this rosetta-stone-like document could ease that transition. So... is there something like that out there? Is that something that the Affinity team could whip up?

OpenColorIO! Native EXR handling! This is going to go down so huge at my company! I can't wait to tell them tomorrow. We are in perpetual icc hell trying to match our OpenColorIO profiles. And we haven't upgraded our Adobe software in a couple of years because of nasty license restrictions. This is fantastic news. You guys rock and I am heading over to the Mac store to buy a personal copy right now.

That would be awesome. Right now we have to create ICC profiles that kind of match our OCIO profiles and it is a twitchy and unreliable approximation at best.

Anyone? Beuller? Beuller? sigh. We are such a tiny market. :)

I suspect that our workflow is a fair bit different than many others here. We mostly do 3D animation and would use Affinity Photo to generate maps for 3D assets as well as projected matte painting style imagery that gets rendered in Renderman or Nuke. So for us one possible use of scripting would involve separating out layers based on a bunch of different and dynamic inputs and generating new images from them. For example, on a multi-layer image we might want to select entire grouped layers based on name, duplicate them and apply different filters and color work to create black and white, gamma'ed versions. In many cases we would like to also extract their transparencies and convert those to alpha channels while un-premultiplying the color channel, and then saving the images to different locations on the network based on the name of the groups in question. A separate use case is tying the tool into our asset management system and show environments so that the file open and close dialogs can be replaced with ones that know about our directory structures and automatically save files with the correct naming conventions, versioning, and even automatically publishing images back to our database when an artist is done. There are tons of workflows that we would love to be able to apply (many of which we have already written for other tools using python which is why my personal preference is that language - we have a ready set of libraries that do much of the heavy lifting already - but I understand that that may be unique to us). That is a sample of what would be our use cases. That said, we haven't bothered to do all of that in Photoshop in part because we are simply too busy to do that on top of all the other applications we are customizing so, well, there's that. :) The only thing we managed to do were the custom open and close dialogs which worked for a while until PS changed some of their libraries from one version to the next and we never bothered fixing our scripts to match. Sigh.

I would also like to add my voice in favor of scripting support. My personal preference would very very strongly lean towards Python simply because it is a properly robust and feature filled programming language (vs. applescript which has some of the most confusing syntax I have ever used), but I would grudgingly accept just about any language. I suppose you could use Javascript in an effort to have some limited crossover with Adobe's software, but I doubt there would be enough reusability there to make it worth it. Maybe Swift (you gain some serious performance as well as relatively modern syntax there)? Ultimately, though, being able to write custom tools within Photo would make it an enormously useful tool in our pipeline.

Fantastic. This is one of the reasons I enjoy using software from smaller developers. There is a real passion to improve their products. Thanks.

I'd like to throw my support for a node-based workflow as well! At the very least it would be nice to reference one layer in more than one location so that any changes made to that layer propagate throughout the document. It would also allow me to paint complex layer masks. Finally, getting back on the topic of OpenEXR, I hope you would support the writing and reading of 16bit (half) EXR's. Often that is plenty of fidelity for most of the work we do, but it also reduces the image size considerably. Also, I hope you don't follow Photoshop's lead in constraining numerical values to a 0-255 range. When dealing with floating point images I really need to be able to enter floating point values (and not be forced into adjusting my images in massive .004 increments forced on me by sticking to the legacy 0-255 model that Adobe seems attached to) I am just now trying out Affinity Photo, but it seems like you guys have a seriously modern structure underneath that allows you to add to the app with fewer limitations based on an ancient code base. This also makes me hopeful that I can dump Photoshop (and their lousy subscription model) as soon as you have full 32 bit support.

Hi, I am excited that exr/floating point support is coming. One additional feature that would be extremely helpful for us would be to support open colorIO (vs. ICC profiles). In the visual effects industry, ICC profiles are hardly ever used (and can be a pain in the arse). Open ColorIO is our preferred color management and if we had the ability to natively use the same profiles that we use in Nuke, Mari, and Maya then we would be miles ahead of photoshop with its confusing and annoying color management. As its name implies, it is an open standard. I have no idea how hard it would be to switch between the two different color models, but if it is at all possible it would push Affinity Photo forward in the effects field quite a bit (coupled with your support for floating point file formats).