You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tika.apache.org by Chris Bamford via user <us...@tika.apache.org> on 2023/03/15 17:19:14 UTC
JPEG / ICC Profiles
Hi there,
As of Tika 2.x I noticed that JPEG files now produce a huge amount of new metadata (3 x floats per pixel?), e.g.
ICC:Signature : acsp
ICC:Viewing Conditions : view (0x76696577): 36 bytes
ICC:Green TRC : 0.0, 0.0000763, 0.0001526, 0.0002289, 0.0003052, 0.0003815, 0.0004578, 0.0005341, 0.0006104, 0.0006867, 0.000763, 0.0008392, 0.0009003, 0.0009766, 0.0010529, 0.0011292, 0.0012055, 0.0012818, 0.0013581, 0.0014343, 0.0015106, 0.0015869, 0.0016632, 0.0017395, 0.0018158, 0.0018921, 0.0019684, 0.0020447, 0.002121, 0.0021973, 0.0022736, 0.0023499, 0.0024262, 0.0025025, 0.0025788, 0.0026551, 0.0027161, 0.0027924, 0.0028687, 0.002945, 0.0030213, 0.0030976, 0.0031739, 0.0032502, 0.0033417, 0.003418, 0.0034943, 0.0035859, 0.0036622, 0.0037537, 0.00383, 0.0039216, 0.0040131, 0.0041047, 0.0041962, 0.0042878, 0.0043793, 0.0044709, 0.0045624, 0.0046693, 0.0047608, 0.0048524, 0.0049592, 0.005066, 0.0051575, 0.0052644, 0.0053712, 0.005478, 0.0055848, .....
Is there a simple way to prevent it? I haven’t dug into the code yet, but was just curious.
Thanks,
Chris
Hi there,
As of Tika 2.x I noticed that JPEG files now produce a huge amount of new metadata (3 x floats per pixel?), e.g.
ICC:Signature : acsp
ICC:Viewing Conditions : view (0x76696577): 36 bytes
ICC:Green TRC : 0.0, 0.0000763, 0.0001526, 0.0002289, 0.0003052, 0.0003815, 0.0004578, 0.0005341, 0.0006104, 0.0006867, 0.000763, 0.0008392, 0.0009003, 0.0009766, 0.0010529, 0.0011292, 0.0012055, 0.0012818, 0.0013581, 0.0014343, 0.0015106, 0.0015869, 0.0016632, 0.0017395, 0.0018158, 0.0018921, 0.0019684, 0.0020447, 0.002121, 0.0021973, 0.0022736, 0.0023499, 0.0024262, 0.0025025, 0.0025788, 0.0026551, 0.0027161, 0.0027924, 0.0028687, 0.002945, 0.0030213, 0.0030976, 0.0031739, 0.0032502, 0.0033417, 0.003418, 0.0034943, 0.0035859, 0.0036622, 0.0037537, 0.00383, 0.0039216, 0.0040131, 0.0041047, 0.0041962, 0.0042878, 0.0043793, 0.0044709, 0.0045624, 0.0046693, 0.0047608, 0.0048524, 0.0049592, 0.005066, 0.0051575, 0.0052644, 0.0053712, 0.005478, 0.0055848, .....
Is there a simple way to prevent it? I haven’t dug into the code yet, but was just curious.
Thanks,
Chris
Disclaimer
The information contained in this communication from cbamford@mimecast.com sent at 2023-03-15 17:19:17 is confidential and may be legally privileged. It is intended solely for use by user@tika.apache.org and others authorized to receive it. If you are not user@tika.apache.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
This email message has been scanned for viruses by Mimecast. Mimecast delivers a complete managed email solution from a single web based platform.
For more information please visit: https://www.mimecast.com
Visit our preference center: https://info.mimecast.com/Subscription-Management.html to update your email preferences or unsubscribe: https://info.mimecast.com/unsubscribe-management.html from all future emails from Mimecast.
Re: JPEG / ICC Profiles
Posted by Tim Allison <ta...@apache.org>.
I can think of three options:
1) use a metadatafilter (this is applied post parse before the data is
returned to you)
2) use a metadatawritefilter (this is applied during the parse to limit the
amount of data written to the metadata object
3) open a ticket to make the icc profile extraction configurable
1) won't work if you're streaming tika via tika-server, but 2 should
If 1) does fit the bill, look at IncludeFieldMetadataFilter or
ExcludeFieldMetadataFilter
See some documentation here:
https://cwiki.apache.org/confluence/display/TIKA/ModifyingContentWithHandlersAndMetadataFilters
Let us know how we can improve that documentation or the functionality.
On Wed, Mar 15, 2023 at 1:19 PM Chris Bamford via user <us...@tika.apache.org>
wrote:
>
> Hi there,
>
>
>
> As of Tika 2.x I noticed that JPEG files now produce a huge amount of new
> metadata (3 x floats per pixel?), *e.g.*
>
>
>
> ICC:Signature : acsp
>
> ICC:Viewing Conditions : view (0x76696577): 36 bytes
>
> ICC:Green TRC : 0.0, 0.0000763, 0.0001526, 0.0002289, 0.0003052,
> 0.0003815, 0.0004578, 0.0005341, 0.0006104, 0.0006867, 0.000763, 0.0008392,
> 0.0009003, 0.0009766, 0.0010529, 0.0011292, 0.0012055, 0.0012818,
> 0.0013581, 0.0014343, 0.0015106, 0.0015869, 0.0016632, 0.0017395,
> 0.0018158, 0.0018921, 0.0019684, 0.0020447, 0.002121, 0.0021973, 0.0022736,
> 0.0023499, 0.0024262, 0.0025025, 0.0025788, 0.0026551, 0.0027161,
> 0.0027924, 0.0028687, 0.002945, 0.0030213, 0.0030976, 0.0031739, 0.0032502,
> 0.0033417, 0.003418, 0.0034943, 0.0035859, 0.0036622, 0.0037537, 0.00383,
> 0.0039216, 0.0040131, 0.0041047, 0.0041962, 0.0042878, 0.0043793,
> 0.0044709, 0.0045624, 0.0046693, 0.0047608, 0.0048524, 0.0049592, 0.005066,
> 0.0051575, 0.0052644, 0.0053712, 0.005478, 0.0055848, .....
>
>
>
> Is there a simple way to prevent it? I haven’t dug into the code yet, but
> was just curious.
>
>
>
> Thanks,
>
>
>
> Chris
>
>
> Chris Bamford m: www.mimecast.com
> Principal Research Engineer p: +44 207 847 8700 Address click here
> <https://www.mimecast.com/company/contact/>
> ------------------------------
> [image: Mimecast] <https://www.mimecast.com>
>
> [image: Linked In]
> <https://eu-api.mimecast.com/s/click/XujAZpejvFW2OIhYbUKIG0T56quhi7ixzedlgvKeE7F0416QOd_RaFWSxFUX-Bnsa0pLanZQMG3GYkiYmkA9c3VPCRBYg4JXq_Wd9owjxje4HqoDBXGxYbEtfSZINU_3-1-DXs8HNoBxB7OUVIfjBbm80zerQX9iyu2hUqSsBeorOQA5m0DSs02m-WfDE0D8Juj8UlcLrraryOYrcDDzEA>
> [image: You Tube]
> <https://eu-api.mimecast.com/s/click/oXWSddS_iA9-kQJnecvDnnmT4bXzJBHkRMmjSfKzxTl0d3ABKZU64MudScMENzDgEEmASbOBgrjmuhe3ZiM_NO2tg0Z1GcCSnGtbZZjdMRF06vegVHPB0js6qidYKqOt1pPMtafV17ay-XNNjTTYsxvDG_kf6sdb_jHtP6aPIeA0eb8L5i4U-HHVLGlD80cI>
> [image: Facebook]
> <https://eu-api.mimecast.com/s/click/YaLfsfOawRiMCVCMOC63LfEyTkWb4fwGJWHrIBHTLROzt5jgCaAd2nyYsCVMfGmzvnR8DyMFUh_0Tks-xn--LE5vZ0Kta4v3tI5G2H83t0VXiBxlf9FPUJSA3zgPMu02gSvIoFwFitRJ75EwEEn4eewU1oumWj1z5QkrpAJSZUbvrncRsUbtx9FG8BMoNqIK>
> [image: Blog]
> <https://eu-api.mimecast.com/s/click/gNXpRy8Di3hABeg9FCvOkM4vXv3VryTzBmMrrDUSNoEH8j-PLL0wORTDjZQDmOzoUCox--CKGUpi456qAZ7-HrwbkTeK6xzoDkgbEf3Jv7J6ZaAtNt72UpwjbK1eQgsXQYGLsysA_qxqzLlmgHh0s0QhvGUnBXihs0pinvg0j4Duw5J7jY2wigBYMmvk442gtrNNxCnTUpQUk0b5Joeatw>
> [image: Twitter]
> <https://eu-api.mimecast.com/s/click/oXWSddS_iA9-kQJnecvDnj5hlL8lnV6ead-sYGbb2aV1JK9VhVmhVs0VcDzkVl1_ZhLJlzGFCk0XiDX175XPwruGREqBjtud6PuEVnTif79osZKE4RfNppedQuWnNVlXaJZkJtVJjZ9IcOra-Rsu_cRWkj9FHMmvWpwZxUgoK4VOguPkbwsOInzx-gJw99Co>
>
>
> [image: Mimecast Presents: 2023 State of Email Security]
> <https://eu-api.mimecast.com/s/click/uYdzQzQXhDdHR-C0Isqh0nDnU_W7ymHJ0fFg7m9rsxlfUgkyTA_yFKk_Co8eRiRTZXdEJ3LJaFPJvpW_4XEHJoVNaD1LK1qBmib3xz96GlHqSaMgDjoU9JiuxbMEfBz4Emk2FIq5K3skglFaDf6x1OitpO_9TEoU19nImuy59nNGXpNoegwRXuyDPXuZ8vNMUkTKizpfY-967aN2UGifuQ>
>
>
> *Disclaimer*
> The information contained in this communication from *
> cbamford@mimecast.com <cb...@mimecast.com> * sent at 2023-03-15
> 17:19:17 is confidential and may be legally privileged. It is intended
> solely for use by * user@tika.apache.org <us...@tika.apache.org> * and
> others authorized to receive it. If you are not * user@tika.apache.org
> <us...@tika.apache.org> * you are hereby notified that any disclosure,
> copying, distribution or taking action in reliance of the contents of this
> information is strictly prohibited and may be unlawful.
>
> This email message has been scanned for viruses by Mimecast. Mimecast
> delivers a complete managed email solution from a single web based
> platform. For more information please visit https://www.mimecast.com
>
> Visit our preference center to change how often you hear from us: Preference
> Center
> <https://info.mimecast.com/Subscription-Management.html?utm_source=EmailStationary>.
>
>
>
>
>