[File] [PATCH] Magdir/images for Adobe Photoshop Color swatch *.ACO
Christos Zoulas
christos at zoulas.com
Fri Sep 23 13:21:41 UTC 2022
Committed, thanks!
christos
> On Sep 16, 2022, at 3:59 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> Some days ago i run the cleaning tool czkawka found on
> https://qarmin.github.io/czkawka/. One menu item concerns bad
> extensions. After running tool i looked in saved file list
> results_bad_extensions.txt for bad extension examples.
> One listed extension is ACO. I found such examples in subdirectory
> inside Adobe Photoshop program directory.
>
> When running file command version 5.43 on ACO examples and related
> negative samples i get an output like:
>
> 4096_colours.aco: data
> CHURCH.IMG: GEM Image data 224 x 170, 1 planes,
> 352 x 352 pixelsize
> DIAGRAM1.PI2: Atari DEGAS Elite bitmap 640 x 200 x 4
> , color palette 0000 0000 0777 0777 0000 ...
> FOCOLTONE-Farben.aco: Atari DEGAS Elite bitmap 640 x 400 x 2
> , color palette 033e 0002 0000 ffff ffff ...
> Faux-Spitzen.abr: data
> HKS Z Process.aco: data
> Mac OS.aco: Windows Precompiled iNF, version 1.0,
> InfStyle 1, flags 0xffff0000,
> at 0xcccc, LanguageID cccc,
> at 0xcccc, at 0xffff0000
> Photo Filter Colors.aco: data
> ReactOS-LiveCD.iso: ISO 9660 CD-ROM filesystem data
> 'REACTOS' (bootable)
> TOYO-Farbsystem.aco: Atari DEGAS Elite bitmap 640 x 400 x 2
> , color palette 041a 0007 10c1 15f5 f8b6 ...
> bmpsuite-15col.tga: Targa image data - Map (240) 1024 x 768 x 8
> Windows Precompiled iNF, version 1.0,
> InfStyle 1,
> at 0xa800a800,, LanguageID 54fc,
> at 0xfca8fcfc, at 0xa8fcfc00
> pal1wb-blue.pi3: Atari DEGAS Elite bitmap 640 x 400 x 2
> , color palette 0777 0007 0007 0007 0007 ...
>
> Furthermore for ACO samples generic mime type
> application/octet-stream or wrong like application/x-pnf or
> image/x-atari-degas is shown with -i option. With option --extension
> 3 byte sequence ??? or wrong extension pnf or pi3 is shown.
>
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). This also does not
> recognise the ACO samples. The samples are described wrong as
> DEGAS bitmap (*.PI2 *.PI3), TARGA bitmap (*.TGA), GEM bitmap (*.IMG),
> Adobe PhotoShop Brush (*.ABR) or WhatsApp encrypted (*.CRYPT7)
> (See appended trid-v-aco.txt.gz).
>
> For comparison reason i also run the file format identification
> utility DROID ( See https://sourceforge.net/projects/droid/). This
> also does not recognize the ACO examples.
>
> Luckily there exist exist an official file from adobe with some
> information about file format. And there exist sites with some more
> details about file format. So that informations are expressed
> by comment lines inside Magdir/images after Adobe Photoshop image
> and before XV thumbnail like:
> # URL: https://www.adobe.com/
> # devnet-apps/photoshop/fileformatashtml/
> # http://fileformats.archiveteam.org/wiki/Photoshop
> # Reference: http://www.nomodes.com/aco.html
>
> The ACO samples have no real strong magic. So i put displaying part
> inside subroutine adobe-aco. Then only suited test lines must be
> added before calling this sub routine. This starts according to
> documentation with lines like:
> 0 name adobe-aco
>> 0 ubeshort x Adobe Photoshop Color swatch, version %u
> !:mime application/x-adobe-aco
> !:apple ????8BCO
> !:ext aco
>> 2 ubeshort x \b, %u colors
>
> Instead of generic application/octet-stream i choose an user
> defined mime type. In first 2 bytes the version is stored as 2 byte
> big endian integer. The value 2 means newest version two. The value 1
> means older version one and the value 0 means oldest version zero.
> For later case i myself find no examples. So use this as first test
> by line like:
> 0 ubeshort <3
> Unfortunately this also always true for Atari DEGAS bitmaps.
>
> At offset two the number of colors (nc) is stored as 2 byte big
> endian integer. For real ACO examples i get values like:
> 20 50 86 88 126 204 300 1050 1137 1280 2092 3010 4096
> Nothing is said about range, but using brain this value does not
> become "too low". So skip few Atari DEGAS medium-resolution bitmap
> (DIAGRAM1.PI2) and many ISO 9660 CD-ROM by check for invalid low
> color numbers value (0) by second test line which looks like:
>> 2 ubeshort >0
>
> After the number of colors the entries for colors are stored. Each
> entry occupies at least 5 value word values (ID w x y z). So size of
> that area is nc*5*2. That exactly is true for older version.
> For newer version 2 this section contain more information. So use
> this as test by line like:
>>>> (2.S*10) ubelong x 1ST_SECTION_END %#4.4x
> By accessing the "last" bytes of first section many (69/327) Targa
> image (*.TGA) are skipped.
>
> According to documentation there exist hybrid variant. After the
> version 1 color section a version 2 section is stored (like in
> samples 4096_colours.aco "Photo Filter Colors.aco"). So older
> software read only the first section, which is version 1 and can
> handle colors. Modern software recognized also the second section
> section with version 2 and also show, handle also color names. So
> after version line test for older version variants by accessing the
> last bytes of first section and look for bytes after this section.
> If there exist such bytes and these start with value 2 then we know
> we have such a hybrid variant. So i show this information by lines
> inside sub routine adobe-aco, which looks like:
>> 0 ubeshort x Adobe Photoshop Color swatch, version %u
>> 0 ubeshort <2
>>> (2.S*10) ubelong x
>>>> &0 ubeshort 2 and 2
>
> At offset 4 the first color entry starts. At the beginning the color
> space ID is stored as 2 byte big endian integer. That information is
> shown by sub routine aco-color with starting lines like:
>> 0 ubeshort 0 RGB
>> 0 ubeshort 1 HSB
>> 0 ubeshort 2 CMYK
>> 0 ubeshort 3 Pantone
>> 0 ubeshort 4 Focoltone
>> 0 ubeshort 5 Trumatch
>> 0 ubeshort 6 Toyo
>> 0 ubeshort 7 Lab
>> 0 ubeshort 8 Grayscale
>> 0 ubeshort 9 wide CMYK
>> 0 ubeshort 10 HKS
> # >0 ubeshort 12 foo
> # >0 ubeshort 13 bar
> # >0 ubeshort 14 FOO
> # >0 ubeshort 15 BAR
>> 0 ubeshort x space (%u)
>
> The official documentation list as highest value 10. When i
> understand unofficial documentation right there may be exist also
> high values til 15. Using brain again we can assume that this value
> is "low", because all typical color space are already handled
> (0~RGB 2~CMYK 7~Lab ). So there may exist only a few more other
> exotic color spaces. So use this information by additional test
> line like:
>>> 4 ubeshort <16
> So few Targa bitmap (bmpsuite-15col.tga rgb24_top_left_colormap.tga)
> with invalid high color space ID (F0 1D) are skipped.
>
> After the ID four color coordinates are stored as 2 byte big endian
> integer. That information is shown afterwards in sub routine by lines
> like:
>> 2 ubeshort x \b, w %#x
>> 4 ubeshort x \b, x %#x
>> 6 ubeshort x \b, y %#x
>> 8 ubeshort x \b, z %#x
> The allowed ranges depends on ID. So for RGB space the z value must
> always be zero. So use this as additional test in RGB branch by
> additional lines like:
>>>>> 4 ubeshort =0
>>>>>> 12 ubeshort =0
> So many (220/327) Targa bitmap with "invalid high" (hexadecimal 2 3
> 2e03 4600 5e04 7502 8002 8b05 c700) RGB color z value are skipped.
>
> In a version 2 ACO file, those color coordinates are followed by the
> color name in the following format, that is shown by sub routine
> aco-color-v2 with lines like:
> 0 name aco-color-v2
>> 0 use aco-color
> #>10 ubeshort x \b, NUL_BYTES %#x
> #>>12 ubeshort x \b, LENGTH %u
>>> 12 ubeshort-1 x \b, %u chars
>>> 14 bestring16 x "%s"
>
> By last line the name of color is shown like: "DIC 1s" "PANTONE
> Process Yellow PC". Before that UTF-16 string the number of
> characters including the terminating \0-character is stored as 2 byte
> big endian integer. Before that length information 2 nil bytes are
> stored. So use this as additional test in non RGB newer version 2
> branch by lines like:
>>>>> 4 ubeshort !0
>>>>>> 0 ubeshort =2
>>>>>>> 14 ubeshort =0
>>>>>>>> 0 use adobe-aco
> So i skip few Atari DEGAS hi-resoltion bitmap (pal1wb-blue.pi3) and
> few ABR samples with invalid "high" nil bytes (7) before color name
> length.
> I hope that i eliminate all negative samples (not identified as
> ACO sample).
>
> At the end of sub routine adobe-aco i show for informational and
> control reason the first 2 color entries depending on version by
> lines like:
>> 0 ubeshort <2 \b; 1st
>>> 4 use aco-color
>>>> 2 ubeshort >1 \b; 2nd
>>>>> 14 use aco-color
>> 0 ubeshort =2 \b; 1st
>>> 4 use aco-color-v2
>>>> 2 ubeshort >1 \b; 2nd
>>>>> (16.S*2) ubequad x
>>>>>> &10 use aco-color-v2
>
> Now comes the other bar of the scissor. In output we see that many
> ACO samples are misidentified as Atari DEGAS 640 x 400 x 2 ( that is
> high resolution uncompressed variant with PI3 file suffix). In real
> Atari degas images the highest allowed value in color palette is
> value 0fff ( that is white for worst case 12 bit variant). Because
> displaying is done by sub routine degas-bitmap so only additional
> test lines must be inserted before the call. The PI3 detection
> start with lines like:
> 0 beshort 0x0002
>> 2 ubeshort&0xF000 0
> The last lines for concerned branch (RABDEMO.PI3 ELMRSESN.PI3
> GEMVIEW.PI3) looked like:
>>>>> &8 ubelong&0xff00ffFF !0
>>>>>> 0 use degas-bitmap
> So this now becomes like:
>>>>> &8 ubelong&0xff00ffFF !0
>>>>>> 6 ubeshort&0xF000 0
>>>>>>> 8 ubeshort&0xF000 0
>>>>>>>> 0 use degas-bitmap
> By first additional test many Adobe Photoshop Color swatch
> (ANPA-Farben.aco TOYO-Farbsystem.aco) with invalid third color
> palette entry (like 1319 2201 2206 21f5 2480 24db 25fd) are skipped.
> By second additional test few Adobe Photoshop Color swatch
> (FOCOLTONE-Farben.aco "PANTONE process coated.aco") with invalid
> forth color palette entry (ffff) are skipped.
>
> On 11 Sep 2022 i send patch file-5.42-images-pi1.diff for Atari
> DEGAS Elite bitmap (*.PI1). In version 5.42 the offset directive
> for file size detection was not working. In newer version 5.43 the
> file offset bug is fixed. The patch contains lines like:
>>> 4 ubeshort&0xF000 0
>>>> -0 offset x FILE_SIZE=%lld
>>>> -0 offset =32034 VARIANT_STANDARD
>>>>> 0 use degas-bitmap
>>>> -0 offset =32066 VARIANT_ELITE
>>>>> 0 use degas-bitmap
>
> The up case phrases (like FILE_SIZE VARIANT_STANDARD
> VARIANT_ELITE)( were only used for debugging or clarification
> reasons. In output for normal users this is only confusing. So i
> removed that up case messages.
>
> After applying the above mentioned modifications by patches
> file-5.43-images-degas.diff file-5.43-images-aco.diff and using
> Magdir/filesystems with Magdir/windows then all my inspected ACO
> are now described correctly. And the negative samples are not
> misidentified. This with -k option now looks like:
>
> 4096_colours.aco: Adobe Photoshop Color swatch, version 1+2,
> 4096 colors; 1st
> RGB space (0), w 0, x 0,
> y 0, z 0; 2nd
> RGB space (0), w 0, x 0,
> y 0x1111, z 0
> CHURCH.IMG: GEM Image data 224 x 170, 1 planes
> , 352 x 352 pixelsize
> DIAGRAM1.PI2: Atari DEGAS Elite bitmap 640 x 200 x 4
> , color palette 0000 0000 0777 0777 0000 ...
> FOCOLTONE-Farben.aco: Adobe Photoshop Color swatch, version 2,
> 830 colors; 1st
> CMYK space (2), w 0, x 0xffff,
> y 0xffff, z 0xffff,
> 14 chars "FOCOLTONE 1070"; 2nd
> CMYK space (2), w 0xffff, x 0,
> y 0xffff, z 0xffff,
> 14 chars "FOCOLTONE 1071"
> Faux-Spitzen.abr: data
> HKS Z Process.aco: Adobe Photoshop Color swatch, version 2,
> 86 colors; 1st
> CMYK space (2), w 0xffff, x 0xf332,
> y 0x4ccc, z 0xffff,
> 8 chars "HKS 01 Z"; 2nd
> CMYK space (2), w 0xf851, x 0xffff,
> y 0, z 0xffff,
> 8 chars "HKS 02 Z"
> Mac OS.aco: Windows Precompiled iNF, version 1.0,
> InfStyle 1, flags 0xffff0000,
> at 0xcccc, LanguageID cccc,
> at 0xcccc, at 0xffff0000
> Adobe Photoshop Color swatch, version 1,
> 256 colors; 1st
> RGB space (0), w 0xffff, x 0xffff,
> y 0xffff, z 0; 2nd
> RGB space (0), w 0xffff, x 0xffff,
> y 0xcccc, z 0
> Photo Filter Colors.aco: Adobe Photoshop Color swatch, version 1+2,
> 20 colors; 1st
> Lab space (7), w 0x1a2c, x 0xc80,
> y 0x2ee0, z 0; 2nd
> Lab space (7), w 0x1be1, x 0xc80,
> y 0x2ee0, z 0
> ReactOS-LiveCD.iso: ISO 9660 CD-ROM filesystem data
> 'REACTOS' (bootable)
> TOYO-Farbsystem.aco: Adobe Photoshop Color swatch, version 2,
> 1050 colors; 1st
> Lab space (7), w 0x10c1, x 0x15f5,
> y 0xf8b6, z 0,
> 9 chars "TOYO 0001"; 2nd
> Lab space (7), w 0x10a0, x 0x1d01,
> y 0xf829, z 0,
> 9 chars "TOYO 0002"
> bmpsuite-15col.tga: Targa image data - Map (240) 1024 x 768 x 8
> Windows Precompiled iNF, version 1.0,
> InfStyle 1,
> at 0xa800a800,, LanguageID 54fc,
> at 0xfca8fcfc, at 0xa8fcfc00
> pal1wb-blue.pi3: Atari DEGAS Elite bitmap 640 x 400 x 2
> , color palette 0777 0007 0007 0007 0007 ...
>
> I hope my diff file can be applied in future version of file
> utility.
>
> Apparently the magic for "Windows Precompiled iNF" is also too weak.
> So i will try to do this in a future session.
>
> With best wishes,
> Jörg Jenderek
> - --
> Jörg Jenderek
>
>
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYyTVtwAKCRCv8rHJQhrU
> 1jSwAJ9FcKly/FoFL9BViz/AWBJkCrJsbQCfTadNPS0lml/UutTzkvzgi5BsGYs=
> =Z/8V
> -----END PGP SIGNATURE-----
> <file-5_43-images-degas_diff.DEFANGED-137808><file-5_43-images-degas_diff_sig.DEFANGED-137809><trid-v-aco.txt.gz><file-5_43-images-aco_diff.DEFANGED-137810><file-5_43-images-aco_diff_sig.DEFANGED-137811>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20220923/6559cfd7/attachment.asc>
More information about the File
mailing list