Reading, writing and previewing abr-files (brushes) - How?

[Heimdaal]

I can't find any information in the manual about how to work with brush files - so how exactly does people approach this?

I have an idea for a tool I want to make but I'm blocked in regards to the technical approach on how to actually work with brush files.

I've seen examples of custom-made brush panels so I know it's entirely possible - but I can't seem to find any actual info about it. I've tried contacting these people but they are either busy or they simply do not want to share this info out of fear that I will develop some competing tool (which I will not - my idea goes beyond just a brush manager). What I need to be able to do is

1) Read an abr file

2) Display the brush (as a thumbnail)

3) Write an abr-file

[JJMack]

Is that not what the Preset Manager does?

[Heimdaal]

Correct.

Do you have the source code?

[Guest]

Here is some information about the .abr file structure:

- A brush file starts with a header: version (2-byte big-endian integer) followed by sub-version (2-byte big-endian integer).

- Atfer the header lies a sequence of sections organized by key: 'samp', 'patt' and 'desc' (I'm not sure if their order is fixed though).

Each of them follows the same structure:

   - Photoshop resource signature ('8BIM')

   - 4-character key ('samp' or 'patt' or 'desc')

   - length of data (4-byte big-endian integer)

   - data (variable size)

- The 'samp' section data (if not empty) represents a series of sampled brushes with unique identifiers (UUID) referenced in the descriptor.

- The 'patt' section data (if not empty) represents a series of patterns (used for textures) with unique identifiers (UUID) referenced in the descriptor.

- The 'desc' section data is a flatten descriptor which can be decoded using the fromStream method.

I already wrote a very simple script which uses this information, but unfortunately it doesn't parse what you are interested in, i.e. the brush previews...

<http://www.tonton-pixel.com/blog/wp-content/uploads/test-parse-abr-file.zip >

An old version of the "Adobe  Photoshop®6.0 File Formats Specification" document has a section about brushes:

<http://oldschoolprg.x10.mx/downloads/ps6ffspecsv2.pdf >

There is an open-source project called ABR Viewer:

<abrViewer.NET - Browse /abrViewer.NET_2.0/abrViewer.NET 2.0 at SourceForge.net >

which provides relevant information about the "8BIMsamp" section in the file "ScanningProcess.cs" inside the "abrViewerNET20_source.zip" archive.

Also, the "8BIMpatt" section data structure may be similar to the way patterns are stored at the beginning of a styles file.

See "Photoshop Styles File Format" in <http://www.tonton-pixel.com/blog/documentation/>

HTH...

[Heimdaal]

This is what I feared - having to write everything from scratch myself.

Also no file previewer which is a big bummer I'll read those links though.

[rob art | illustration]

I'm looking to pull BrushTip info from an ABR, but have hit a wall. I get the data, can get the name the location of the image, but it just shows a zebra pattern and not the brushTip!
I've looked at most of this info as well. I am missing something.

[jazz-y]

If you get a "zebra", it means that you got to the sample block correctly, but you are decoding it incorrectly. I have not worked with the abr format, but I suspect that there is some compression algorithm, most likely the simplest one like PackBits (the first byte encodes the number of repetitions of the byte following it).

Create a simple texture (for example, a 16x16 square with alternating blocks of black and white pixels within it), this will make it easier to find the right decoding algorithm.

UPD, i looked at a few samples of brushes, yes, indeed, you can see that some version of PackBits is used there. For example, a 16x16 brush sample is encoded as follows:

fd ff fd 00 fd ff fd 00 fd ff fd 00 fd ff fd 00
fd ff fd 00 fd ff fd 00 fd ff fd 00 fd ff fd 00
fd 00 fd ff fd 00 fd ff fd 00 fd ff fd 00 fd ff
fd 00 fd ff fd 00 fd ff fd 00 fd ff fd 00 fd ff
fd ff fd 00 fd ff fd 00 fd ff fd 00 fd ff fd 00
fd ff fd 00 fd ff fd 00 fd ff fd 00 fd ff fd 00
fd 00 fd ff fd 00 fd ff fd 00 fd ff fd 00 fd ff
fd 00 fd ff fd 00 fd ff fd 00 fd ff fd 00 fd ff

 i.e 1st bit FF+2 (257) - fd (253) = 4, so fd ff = "repeat ff x4"

I checked this on several brushes and the compression principle is the same everywhere, except... except for cases when the brush contains colors that are 1-2 bytes in a row:

ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff
ff 00 ff ff 00 00 ff ff ff 00 00 00 ff ff ff ff

here we see (even from the code preview) that the bytes literally repeat the sample pixels.

If you have figured out the file structure, then perhaps somewhere in the area of the bits indicating the brush size there is a mark about the presence or absence of compression (or this should be judged indirectly, by comparing the length of the sample bytes with the size of the image)