768 byte Color Table

[Ghoul Fool]

Techical question on colour tables

I'm I right in thinking that 768 byte color tables are from legacy versions of Photoshop?

I've tried with various coloured images (6 colours - 256 colours with/without transpaency) to recreate one that's 768 bytes long. But all were 772 bytes. 

The documentation is minimal at best: 

www.adobe.com/devnet-apps/photoshop/fileformatashtml 

As always, answers on a piece of toast!

[Semaphoric]

Color tables are for images in Indexed Color mode, which have a maximum of 256 colors. It's a relic, but still has uses.

[Ghoul Fool]

I'm a relic, but I still have my uses.

[Test Screen Name]

I don't know how you're creating it, but 256 x 3 + 768. If you put the raw RGB data from 256 samples (each 3 bytes), it can't be any other size. Transparency not relevant. 

[jazz-y · Accepted solution]

No.

When you see a table that is 772 bytes long, the last 2 bytes is number of colors in palette (00 ff), previous 2 bytes is transparency marker (01 00), also 3 bytes before the transparency marker - the color of transparency (ff ff ff ). That is, in fact, the table with the transparency option enabled consists of 255 colors, not 256.

If this checkbox is disabled, the file size will be 768 bytes.

[Ghoul Fool]

I'm still getting 772 bytes regardless of transparency

[jazz-y]

Are you using a previously saved file that has been converted to indexed colors? This option may have been set before (the transparency marker will be in the table even if the file does not have transparent pixels). Try converting it to RGB and convert to indexed colors again.

I don't fully understand what you are trying to do, but if you want to read *.acl file, just make sure its size is a multiple of 3 bytes. Or sequentially read three bytes and each time make sure that the rest of the file is not equal to 4 (this will be a sign of the presence of a transparency marker)

[Ghoul Fool]

These are RGB images converted to index colour. I've written ascript to read/write out the .ACT in the order that I want (rather than Photoshop's rather random order) It works and I've tested it out on several images.

My point of concern is/was making sure that it deals with 768 byte ACTs as well as 772 bytes ones. 

I couldn't manage to produce any 768 byte ones - but did manage to find some from an archive circa 2002 😄 ! Hence me thinking they were a legacy thing.

Does that make sense now?

[jazz-y]

I have explained to you the difference between 768 and 772 bytes long color tables above. The new Photoshop can easily create a 768-byte color table if you turn off the use of transparency when converting to indexed colors.

[Ghoul Fool]

Thanks for the video. I understand. But I now realise the difference (which is probably a failure to communicate on my side): If you use less than 256 colours - say only 32 to start with (rather than a true colour image with thousands of colours) they'll be 772 bytes, regardless of whether you include transparency.

Mystery solved 🙂

[jazz-y]

If the table contains less than 256 colors, then the logic changes - the last 2 bytes are always FF FF, the previous 2 bytes are the number of colors in the palette.

In other words, if the file is 768 bytes, then everything is simple - it always contains 256 colors without transparency.

If the file is 772 bytes, then read the last 2 bytes of the file:

1. If this is 00 FF, then we are dealing with a palette of 255 colors + transparency

2. If it's FF FF, then it's a palette with less than 256 colors. Read the previous two bytes to get the number of colors in the palette.

P.S. I don't have a color table with less than 256 colors from previous versions of Photoshop, but I admit that they could be 678 bytes (i.e. the limited palette marker at the end of the file was not used, instead all unused colors were simply filled with zeros). I tried manually deleting the last 4 bytes in the palette-limited file, and Photoshop accepted the file with no problem.

[r-bin]

Не совсем верно, вроде ).

Не макрер, а индекс. Читаем, смотрим, соображаем... ))

[jazz-y]

Да 🤦👍