David in Яuislip Posted August 7, 2020 Share Posted August 7, 2020 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 ? Quote Microsoft Windows 11 Home, Intel i7-1360P 2.20 GHz, 32 GB RAM, 1TB SSD, Intel Iris Xe Affinity Photo - 24/05/20, Affinity Publisher - 06/12/20, KTM Superduke - 27/09/10 Link to comment Share on other sites More sharing options...
walt.farrell Posted August 7, 2020 Share Posted August 7, 2020 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. Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. iPad: iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1 Link to comment Share on other sites More sharing options...
David in Яuislip Posted August 7, 2020 Author Share Posted August 7, 2020 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. Quote Microsoft Windows 11 Home, Intel i7-1360P 2.20 GHz, 32 GB RAM, 1TB SSD, Intel Iris Xe Affinity Photo - 24/05/20, Affinity Publisher - 06/12/20, KTM Superduke - 27/09/10 Link to comment Share on other sites More sharing options...
walt.farrell Posted August 7, 2020 Share Posted August 7, 2020 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. Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. iPad: iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1 Link to comment Share on other sites More sharing options...
David in Яuislip Posted August 7, 2020 Author Share Posted August 7, 2020 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 Quote Microsoft Windows 11 Home, Intel i7-1360P 2.20 GHz, 32 GB RAM, 1TB SSD, Intel Iris Xe Affinity Photo - 24/05/20, Affinity Publisher - 06/12/20, KTM Superduke - 27/09/10 Link to comment Share on other sites More sharing options...
Staff Chris B Posted August 13, 2020 Staff Share Posted August 13, 2020 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. Quote How to format a bug report | Learning Resources | List of V2 FAQs | YouTube Tutorials Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.