starred/photoprism

Fork 0

mirror of https://github.com/photoprism/photoprism.git synced 2026-03-02 22:57:18 -05:00

EXIF Wiki Updates/Discussion #157

New issue

Closed

opened 2026-02-19 23:03:04 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-19 23:03:04 -05:00

Owner

Originally created by @dsoprea on GitHub (Jan 13, 2020).

Originally assigned to: @dsoprea on GitHub.

@lastzero

Can we remove the table of all possible EXIF tags? If someone needs these, they can refer to the official link.
The EXIF link is a pointer to a non-authoritative library. We should update it to point to http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf (2.3). It's the same PDF as the one in go-exif (https://github.com/dsoprea/go-exif/blob/master/assets/DC-008-2012_E.pdf).
It might be more succinct and maintainable to point to exif.go as the source-of-truth for what tags PhotoPrism uses rather than having them in the other table, here.

Regarding the tags that the library (er, goexif, the previous integration) reportedly supports but PhotoPrism does not ("ExifIFDPointer", "GPSSatelites", "InteroperabilityIFDPointer"):

"ExifIFDPointer": I'm guessing that this refers to the tag that points to child IFDs, which is a concept internal to the EXIF library and shouldn't be a concern of the integration.
"GPSSatelites" (a misspelling of "GPSSatellites", the official name) is supported by go-exif (as are any other standard tags); does this imply that we want it in PhotoPrism?
"InteroperabilityIFDPointer": This refers to the collection of tags found in the Interoperability IFD. This should be already be supported as well. An example where they end-up in a JSON dump of tags during the uni-tests (the file we validate against): github.com/dsoprea/go-exif@25524615d1/assets/exif_read.json (L455) . The source-of-truth for the Interoperability tags that go-exif supports are here: github.com/dsoprea/go-exif@9068786204/tags_data.go (L934) . Are you wanting to bring some of these tags into PP?

I also noticed that there are screenshots of people being able to see metadata, which includes the original filename. As this is not currently supported, should I assume that these screenshots are sufficiently inaccurate that they should be removed?

Originally created by @dsoprea on GitHub (Jan 13, 2020). Originally assigned to: @dsoprea on GitHub. @lastzero 1. Can we remove the table of all possible EXIF tags? If someone needs these, they can refer to the official link. 2. The EXIF link is a pointer to a non-authoritative library. We should update it to point to http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf (2.3). It's the same PDF as the one in go-exif (https://github.com/dsoprea/go-exif/blob/master/assets/DC-008-2012_E.pdf). 3. It might be more succinct and maintainable to point to exif.go as the source-of-truth for what tags PhotoPrism uses rather than having them in the other table, here. Regarding the tags that the library (er, _goexif_, the previous integration) reportedly supports but PhotoPrism does not ("ExifIFDPointer", "GPSSatelites", "InteroperabilityIFDPointer"): - "ExifIFDPointer": I'm guessing that this refers to the tag that points to child IFDs, which is a concept internal to the EXIF library and shouldn't be a concern of the integration. - "GPSSatelites" (a misspelling of "GPSSatellites", the official name) is supported by go-exif (as are any other standard tags); does this imply that we want it in PhotoPrism? - "InteroperabilityIFDPointer": This refers to the collection of tags found in the Interoperability IFD. This should be already be supported as well. An example where they end-up in a JSON dump of tags during the uni-tests (the file we validate against): https://github.com/dsoprea/go-exif/blob/25524615d1246315ee12f8948d1b72acc80b00b9/assets/exif_read.json#L455 . The source-of-truth for the Interoperability tags that go-exif supports are here: https://github.com/dsoprea/go-exif/blob/9068786204c5fcf90bc65a93228da05915f7bb54/tags_data.go#L934 . Are you wanting to bring some of these tags into PP? I also noticed that there are screenshots of people being able to see metadata, which includes the original filename. As this is not currently supported, should I assume that these screenshots are sufficiently inaccurate that they should be removed?

deekerman

2026-02-19 23:03:04 -05:00

closed this issue
added the
enhancement

released
labels

deekerman commented

2026-02-19 23:03:05 -05:00

Author

Owner

@lastzero commented on GitHub (Jan 13, 2020):

Sure, remove it... think we don't need it anymore. Link would be good/enough. Feel free to fix other links as well.

@lastzero commented on GitHub (Jan 13, 2020): Sure, remove it... think we don't need it anymore. Link would be good/enough. Feel free to fix other links as well.

deekerman commented

2026-02-19 23:03:05 -05:00

Author

Owner

@lastzero commented on GitHub (Jan 13, 2020):

Those screenshots are of other apps and serve as inspiration, please don't remove them (until we find another place).

@lastzero commented on GitHub (Jan 13, 2020): Those screenshots are of other apps and serve as inspiration, please don't remove them (until we find another place).

deekerman commented

2026-02-19 23:03:05 -05:00

Author

Owner

@dsoprea commented on GitHub (Jan 13, 2020):

@lastzero Ack.

@dsoprea commented on GitHub (Jan 13, 2020): @lastzero Ack.

deekerman commented

2026-02-19 23:03:05 -05:00

Author

Owner

@dsoprea commented on GitHub (Jan 13, 2020):

@lastzero Comments on how/whether the tags mentioned should be brought into PP?

@dsoprea commented on GitHub (Jan 13, 2020): @lastzero Comments on how/whether the tags mentioned should be brought into PP?

deekerman commented

2026-02-19 23:03:05 -05:00

Author

Owner

@lastzero commented on GitHub (Jan 13, 2020):

Regarding support for more fields, I think we might have to restructure our db... main table should only contain columns we actually need for our search so that it has a chance to fit in memory.

@lastzero commented on GitHub (Jan 13, 2020): Regarding support for more fields, I think we might have to restructure our db... main table should only contain columns we actually need for our search so that it has a chance to fit in memory.

deekerman commented

2026-02-19 23:03:05 -05:00

Author

Owner

@lastzero commented on GitHub (Jan 13, 2020):

Can have a look at this, but should do the Places UI first... need to replace OSM.

@lastzero commented on GitHub (Jan 13, 2020): Can have a look at this, but should do the Places UI first... need to replace OSM.

deekerman commented

2026-02-19 23:03:05 -05:00

Author

Owner

@dsoprea commented on GitHub (Jan 13, 2020):

Makes sense to me. There are a lot of tags, but most of them are mundane. The Iop IFD always just seemed like technical minutiae to me. I'll assume that we already have the necessary minimum.

We can revisit any new tags that we might want at some more prudent point in the future when the need is there. Do you just want to close this?

@dsoprea commented on GitHub (Jan 13, 2020): Makes sense to me. There are a lot of tags, but most of them are mundane. The Iop IFD always just seemed like technical minutiae to me. I'll assume that we already have the necessary minimum. We can revisit any new tags that we might want at some more prudent point in the future when the need is there. Do you just want to close this?

deekerman commented

2026-02-19 23:03:06 -05:00

Author

Owner

@lastzero commented on GitHub (Jan 13, 2020):

If that's all and the documentation is updated, we can surely close this :)

@lastzero commented on GitHub (Jan 13, 2020): If that's all and the documentation is updated, we can surely close this :)

deekerman commented

2026-02-19 23:03:06 -05:00

Author

Owner

@dsoprea commented on GitHub (Jan 13, 2020):