Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User configurable per-file attributes #14

Open
unreadablewxy opened this issue May 25, 2020 · 2 comments
Open

User configurable per-file attributes #14

unreadablewxy opened this issue May 25, 2020 · 2 comments
Labels
unplanned Might want, thoughts?

Comments

@unreadablewxy
Copy link
Owner

unreadablewxy commented May 25, 2020

It could be that I rely too much on group attributes to realize it before. But I've realized that the program doesn't actually support user configured file level attributes as a first class concept.

  • This makes sense because hoppers corresponds to groups which doesn't necessarily have a 1:1 relationship with the files
  • The service doesn't really do any file level inspection that doesn't result in an attribute it will write anyways
  • Maybe we ought to expose more FFMPEG & OpenCV functionality
  • Maybe we ought to let users set attributes on files via its own phase in the import process, so it doesn't have to be hacked it into existence via transforms
  • Quite possibly it is a good to format paths purely based off file attributes so we can generate more nuanced file names instead of some combination of group level properties & file index
@unreadablewxy unreadablewxy added the unplanned Might want, thoughts? label May 25, 2020
@unreadablewxy
Copy link
Owner Author

unreadablewxy commented May 27, 2020

File identities and qualifiers can probably be safely coupled together to expose image/audio content properties as native properties (bitrate, mean frequency/amplitude, resolution, frame rate) since we have a chance to pull those information out anyways as part of doing phash dedupe.

Might make sense to create a different kind of external program invocation. "Probes" that writes back properties which we can attach to the files. Could be a good adapter for meta-data fetchers that doesn't understand xattrs/alt-streams.

@unreadablewxy
Copy link
Owner Author

Does probes really make sense? Transforms prevents us from generate dry run reports, because we can't guess what the transform does.

The only way I see us forwards with probes is to force people declare what properties the probes will retrieve, i.e. each probe fetches one value out of their STDOUT and we write it to the attribute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unplanned Might want, thoughts?
Projects
None yet
Development

No branches or pull requests

1 participant