Why you have affinity files at all?

[Piotr Krochmal]

Seriously, why?

If you own software cannot use it for stacking? or merging?

 

[Alfred]

Seriously? If there were no native format, we wouldn’t be able to save editable adjustments, filter effects, text or vector objects.

[Piotr Krochmal]

Seriously? Yes!

Why I have to convert files from affinity to tif to make HDR stack?

[Alfred]

In that case, your thread title poses the wrong question! What you really want to know is why the HDR function doesn’t accept input in *.afphoto format, which I think is a perfectly reasonable thing to ask about.

[Piotr Krochmal]

13 minutes ago, αℓƒяє∂ said:

In that case, your thread title poses the wrong question! What you really want to know is why the HDR function doesn’t accept input in *.afphoto format, which I think is a perfectly reasonable thing to ask about.

Yes I know but It will be ignored as my question about why Affinity cannot remember my settings for HDR stacking so I have to manually uncheck noise reduction, and  slowtone mapping and check align So I'm waiting for answers from DEV! Help!

[Alfred]

29 minutes ago, Piotr Krochmal said:

It will be ignored as my question about why Affinity cannot remember my settings

There are many threads about ‘sticky’ settings for a range of functions across the Affinity apps. I want them too, but posting a topic which is ostensibly about the raison d’être of the native file format isn’t going to get you the answers that we’re waiting for.

[Piotr Krochmal]

11 hours ago, αℓƒяє∂ said:

There are many threads about ‘sticky’ settings for a range of functions across the Affinity apps. I want them too, but posting a topic which is ostensibly about the raison d’être of the native file format isn’t going to get you the answers that we’re waiting for.

Yess you are right but I stuck.

But lets back to main topic. I'm fighting with not-working alignment if files come from affinity. Affinity mess (destroy) with EXIF so TIFF from HDR stacking cannot be recognised properly by affinity and cannot be stack (EXR, TIFF, JPG all same problem). 

Maybe just Maybe if stacking affinity files will be possible it will work. But for now it is not working.

Why we cannot use functions with affinity files is unclear for me.

 

[walt.farrell]

25 minutes ago, Piotr Krochmal said:

TIFF from HDR stacking cannot be recognised properly

What do you mean by that? 

[ianrb]

I have often wondered about Affinity files; but once I understood I could save Tiff files with layers there wasn't a need to use Ap files at all. Similar can be said about On1, ACDsee, and few others I have tried . I have basically forgotten about Affinity Files --- Tiff are better than PSD for me because I can see the photo in windows 
Of course I'm use Affinity for photo editing only, so there may be reasons for the Affinity files for other jobs I don't know about so I don't care / worry about for now

[Alfred]

6 hours ago, ianrb said:

I'm using Affinity for photo editing only, so there may be reasons for the Affinity files for other jobs

TIFF is fine if you only want to preserve image layers, but what if you’ve applied adjustments that you may want to tweak later on?

[Pšenda]

9 minutes ago, αℓƒяє∂ said:

but what if you’ve applied adjustments that you may want to tweak later on?

For example Live Filters, History, Snapshots, etc. 

[firstdefence]

Every Software has their own proprietary file format, its a container (a box) that stores specific information related to the abilities and features of that app.

If you change the (box) to another file format like TIFF that has its own abilities and features and stores more generic information, this makes it readable by more apps but in order for that to happen you lose some of the abilities that an .afphoto file affords you, this isn't an affinity issue this is just the latent capabilities of the TIFF file format. Every Proprietary file format does this.

[Piotr Krochmal]

one more time, my question is why affinity have their own file format if it cannot be used in affinity. And it cannot be used for any of stacking so literally 3/4 of my work for this program.

It is very annoying as long as Affinity destroy exif data completely so exporting stacked photos in any mode photos cannot be stack together.

In my case first step HDR ->EXR or best affinity 32bit original files then few EXR or affinity files stacket to in uean mode.

So question is why affinity cannot use it own file format? If it cannot and exported files are corrupted then proprietary format is totally useless.

I've even tried to repair exif by exit tools but is  give always error.

So what will be nice if DEV's (as only them know how this program) is made a statement or explanation to clarifying this situation. I'm trying to get to point where i will not be forced to use workaround by using 3 different programs

 

[Old Bruce]

58 minutes ago, Piotr Krochmal said:

It is very annoying as long as Affinity destroy exif data completely so exporting stacked photos in any mode photos cannot be stack together.

In my case first step HDR ->EXR or best affinity 32bit original files then few EXR or affinity files stacket to in uean mode.

I will admit I am having a hard time understanding your question and your statements. 

Regarding Stacking, we can use File > Place...  to put Affinity Photo files into new layers in  a document. 

Your second statement has me thinking you wish to export the result of a High Dynamic Range to the EXR file format* and then import them into some other Stacking Mode. I can do that I can open them and I can place them in an Affinity Photo document.

Affinity Photo file format is designed for using layers and this would create serious problems in the various Stacking Modes... Panorama, HDR, Focus Merge etc. That is why we can't use them. We can put Affinity Photo files into another Affinity Photo file and work with them.

If your question is not about Stacking Affinity Photo files in Affinity Photo then I truly do not understand the problem.

*(no idea of what that is but I digress) 

[John Rostron]

Why are you saving your files in the .afphoto format in the first place? Presumably your files are developed from raw. Why not export them as 16-bit tiffs once they are developed. I think that you can ensure the exif data is saved if you select the More option in export and tick the appropriate box. You do not actually need .afphoto files in your workflow. You can do all your stacking and merging using the tiffs.

John

 

[Piotr Krochmal]

2 hours ago, John Rostron said:

Why are you saving your files in the .afphoto format in the first place? Presumably your files are developed from raw. Why not export them as 16-bit tiffs once they are developed. I think that you can ensure the exif data is saved if you select the More option in export and tick the appropriate box. You do not actually need .afphoto files in your workflow. You can do all your stacking and merging using the tiffs.

John

 

I need it as it could be only chance to stack to HDR and then Stack to "pile" with mean mode.

Besides of that, final export should be final. We are living in digital world so if you export you don't have input data. If you have two steps your data mass is growing exponentially.

for example 1.DNG from K1 is around 40MB exported 16 BIT TIFF around 206MB stacked HDR in EXR file around 400MB Final compressed TIFF (all HDR software are compressor Dynamic Range compressor so it fit in our media) around 200-220 MB. So I don't need to save 5x40MB TIFF as they can be made any time But I have to save DNG, for safety I should also save stacked file in EXR as getting to this point is most time consuming. having this file give me flexibility to easy make new compression in different style. So we landed with 5x40+400+200MB =800MB of data per picture :).

You will ask why I save those data? it is simple. I'm learning from my mistakes.  Software is changing, newer version are "better" but also differ. From time to time I need to get that old look. And I don't save. In beggining DNG, then I learned but then I skip EXR file etc.

So I think having all in one merged container is best option