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

Does not respect EXIF orientation #76

Open
gpolosa opened this issue Jan 18, 2023 · 2 comments
Open

Does not respect EXIF orientation #76

gpolosa opened this issue Jan 18, 2023 · 2 comments

Comments

@gpolosa
Copy link

gpolosa commented Jan 18, 2023

I have a huge database of photos and am trying to compare ones of the same name to discard duplicates. Some duplicates have a different orientation flag in the EXIF data, while others have already been rotated (I probably used some jpeg optimization software on them in the past which transformed for the orientation). When comparing both images that appear the same way in image viewers, a huge difference is reported because one stores the pixels in a horizontal sequence and the other in a vertical sequence.

odiff should apply the orientation flag when loading images and transform the data accordingly. I could preprocess all images that have non standard orientation, but that requires a recompression and potential loss of quality.

Seems like a trivial thing to implement and would avoid mismatches for the unaware.

@gpolosa
Copy link
Author

gpolosa commented Jan 18, 2023

Found a fix which requires an extra step to use "exiftran" to losslessly rotate images in place according tot heir exif data orientation flag. Comparing works properly now.

@dmtrKovalenko
Copy link
Owner

Thanks for posting a solution. I feel like I don't really want to add this by default, because it takes time to parse and read EXIF data from jpeg files while other formats do not support it at all, and for most usecases, you don't have this issue.

For now, it will be required to manually rotate the image if you know the data might be different. If there will be more calls for this in the future we can probably implement this behind the flag but this will require a lot of effort in actually changing how we read pixels to make it truly efficient.

If you really need this please post your use case in the comments or you can also sponsor my work on this to have 100% guarantee of quick implementation https://github.com/sponsors/dmtrKovalenko

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

No branches or pull requests

2 participants