Get image properties without hydrating the file

[HEIC-to-JPEG-Dev]

With placeholder files, only a "stub" is on the local filesystem; any attempt to read more data causes the file to hydrate (download the full file - think OneDrive or iCloud).

The basic image properties can be retrieved using WinRT StorageFile.Properties.GetImagePropertiesAsync(); - this gets the data without hydration, performance is very, very bad though.

I understand that not all properties would be available, but DateTime/Dimensions etc are.

Is there any advice on if this is possible or a future update ?

thanks

[StefanOltmann]

https://learn.microsoft.com/en-us/uwp/api/windows.storage.fileproperties.imageproperties?view=winrt-22621

This entails incorporating Windows-specific system code into a Java library that is currently platform-independent. Maybe even a DLL lib with JNI access would need to be implemented, but it would only work for Windows.

The resolution for this issue should be implemented in the end-user application utilizing the library. It involves preventing users from selecting OneDrive stub files and encouraging them to utilize a dedicated OneDrive source file.

Consequently, this approach aligns with how I am addressing the problem in Ashampoo Photos.

However, this may be an viable idea for metadata-extractor-dotnet.

@drewnoakes I suggest closing this as "not planned" to maintain metadata-extractor's complete platform agnosticism.

[drewnoakes]

However, this may be an viable idea for metadata-extractor-dotnet.

The .NET library is also cross-platform so cannot take Windows dependency.

I understand the original request here but feel it is out of scope for the library.

[HEIC-to-JPEG-Dev]

https://learn.microsoft.com/en-us/uwp/api/windows.storage.fileproperties.imageproperties?view=winrt-22621

This entails incorporating Windows-specific system code into a Java library that is currently platform-independent. Maybe even a DLL lib with JNI access would need to be implemented, but it would only work for Windows.

The resolution for this issue should be implemented in the end-user application utilizing the library. It involves preventing users from selecting OneDrive stub files and encouraging them to utilize a dedicated OneDrive source file.

Consequently, this approach aligns with how I am addressing the problem in Ashampoo Photos.

However, this may be an viable idea for metadata-extractor-dotnet.

@drewnoakes I suggest closing this as "not planned" to maintain metadata-extractor's complete platform agnosticism.

The problem is, that for OneDrive, there is an open API, but for other services like iCloud, there is not, so we have to rely on the Operating System and the sync system.

[drewnoakes]

I understand, though that feels more like a request for a new kind of library (to paper over such differences).

[StefanOltmann]

The problem is, that for OneDrive, there is an open API, but for other services like iCloud, there is not, so we have to rely on the Operating System and the sync system.

All cloud services provide a REST API, except iCloud, which is not meant for direct use but is instead accessed transparently through Apple Photos.

However, cloud APIs often return only partial data. The good news is that metadata-extractor stops reading from InputStream as soon as it has all metadata, allowing you to leverage this behavior to download only the file headers from the APIs. A solution to your problem already exists; you just need to discourage users from selecting the OneDrive folder on disk and guide them to use the OneDrive REST instead.

Considering your previous mention that the WinRT approach is notably slow, it raises the question of what kind of user experience it would provide to your users.