Improved non-destructive RAW save options that don't eat disk space

[Corgi]

My present understanding of the way the embedded and linked non-destructive RAW options work (reference this topic) is:

• The linked option creates an afphoto file of 1MB, give or take, which contains a very low-resolution copy of the RAW image to use temporarily when the afphoto is opened, pending a full expansion and development of the linked RAW image.
   
• The embedded RAW option saves the developed RAW file within the afphoto file, which (in addition to having a nice self-contained afphoto file) speeds up the time it takes to open the file for editing at full resolution (compared to the linked alternative), at the expense of increased file size.

There are two issues with the way these options operate. The biggest issue is that the embedded RAW option consumes an incredible amount of disk space when compared to the alternative. For example, I have a 62MB RAW file. If I save the afphoto file in the linked RAW mode, I get a 1MB afphoto file. So the total disk space consumed for that image is 63MB. If I instead save the afphoto file in embedded RAW mode, the afphoto file is 385MB, which is 320MB more than it needs to be to accomplish embedding.

The second issue is that the preliminary low-resolution linked RAW image is extremely low-resolution.

So I'm requesting two features:

1. Have two different flavors of Embedded RAW: the original/current implementation, plus a new implementation that optimizes for disk space at the potential expense of performance.
    
2. Either have a higher-resolution "thumbnail" stored in a linked RAW file, or provide an option/preference for the user to modify the resolution of that low-resolution linked RAW image.

[walt.farrell]

2 hours ago, Corgi said:

If I instead save the afphoto file in embedded RAW mode, the afphoto file is 385MB, which is 320MB more than it needs to be to accomplish

I don't think you can draw that conclusion yet. 

How big is the file if you Develop it to a Pixel layer, rather than using the new function? That will give, I think, a better idea of what is "needed" (though still not perfect, perhaps).

[Corgi]

2 hours ago, Corgi said:

... If I instead save the afphoto file in embedded RAW mode, the afphoto file is 385MB, which is 320MB more than it needs to be to accomplish embedding.

 

6 minutes ago, walt.farrell said:

I don't think you can draw that conclusion yet. 

How big is the file if you Develop it to a Pixel layer, rather than using the new function? That will give, I think, a better idea of what is "needed" (though still not perfect, perhaps).

When saved as a pixel layer, the file is 321MB. But I don't see how that's relevant.

The conclusion still seems obvious to me. The 62MB RAW file contains all of the information about the photo. It could be appended to (or encapsulated into) the afphoto file byte-for-byte, rather than pre-processed into a larger size. Otherwise, what information is contained in that extra 320MB?

 

[walt.farrell]

1 hour ago, Corgi said:

Otherwise, what information is contained in that extra 320MB?

 

All of the actual image, so you can see it on screen. Otherwise, as with the Linked form, you have to Develop it when opening so you can see it.

[Corgi]

15 minutes ago, walt.farrell said:

All of the actual image, so you can see it on screen. Otherwise, as with the Linked form, you have to Develop it when opening so you can see it.

Exactly! And what I'm saying is that I'd like an embedded feature that does away with that extra storage, as it is not necessary until the file is opened.

I guess perhaps I'm not sure what you're saying. It seems completely obvious that Serif could add an embedded RAW feature which consumes little more disk space than the RAW file itself (absent editing). It is trivial from a technical standpoint (in the sense that it is trivially obvious that it doesn't require tech wizardry). Do you concur?

[Old Bruce]

5 hours ago, Corgi said:

Have two different flavors of Embedded RAW: the original/current implementation, plus a new implementation that optimizes for disk space at the potential expense of performance.

Isn't that the way the Linked method works? Bit of a performance hit in displaying (Developing) the image but a huge saving in file size.

[Corgi]

3 minutes ago, Old Bruce said:

Isn't that the way the Linked method works? Bit of a performance hit in displaying (Developing) the image but a huge saving in file size.

Yes, except that with linking you lose the portability and flexibility advantages of embedding.