Inflated JPG File Size - Photoshop Document:Ancestors Metadata

[wckdtall]

Has anyone run into this issue?

I have a JPG that I have removed all image from, and filled with white. When I save it, the size is 7.89 MB. If I go into Bridge and clear the metadata, most likely the "<Document:Ancestors>" which contains "<rdf:bag>" , and 100+ lines of Hexadecimal code, the file size goes down to around 150KB. Maybe I'm missing a file save option out of photoshop, but It seems this metadata should be scrubbed on file saved. Additionally, does anyone know what kind of information is stored in Document Ancestors? Or if there is image information embedded that could potentially be extracted?

[Stephen_A_Marsh]

Hi gener7, I believe that the script is a Photoshop script, not Bridge. This Photoshop script can be setup to automatically run when files are opened, saved or exported using the Scripting Events Manager, as described in my post here:

Re: Photoshop saving issue (FILES TOO LARGE)

The Bridge script that you are thinking of is in this thread:

Bridge Script to Remove Photoshop DocumentAncestors Metadata

Cheers!

[gener7]

Thanks Stephen. I rushed that one answer out and missed that detail.

[Stephen_A_Marsh]

I have just updated my blog with with all of the known solutions to this issue:

Prepression: Metadata Bloat – photoshop:DocumentAncestors

[elmimmo]

In my test with a PNG file, from the methods listed in iamwickedtall1​'s blog post “Prepression: Metadata Bloat – photoshop:DocumentAncestors​”, the ones that accomplished dramatic lossless file size reduction were:

• Solution #3: ExifTool
• Solution #4: PDF Files & Acrobat DC Pro (v. 17.012.20098)

but the following did not:

• Solution #1: Adobe Photoshop Script (v. 17.0.0 a.k.a 2015.5)
• Solution #2: Adobe Bridge Script (v. 6.2.0.179)
• Addendum – Solution #5: Adobe Photoshop Script (v. 17.0.0 a.k.a 2015.5)

In case of the latter three, the scripts run apparently successfully, but the PNG weighted approximately the same. Furthermore, subsequently trying Solution #3: Exiftool with the PNG did nothing too. In order to diagnose why, I extracted the XMP metadata from the processed PNG using exiftool:

exiftool -b -XMP image.png >out.xmp

Opening it in a text editor revealed that, while all Document:Ancestors entries were gone, now there were thousands of lines filled only with spaces acting as padding between </x:xmpmeta> and <!--?xpacket end="r"?-->, which explains why exiftool could not fix the image after it has unsuccessfully been processed by the solutions that did not work.

Note that while Bridge does not allow rotating a PNG, I tried adding an IPTC keyword to force Bridge into updating the file or whatever. The keyword was inserted, but the lines filled with spaces in the XMP metadata block remained.

[Stephen_A_Marsh]

elmimmo a small correction, the blog is mine – not iamwickedtall1’s.

Thank you for your tests and posting the findings. I did not try PNG, I remember PSD and JPEG not having any issues, not sure about TIFF. I have added a note to the blogpost.

I have a feeling that the 3 scripts that did not work as expected were not intended for PNG or that PNG requires special handling.

I can confirm you results.

When I ran the script on a PNG file and looked at the XMP dump, there were 41,453 lines of data, many blank.

I then ran the following ExifTool command to rebuild the metadata:

exiftool -v -all= -tagsfromfile @ -all:all -unsafe -icc_profile PATH-TO-FILE

Which fixed the file and resulted in 150 lines of data and a reduction in file size.

[wckdtall]

elmimmo​ could you clarify a bit? You mention that dramatic file size loss was not achieved for

• Solution #1: Adobe Photoshop Script (v. 17.0.0 a.k.a 2015.5)

However, you go on to later say that exif tool left you with thousands of blank lines, and cited it as a success. As PNGs use a lossless compression you may not notice too much of a difference in file size w/ and w/out Doc Ancestors using maximum compression. PNGs can be tricky, I've worked with some recently that using fast save are 400MB, and using max compression and save are 2.8 MB. No loss on the image quality or information but compression made a world of difference.

[Stephen_A_Marsh]

iamwickedtall1 – I would suggest that you read posts #24 and #25 again. The Photoshop and Bridge Scripts when used on PNG files that contain photoshop:DocumentAncestors metadata do not correctly remove the metadata and leave blank lines. I confirmed this behaviour in post #25 and also confirmed that ExifTool does correctly remove this metadata from PNG files and that it can also fix/clean the blank lines left when these scripts are run on PNG files.

[wckdtall]

Reread both, and I'm still seeing that Script Solution #1, works just fine, and have been using with no problem through photoshop. Only difference between my workflow and what you've been using is exifTool, which maybe potentially there are special characters not being handled on that end? In looking between the tags elmimmo mentioned, the only difference I have is an end = "w" for xpacket. In both the raw XMP with doc ancestors, and the cleansed version, there are only about 20 lines in between the 2, although in my document there are also 2047 spaces on those lines. I use this script for tif, psd, jpg and tif and have run into no issues with inflating the file again. I wonder if exifTool is otherwise delimiting the file by spaces at that point and reading them to their own line. I exported my XMP via bridge and didn't see an issue even in text editor, can you confirm that you're seeing the same within a simple save as from Photoshop after running the script?

[Stephen_A_Marsh]

You don’t mention PNG... Did you actually try PNG? This is what the addendum post is all about, not other formats.

Save for web and export to PNG strip metadata, so this is not an issue. A regular save as PNG will retain the metadata and running these scripts on PNG does appear to mangle the metadata and not work as expected.

[wckdtall]

Forgot to include PNG, but yes that works fine as well. I have yet to find a format that doesn't execute the script properly.

[elmimmo]

iamwickedtall1  escribió

Forgot to include PNG, but yes that works fine as well. I have yet to find a format that doesn't execute the script properly.

I checked again and indeed Solution #1: Adobe Photoshop Script (v. 17.0.0 a.k.a 2015.5) does work on PNGs just fine. Go figure. I might have missed something when I checked originally.

Nevertheless, Solution #2: Adobe Bridge Script (v. 6.2.0.179) and Addendum – Solution #5: Adobe Photoshop Script (v. 17.0.0 a.k.a 2015.5) still did not work this time either, resulting in the same effect I described above: a modified PNG that remains unnaturally huge but has no Document Ancestor metadata anymore.

For reference, this is the PNG file I used, a whooping 13 MB file for a canvas of a mere 100px². (Update: I accidentally uploaded a version processed by the Bridge script therefore still inflated but lacking Document Ancestor metadata; after I noticed, I changed the link to point to a non-processed file therefore with its Document Ancestor metadata intact).

[Stephen_A_Marsh]

Go figure. I might have missed something when I checked originally.

It is strange, I’m sure the same thing happened to me! When I first checked, it did not work, then the next time it did…

[elmimmo]

iamwickedtall1​, the results that I report refer to when applying those solutions exclusively to PNG files. Here, I rephrase it all to make it clearer:

• Photoshop or Bridge scripts do not work on PNG files. They do alter the PNG, but substituting, instead of deleting, the thousands of Document Ancestors with thousands of lines filled with spaces, therefore maintaining its approximate file size. Applying exiftool to the PNG after it has been unsuccessfully processed by the Photoshop or Bridge scripts, in a manner (i.e. command-line arguments) that it deletes only Document Ancestors, accomplishes nothing either, since the file has no Document Ancestor metadata anymore.
• Exiftool does work bulletproof to affected PNGs that have not been previously tampered with by the Photoshop or Bridge scripts.

iamwickedtall1​ wrote:

I exported my XMP via bridge and didn't see an issue even in text editor

For what it's worth, the XMP of a PNG that has unsuccessfully been processed by the Bridge script, if exported via Bridge (menu File > File Info… > Export…), does not contain those thousands of lines filled with spaces that I report the Bridge script substituted Document Ancestor metadata with. But they are there if the XMP is exported via exiftool. And since, at any rate, the file size of the PNG processed by the Bridge script remains huge, I take the XMP exported by exiftool is the reliable one.

[wckdtall]

Thanks for going into further detail. I cannot speak to the Bridge Script as I only solved for Photoshop. In Bridge, I'm wondering if the file needs to be saved via another method to reflect the changes to the xmp before letting go of that space in the file. As far as which xmp data is correct, it seems something unexpected is happening with exif tool that would need to be addressed. I did a quick test, taking a png with doc ancestors, and one that had been saved out running the script through photoshop, and changing both extensions to xmp and opening in text edit. In both cases, there were 120 lines between </x:xmpmeta><?xpacket end="w"?>. The main difference being the file with ancestors had an addition 66110 lines of code. As the information has been successfully scrubbed from the file, it would seem there needs to be additional handling on the exifTool end, where Adobe is potentially creating some hidden issues within their code.

[Stephen_A_Marsh]

ExifTool is doing this correctly.

[giahai]

Hello, i think i run into similar issue.

My file is originally 300MB, but it just includes 3 very tiny artboards for web banner which within 300x350px. Every artboard has only 1 layer with no special effect. Items in the artboards are copied and pasteed from another file. I suspect something wrong so i delete all the layers and remain 1 empty layer in one artboard. the file is still at 280MB??!?!

I tried your method but there is an error while running the jsx file

i am not sure which part went wrong...

[Stephen_A_Marsh]

You incorrectly saved the file as a RTF rich text file, not as plain text file.

[li-jent93610173]

OMG!!!
You're a life saver T-T

THX!!!!!!!!

[dominikamars]

thank you SO MUCH.