Donate. I desperately need donations to survive due to my health

Get paid by answering surveys Click here

Click here to donate

Remote/Work from Home jobs

Custom file scheme for object state with image

I've been debating on how best to save data for a WPF application which involves layering interactive elements over an Image on a Canvas. The interactive elements can easily be persisted in XML, but the Image is causing me the most trouble. I can obviously get a byte[] from the JpegEncoder and persist that in the XML file along with the metadata I need from the original, but running it through an encoder each time will degrade the quality of the image over several saves, will it not? This seems less than ideal. So then I considered reading the original file into a byte[] and persisting that in the XML, but that seems odd too- especially considering a master project file could contain hundreds of individual interactive elements/image objects.

How have others addressed these situations?

The only example I can think of off the top of my head are the Microsoft Office "x" files (docx, xlsx, etc..) where the file is a zip, containing sub folders, and XML navigation files and objects. This would allow storage of the original image without altering it alongside the interactive object XML. But seems like a complex solution with a lot of overhead in the disk writing department. I assume that the project file (zip) would really have to be extracted to a temp directory when opened, then when a save is performed, the temp directory re-zipped and written over the original? Thinking out loud- as soon as a new Image/Element was started, I'd probably have to start a temp folder and copy the original image file to it, and create a new XML file for it, etc..

I guess there is the Visual Studio like scheme as well, where there is a project folder, with XML navigation files, with sub folders for each individual Image/XML combo. That would reduce the overhead in extracting an entire zip to a temp folder, but would decrease share-ability that having everything contained in single zip provides.

From an in app data perspective, I like the first- each Image and elements wrapped in their own object.. making LINQ queries on their data easy. But it feels like a big project would get out of hand quickly... So dealing with the second and just loading XML data until the image is required seems more reasonable, but a TON more work... the photo metadata would still have to be extracted and entered into the XML for the individual image/element set to make them LINQ query-able (Filter by all original images taken in May 2018, for ex).

Again, looking for other potential solutions. Hopefully someone else has had to do something similar and can has some insightful pros and cons.

Edit: Is it possible to use EF Core with some sort of local database?

Comments