Jump to content
Blokyk

Publishing informations about .afphoto and .afdesign formats

Recommended Posts

Hello ! 

Quite a few times, I find myself in a situation where being able to handle/modify .afdesign and .afphoto programmatically would have been really handy.

However, after a couple of google searches, I couldn't find any information about those formats. I've tried to decompile the AD and AP apps using decompiler such as dotPeek and dnSpy, but didn't make any progress. Analyzing the files with binwalk or strings was of no help either.

Now, I'd like to develop a tool that would generate .afdesign files based on user input, and it is impossible to do without even any basic information about this format.

Anyway, as you've probably guessed, I'm posting here to ask if we could get some information about the files formats. I know writing documentation for a piece of software instead of working on new features or patching bugs can be really boring and time-consuming, so I'm not asking you for a full-blown documentation, but at least a sufficient level of information to work with those files programmatically and maybe being able to create/modify them, that may include the different memory sections/segments, how shapes/colours/palettes/text/filters/effects/references are stored, etc...

 

I know it's probably not gonna happen, because it's too time-consuming or costs too much, but I sincerely hope that it will be a resource soon available to the community.

Thanks for reading, waiting for your reply.

 

Share this post


Link to post
Share on other sites

Hi Blokyk and Welcome to the Forums,

As the .afdesign and afphoto file formats haven't been documented, you won't find anything online.  I know as explained on this post the Dev team have no plans on documenting the format and I can't see that changing anytime soon.

Share this post


Link to post
Share on other sites
2 hours ago, stokerg said:

I know as explained on this post the Dev team have no plans on documenting the format and I can't see that changing anytime soon.

From what @Ben said in that post, it seems likely that creating problem-free Affinity 'native' format files with a third party tool would require access to "full-blown" file format documentation (or at least to most of it), & even then the tool would have to be updated or perhaps completely rewritten if the format is changed, as was recently done in the 1.7 betas & may be done again for some later version.

Also, since as I understand it, some of this info is considered proprietary trade secrets, access to it probably would require signing a NDA with Serif, so anything in the tool that might reveal any of it -- even indirectly or accidentally -- could create serious liability issues for the tool's creator, making this a risky project, particularly for an independent developer.


Affinity Photo 1.7.2, Affinity Designer 1.7.2, Affinity Publisher 1.7.2; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.2.153 & Affinity Designer 1.7.2.6 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites

Okay, well, guess I'll just abandon this project, or maybe try an open format instead...

Thanks for the link to the post @stokerg and thanks for the answers

Have a good day, bye

Share this post


Link to post
Share on other sites

As already stated, we are not going to document our file format - for all the reasons already given (many, many times).

 

You could spend a lifetime trying to reverse engineer our files.  It's not a conventional file structure, like TIFF, for example.  I would like to know why you'd need to be able to create or modify Affinity files outside of Affinity.  Is this due to inability to perform tasks in our app?  I can't imagine any other reasons for being able to create a file fully in an external app.

 


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites
25 minutes ago, Ben said:

... I would like to know why you'd need to be able to create or modify Affinity files outside of Affinity.  Is this due to inability to perform tasks in our app?  I can't imagine any other reasons for being able to create a file fully in an external app.

In the case of InDesign and QuarkXPress, they went the route of server editions. Basically a non-UI version with some extra capabilities. Obviously the file format doesn't come into play at that point.

There are a bazillion (OK, fewer than that) places on-line where a customer via the web inputs data--something as simple as wedding announcements to full-fledged publications--and the server edition constructs the file. The server-generated file is then instructed to create a PDF and that is sent to a queue. The files in the queue are then automatically pre-flighted and then scheduled to print. All done hands-off automatically. This capability via a server edition is not exposed to the user and they never know what is happening behind the scenes. 

Another for instance, some create IDML, QXML, XML, Tagged Text, etc., which at least need to know the interchange file format. This moot in the present case of Affinity applications there is no secondary file format that can automate local installations.

There are other use cases, but not any that need to know the native file format as far as I know of. And I would suspect Serif will not be building a server version, either...

Share this post


Link to post
Share on other sites
34 minutes ago, Ben said:

I can't imagine any other reasons for being able to create a file fully in an external app.

Well can you imagine why Affinity apps create PSD files outside of Adobe Photoshop?


☛ Affinity Designer 1.7.1 ◆ Affinity Photo 1.7.1 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
53 minutes ago, Ben said:

I would like to know why you'd need to be able to create or modify Affinity files outside of Affinity.

Not the same thing, but as you know quite a few users would like the Affinity apps to support some kind of scripting language, which would make it possible to do things 'inside' the apps programmatically that we cannot (or not easily) do currently, for example to use script variables & conditionals to (re)name layers.

IIRC, at one time one of the developers said that scripting might be added to some future version, probably in version 2 or in a later paid upgrade. If that is still a possibly for the future, maybe that would satisfy the OP's needs?


Affinity Photo 1.7.2, Affinity Designer 1.7.2, Affinity Publisher 1.7.2; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.2.153 & Affinity Designer 1.7.2.6 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites

Sorry for the late response, was at work.

So, @Ben, to answer your question, I'd like to create an app that can create .afdesign files based on source code (for now HTML and CSS, but I planned on adding other languages later). And yes, as @R C-R pointed out, a sort of scripting language inside the affinity apps, if developed by the community, would require a "standard" file format (unlike now, as I understand). 

Thanks anyway, bye

Share this post


Link to post
Share on other sites
15 minutes ago, Blokyk said:

...sort of scripting language inside the affinity apps, if developed by the community, would require a "standard" file format (unlike now, as I understand). ...

No. JavaScript or whatever language Serif uses does not need to know the file format, just the methods, etc., to create or manipulate objects.

Share this post


Link to post
Share on other sites

If it directly inside the app, you're right, it doesn't need to, but if it's external, you will need to know the file format to be able to manipulate it

Share this post


Link to post
Share on other sites
3 minutes ago, Blokyk said:

If it directly inside the app, you're right, it doesn't need to, but if it's external, you will need to know the file format to be able to manipulate it

Unless Serif uses PERL or another higher-level scripting language, I cannot imagine being able to create/manipulate an AD file. But, for instance, I can use VBA under Windows to create a CD file, add items to it and manipulate them, but the file format itself is not known, just the methods, etc., to do those things.

Share this post


Link to post
Share on other sites
54 minutes ago, Blokyk said:

If it directly inside the app, you're right, it doesn't need to, but if it's external, you will need to know the file format to be able to manipulate it

No not necessarily, even then all you would need is just a library which offers to reuse apropriate functions/methods to create, add, reorder or remove contents etc. and only to open/write the reulting files. Usually you don't need deeper information of the file format internals, this can be still encapsulated in a lib in the same manner as currently for the apps themself.

 


☛ Affinity Designer 1.7.1 ◆ Affinity Photo 1.7.1 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
53 minutes ago, MikeW said:

Unless Serif uses PERL or another higher-level scripting language, I cannot imagine being able to create/manipulate an AD file. But, for instance, I can use VBA under Windows to create a CD file, add items to it and manipulate them, but the file format itself is not known, just the methods, etc., to do those things.

I can imaging a bunch of things here, there are many possibilities. It's pretty much the same as it's common usage to use certain system or third party programming libs to open/save certain bitmap/vector based files etc. The programming language usually doesn't play any role here, it can be done and offered for whatever language.


☛ Affinity Designer 1.7.1 ◆ Affinity Photo 1.7.1 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Yeah, we would need an API, but if Serif doesn't want to create/develop/expose it, the community would need to know the file format's specifications if it wanted to create a library. However, we're getting kinda off-topic here and we're running in circles anyway.

Share this post


Link to post
Share on other sites
5 minutes ago, Blokyk said:

Yeah, we would need an API, but if Serif doesn't want to create/develop/expose it, the community would need to know the file format's specifications if it wanted to create a library. However, we're getting kinda off-topic here and we're running in circles anyway.

Serif will provide an API at some point in time. Scripting means nothing without it. They have communicated scripting will come.

Share this post


Link to post
Share on other sites
19 hours ago, MikeW said:

In the case of InDesign and QuarkXPress, they went the route of server editions. Basically a non-UI version with some extra capabilities. Obviously the file format doesn't come into play at that point.

There are a bazillion (OK, fewer than that) places on-line where a customer via the web inputs data--something as simple as wedding announcements to full-fledged publications--and the server edition constructs the file. The server-generated file is then instructed to create a PDF and that is sent to a queue. The files in the queue are then automatically pre-flighted and then scheduled to print. All done hands-off automatically. This capability via a server edition is not exposed to the user and they never know what is happening behind the scenes. 

That is fine, but to produce a "server edition" wouldn't be down to a third party - and if we were to ever consider such a thing it still would not require us to expose or document our file format.


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites
19 hours ago, v_kyr said:

Well can you imagine why Affinity apps create PSD files outside of Adobe Photoshop?

I can - and I know, and have stated a million times, that while any app can load/save PSD files, the experience will never be the same as if using Photoshop - the native application for PSD.

 

The crucial thing is that we offer import and export - we do NOT offer save and load of PSD.  The difference is VERY significant.  Show me one single application other than Photoshop that creates and manipulates a *perfect* PSD file.  There is not one!

 As the person who has spent YEARS working on PSD import/export - I feel quite qualified to make comment on this.

 

The same would be true for anyone trying to replicate our file format.  I could document the data structures, but the complexity does not end there.  Related pieces of data need to correlate. There's other higher level logic that is imposed by our code base that goes beyond just the data structures.  All these rules would also need to be documented.  In the end, you'd have to replicate our code base.  What would be the point!?

 


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites
17 hours ago, Blokyk said:

Sorry for the late response, was at work.

So, @Ben, to answer your question, I'd like to create an app that can create .afdesign files based on source code (for now HTML and CSS, but I planned on adding other languages later). And yes, as @R C-R pointed out, a sort of scripting language inside the affinity apps, if developed by the community, would require a "standard" file format (unlike now, as I understand). 

Thanks anyway, bye

Seriously - our file format is far from trivial.  We've not used conventional structures - we needed to think about scalability and speed, not simplicity of the data format.


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites
1 hour ago, Ben said:

That is fine, but to produce a "server edition" wouldn't be down to a third party - and if we were to ever consider such a thing it still would not require us to expose or document our file format.

I don't believe I even implied as much. Of course it would be Serif creating a server edition if it ever happened. 

Share this post


Link to post
Share on other sites

But, we are talking about external apps manipulating Affinity files.  You replied to my comment on that.

 


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites
11 minutes ago, Ben said:

But, we are talking about external apps manipulating Affinity files.  You replied to my comment on that.

Going through a server version is using an external application. It is outside of but manipulates the server edition. The outside code then programatically instructs the server edition to spit out whatever it is instructed to do. It is simply an automated means to an end. It doesn't require knowing the file format. 

Look, Ben, I don't have a dog in this fight. I don't give a flying f**k whether Serif ever ventures down such a road--other than I think Serif would be foolish to do so. As a casual user of Affinity applications, all I really care about is that Serif would actually make Affinity applications work right, to be more efficient, to actually make them professional applications (and at that, I am thinking print work-flows).

Good luck. I'll leave you to your defensive self.

Share this post


Link to post
Share on other sites
4 hours ago, Ben said:

I can - and I know, and have stated a million times, that while any app can load/save PSD files, the experience will never be the same as if using Photoshop - the native application for PSD.

The crucial thing is that we offer import and export - we do NOT offer save and load of PSD.  The difference is VERY significant.  Show me one single application other than Photoshop that creates and manipulates a *perfect* PSD file.  There is not one!

 As the person who has spent YEARS working on PSD import/export - I feel quite qualified to make comment on this.

Wait previously you said "...I can't imagine any other reasons for being able to create a file fully in an external app...", now you are jumped on distinguishing between parsing/saving that file format versus *perfect* native PS file format support. - Fact is more, that you can and do create PSD files, in the same manner as you do handle PDF or SVG etc. too. Otherwise the Affinity apps wouldn't support any of those file formats at all, even not via import/export aka parsing and data generation. - Even I know what you mean in detail here, the initial point isn't the difference in being *perfect*, but instead to support it in some more or less usable manner.

Quote

The same would be true for anyone trying to replicate our file format.  I could document the data structures, but the complexity does not end there.  Related pieces of data need to correlate. There's other higher level logic that is imposed by our code base that goes beyond just the data structures.  All these rules would also need to be documented.  In the end, you'd have to replicate our code base.  What would be the point!?

I don't see any need to specify/document it in detail here, since I doubt much people would even then go the stony road to write a well working parser and file generator out of the specs for it. Usually there is also no need to document it, instead you can just offer a programmers API, which allows people then to generate for Affinity apps reusable files with that. That's also probably much easier to reuse then for third party developers in order to build some supporting tools and even add some additional functionality.

Such things could be offered either as an internal API for the Affinity apps themselve (hook into), or as programmer libs for external standalone third party applications, in order to support the Affinity file format as an export to option then.


☛ Affinity Designer 1.7.1 ◆ Affinity Photo 1.7.1 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

I want to hold PSD up as a very unique case.  Firstly, it's a native format that was documented due to legal pressure.  They then (craftily) only documented the main structure but omitted descriptions for some parts or the required logic for creating what Photoshop would consider a "correctly formed" file.  You can create a file according to all the information available in the file format description document, but Photoshop will still reject it.  It is also one of the few editable formats that is documented in any way.  All other formats are end/export formats - SVG, JPEG, PNG, TIFF, PDF.  These formats were created to be cross platform/application.  They are fully documented.  They also only include finalised data and exclude editable properties. For example, the data is compressed with lossy algorithms.  Knowledge of how text was placed and ordered is omitted.  Original object hierarchies are lost.  Additional tool logic data is not present.  They are not editable formats, and they are not native to the application.


We only support PSD because it is viewed as a minimum requirement by a lot of people - who also don't really appreciate the shortcomings inherent in supporting it as a third party application.

 

As far as documenting native formats, the same is not true for Adobe's other native formats, or the native formats of a number of other main players.

 

I'll also reiterate again.  You don't CREATE a PSD file in Affinity.  You create an Affinity document, and then you EXPORT a heavily rehashed document in PSD format.  This is not the same thing at all.


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×