ICC APP2 section strip#654
Conversation
- just the ui toggle, no functionality - defaulted to off - no icon - probably doesn't need the geo-tag note?
- we can find and parse the ICC profile! - todo: remove this section of bytes
- remove unused import - adjust summary - rename variables for clarity
- move extractIccFromJpeg() into it's own JpegUtils class - adjust extraction to return a data object containing the start and end position of the APP2 section so the caller can know where to strip bytes. - function to strip bytes
|
I have also validated that the unwanted ExifTool output now with the "Remove ICC profile data after capture" toggle enabled: ExifTool Version Number : 13.55 |
|
ICC profiles are not EXIF metadata. The profile is a standard ICC profile for Pixels in general so it doesn't vary across photos. The output of ExifTool is misleading since it shows all the metadata it can find including filesystem metadata for the currently stored file. It's not all EXIF metadata. |
|
Yes, I understand that now. What I mean is the data shown in ExifTool was coming from the ICC profile. Not the exif data. That is what mislead me originally. But I am still validating the output with exiftool. |
Then probably all pixels have have only 1 ICC chunk within a single APP2 section? I don't have any other pixels to validate on. |
Ok. Got this working! New toggle, off by default. Closes #520
Consider this a draft as there are a still some minor todo's:
Duplicate id '@+id/remove_exif_icon', already defined earlier in this layoutPNG support? I didn't see any option for saving as PNG, so only implemented the default JPG. But I can add PNG ICC strip support if needed.Nvm, I see PNG is not supported in 529.I have only tested on a Pixel 9a which appears to only have 1 ICC chunk by default:
But have tested a few different images by injecting in the bytes for testing. Including validating against images no ICC chunk:
And against images with multi-chunk ICC profile; sample multi-chunk image: https://cloud.githubusercontent.com/assets/1643413/5495182/985fc656-86e2-11e4-9349-78a0dd9d6b4d.jpg
Output matches
iccJpegDump 985fc656-86e2-11e4-9349-78a0dd9d6b4d.jpg -p /tmp/multi.iccThe images that come out so far with ICC strip enabled have been valid and rendering both on device (gallery, in other apps), and in standard image viewers on desktop once pulled from the device. But I am struggling to find more sample data with ICC profiles from different devices, so my testing is severely limited to just the 9a and a couple images found online.
I have also been validating / mapping out ICC data structure in ImHex, extending the jpeg pattern to parse ICC profile (WIP). Now that I know how to parse ICC properties, there is potential to edit unwanted ICC tags (ei: google strings, timestamps, etc...) whilst leaving the rest of the color profile in-tact for color accuracy. But that is out-of-scope for this PR.
References & Resources:
I understand this is a low priory feature, but at least this PR should get it ~90% of the way. Post processing time was mentioned as a potential concern in the linked issue, but it seems to be not too large impact by my measurements (at least on on the 9a, unsure about older devices) averaging out at an extra 3-4 ms per image.
I could not find documentation on preferred standards / best practices / style guide for contributing. I did my best to follow the existing structure, but let me know any adjustments that need to be made and I will correct it.