LUT Presets and the size of adjustments.propcol

[David in Яuislip]

Playing with LUTS introduced via an LUT Adjustment layer then added as Presets so they appear in the Adjustment/ LUT panel

1) There seems to be an issue with LUTS containing remarks in that the data are not deleted from adjustments.propcol after the preset is removed from Photo

2) LUT tables are overwritten with FF and the file size doesn't properly reduce when a preset is removed

What I did:
File sizes below relate to adjustments.propcol in C:\Users\DavidinЯuislip\AppData\Roaming\Affinity\Photo\1.0\user

1.65 MB (1,740,756 bytes) originally created in 1.8.3 before the 1.8.4 update

3.32 MB (3,483,348 bytes) 2 LUTS added

2.72 MB (2,855,872 bytes) both LUTS removed. Teal header and table is still there in hex editor view, gone from Adjustments/ LUT in Photo

FG_CineTeal&Orange1.cube file header
=====================================(not in file merely a delimiter)
#Generated with IWLTBAP LUT Generator
#Website: http://luts.iwltbap.com
TITLE "FG_CineTeal&Orange1"

#LUT size
LUT_3D_SIZE 25

#LUT data points
0.066667 0.109804 0.125490 etc
=====================================

so I removed the comments and line breaks thus:
=====================================
TITLE "FG_CineTeal&Orange1nonotes"
LUT_3D_SIZE 25
0.066667 0.109804 0.125490 etc
=====================================
and renamed it NoNotes

3.32 MB (3,486,824 bytes) - added NoNotes

3.52 MB (3,694,712 bytes) - removed NoNotes. It's gone from the hex view but the file is larger

Reset by copying adjustments.propcol from C:\Program Files\Affinity\Photo\Resources\Affinity Photo to user

1.42 MB (1,493,679 bytes)

2.69 MB (2,826,618 bytes) 2 LUTS added. New adjustments.propcol created, original renamed to adjustments.propcol_backup1

K_TONE_Vintage_KODACHROME.cube 880 KB (901,585 bytes)
FG_CineTeal&Orange1nonotes.cube 412 KB (421,925 bytes) both freely available on the www

1493679 + 901585 + 421925 = 2,817,189 - ok

2.69 MB (2,824,747 bytes) both LUTS removed. LUT tables gone but now lots of FF empty spaces in hex view

?

[walt.farrell]

For your point 2, if the .propcol files work like some other Affinity files work, they maintain their sizes when data is deleted in order to enable efficient processing, and are only rewritten and compatcted when a large enough space reduction will occur.

[David in Яuislip]

Makes no sense to me Walt, when stuff is removed from adjustments then the file should be rewritten properly. Leaving FF padding spaces is an error no matter how you look at it.  I could add even more LUTS then remove them and I suspect that the file would keep growing in size which I suspect would increase the program loading time but that's a job for the Devs not me.

[walt.farrell]

49 minutes ago, David in Яuislip said:

Leaving FF padding spaces is an error no matter how you look at it. 

Not if it's intentionally done for performance reasons.

 

50 minutes ago, David in Яuislip said:

and I suspect that the file would keep growing in size

And I suspect that at some point there would be enough "gas" space in the file that Affinity Photo will rewrite it and compact it down to the needed size. But that's only a guess, and not something I feel like experimenting with. That is, however, the way that .afphoto, .afdesign, and .afpub files work. And it's quite easy for me to believe that the other proprietary format files used by Affinity work the same way.

[David in Яuislip]

37 minutes ago, walt.farrell said:

1 hour ago, David in Яuislip said:

Leaving FF padding spaces is an error no matter how you look at it. 

Not if it's intentionally done for performance reasons.

There is no perfomance gain associated with a bloated file. It takes longer to read from disc and longer to parse

1 hour ago, David in Яuislip said:

and I suspect that the file would keep growing in size

And I suspect that at some point there would be enough "gas" space in the file that Affinity Photo will rewrite it and compact it down to the needed size. But that's only a guess, and not something I feel like experimenting with. That is, however, the way that .afphoto, .afdesign, and .afpub files work. And it's quite easy for me to believe that the other proprietary format files used by Affinity work the same way.

The 'gas' shouldn't be there. I suspect that Serif has missed a trick, there is no point in converting a straight ascii LUT into a binary file if the maintenance turns into a problem. Regarding .afphoto file sizes they seem to be huge compared with the basic image size within so heavens knows what it contains.

cf Adobe tiff format, a piece of genius then developed into .psd

 

[Chris B]

Thanks David in Яuislip,

I've read through this a few times and will ask a dev to see if they'd like to investigate.