Support for editing exifs

[i5-650]

Hey,

Do you plan on adding support for editing exits ?

That would make me switch from rexiv2 to your lib.

[mindeng]

Hi @i5-650

Thank you for your feedback! I will definitely consider adding editing features in future versions. However, it may be done step by step based on priority. For example, we might start with some commonly used editing features, such as:

• Modifying time information
• Editing GPS information
• Erasing all Exif/Metadata

Do you have any suggestions? Or are there other editing features you’d like to see prioritized? Please feel free to share your thoughts. Thank you!

[i5-650]

Great!

You've already mentioned the most important points (in my opinion), but I’d like to expand on this. My goal is to edit all EXIF data in a file, particularly for images.

If I may suggest a few thing:

• Displayable EXIF data: You already have this functionality, which is great!
• Serializable EXIF data: I’m currently working on an EXIF tool/editor that will allow users to edit EXIF data interactively—similar to how git rebase -i opens up Vim (on Linux) then use what the user wrote. Having EXIF data that can be easily serialized/deserialized would help immensely in this project.

[mindeng]

Great!

You've already mentioned the most important points (in my opinion), but I’d like to expand on this. My goal is to edit all EXIF data in a file, particularly for images.

If I may suggest a few thing:

• Displayable EXIF data: You already have this functionality, which is great!
• Serializable EXIF data: I’m currently working on an EXIF tool/editor that will allow users to edit EXIF data interactively—similar to how git rebase -i opens up Vim (on Linux) then use what the user wrote. Having EXIF data that can be easily serialized/deserialized would help immensely in this project.

I think the serialization function should be considered already available, just enable the feature json_dump. You can refer to the usage in rexiftool.

Deserialization may be a bit problematic, mainly because there should be no way to distinguish numeric types in json, for example, u8/u16/u32/u64 may be the same to json, but different when reading and writing to Exif. Therefore, you may need to carry out separate serialization and deserialization designs according to your demand scenarios, which may be more flexible in the application.

[i5-650]

Yes, serialization is already implemented (and it's great!), but I think we might be able to work around deserialization in some way. (I'm not an expert on EXIFs, so please correct me if I'm wrong.)

Based on the tag name, we could define an Enum that might look something like this:

#[derive(Debug, Serialize, Deserialize)]
enum ExifTag {
    SonyRawImageSize(i16),
    BlackLevel(i16),
    ExposureTime(f32),
    IsoSpeed(i32),
    // Add more EXIF tags and their types here
}

Therefore, we could serialize from a JSON file! However, that would imply having a huge Enum...

Let me know what you think about that

[mindeng]

Yes, serialization is already implemented (and it's great!), but I think we might be able to work around deserialization in some way. (I'm not an expert on EXIFs, so please correct me if I'm wrong.)

Based on the tag name, we could define an Enum that might look something like this:

#[derive(Debug, Serialize, Deserialize)]
enum ExifTag {
    SonyRawImageSize(i16),
    BlackLevel(i16),
    ExposureTime(f32),
    IsoSpeed(i32),
    // Add more EXIF tags and their types here
}

Therefore, we could serialize from a JSON file! However, that would imply having a huge Enum...

Let me know what you think about that

In fact, EntryValue has already done this. You can try using format!("{:?}", entry_value) directly. However, parsing from str has not been implemented yet, but this shouldn't be a problem to handle at the application layer. If needed, we could also consider adding that implementation to the library.