Skip to main content
_
_videohead_
Known Participant
November 23, 2006
Question

Reading/Parsing a Photoshop generated TIFF

  • November 23, 2006
  • 6 replies
  • 1259 views
Hi -<br /><br />I'm trying to read a layered TIFF image generated by Photoshop, and according to the TIFF Technical notes (http://partners.adobe.com/public/developer/en/tiff/TIFFphotoshop.pdf) page 11 , the ImageSourceData section should start with the null terminated character sequence, "Adobe Photoshop Document Data Block". However on, reading I get:<br /><br /><xapMM:DocumentID>adobe:docid:photoshop:688c7d73-5fb3-11db-97df-d46af1c0ee86</xapMM:DocumentID><br /> </rdf:Description><br /><br /></rdf:RDF><br /></x:xapmeta><br /><br />// lots of space<br /><br /><?xpacket end='w'?> <br /><br />Before I get the 4 byte signature, '8BIM' (I had to read till I encountered the null character to get all that). Also, the next 4 bytes I isn't aren't the characters, 'Layr', 'LMsk', 'Patt', or 'Anno' as the docs say. <br /><br />Has Adobe changed the structure of its TIFF image? Thanks,<br /><br />- Olumide
This topic has been closed for replies.

6 replies

_
_videohead_Author
Known Participant
November 30, 2006
Got it (I think)! The problem has had to do with the way I was unpacking the data.

Reading the spec c a r e f u l l y is always a good idea :-D .
_
_xbytor_
Known Participant
November 30, 2006
videohead{at_char_here}mail.com wrote:
> Got it (I think)! The problem has had to do with the way I was unpacking the data.
>
> Reading the spec c a r e f u l l y is always a good idea :-D .

Then read it again :)

-X
_
_videohead_Author
Known Participant
November 28, 2006
According to the Photoshop file format specification (which that Photoshop's layered TIFFs are based on), the channel ID -1 indicates the transparency mask, 0 for red, 1 for green etc.

On blank and non blank protions, I guessed thats done to keep file sizes smaller, but and thats why I calculated
(layerRecords.top - layerRecords.bottom) * (layerRecords.right - layerRecords.left). In each case, the answer did not equal the pixel count I got after decompressing the RLE data.

... I wonder why the transparency channel pixel count isn't equal to the the pixel count values I got for the other layers? Is this normal?

Thanks
Chris Cox
Chris Cox
Legend
November 27, 2006
Channel -1?
Normally computer arithmetic starts at zero....

You could be using the wrong compression scheme or otherwise are off in the data somewhere.

Also, layers can write only the non-blank potions (keep the file a lot smaller).
That's why each layer has another rect associated with it.
_
_videohead_Author
Known Participant
November 27, 2006
I've finally got my program to the point where it is able to read and decode RLE (Packbits) compressed pixel data by layer. Here's a sample output of my program's pixel count per channel per layer (after decompression of RLE)

// Layer 1
[Channel -1] Pixel count: 31381
[Channel 0] Pixel count: 29728
[Channel 1] Pixel count: 29728
[Channel 2] Pixel count: 29728

// Layer 2
[Channel -1] Pixel count: 61530
[Channel 0] Pixel count: 52202
[Channel 1] Pixel count: 52202
[Channel 2] Pixel count: 52202

// Layer 3
[Channel -1] Pixel count: 71170
[Channel 0] Pixel count: 55406
[Channel 1] Pixel count: 55406
[Channel 2] Pixel count: 55406

Here's the question. I thought the pixel count for each was supposed to be the equal to: image_width * image_height ??? Also, these pixel counts are not equal to:
(layRecords->bottom - layRecords->top) * (layRecords->right - layRecords->left)

... in my case, it isn't :-( . My image is 600 x 600 .

Thanks.
_
_videohead_Author
Known Participant
November 23, 2006
Got it, thanks.

All I had to do was to read the offset value of the ImageSourceData tag.
Chris Cox
Chris Cox
Legend
November 23, 2006
You're off by a few bytes in reading the data.

What you show is partway into the XMP data block.
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices