NPD header format observations:
00h: NPD magic = "4E 50 44"
80h: "80h" (current observations indicate fixed)
83h: compressed = 01; uncompressed = 00
86h: block size indicator (see below)
8Ch - 8Fh: uncompressed data length
The length of header can be dependent upon the chosen block size. Should the data be compressed, the header length is increased by 16 bytes. At the end of the header one will find this new 16 bytes of information added when compression is used:
Bytes "0-4" : 00's
Bytes "5-8" : start offset of a block of compressed data
Bytes "9-12": length of compressed data (1-3 sets of 00's can be included at the end of compressed data block)
Bytes "13-16": 00 if compression algorithm not applied to that block of data; 01 if compression algorithm is used on that block
For example, notice in NPD_header2 JPG file (using decimal offsets in this picture), that at offsets 310-311 (decimal) the hex values are "0230", which corresponds to 560 decimal. The block starts at offset 560 decimal. Furthermore, notice the length of the compressed data in bytes is 2Ch, or 44 decimal.
The block size input, which can be an argument into programs making NPD files (e.g. -b [1,2,4,8,16,32), influences the number of blocks of compressed data. The larger arguments result in larger blocks of compressed data. So, the -b 1 argument would result in a larger number of smaller blocks as shown in the example NPD_header2 JPG file. At 86h in the header, that byte can indicate the block argument used:
-b 1 -> "04h"
-b 2 -> "08h"
-b 4 -> "10h"
-b 8 -> "20h"
-b 16 -> "40h"
-b 32 -> "80h"
If anyone is interested in understanding the reason for this input, read up on blocking factors and their influence on record (block) sizes. e..g. type "gzip blocking factor" in Google.
The green circle of hex values shows a pattern commonly found in some PS3 files. This pattern includes input used to determine were compressed data is located and the size of compressed blocks of data (a.k.a. records).