gfcwfzkm / pif-image-format Goto Github PK

FYI, support for parsing PIF was added to Kaitai Struct a little while ago, see:

https://github.com/kaitai-io/kaitai_struct_formats/blob/master/image/pif.ksy

There is a link to PIFtestENV/README.md in C Library/examples/README.md:

but the C Library/examples/PIFtestENV/ directory has no README.md.

I suspect it should be the number of bytes, since the "important" resources seem to prefer this semantics, but it's not 100% clear because some files quite explicitly suggest otherwise:

Number of bytes:

• test_images/Lenna/Lenna_Indexed16_RGB565.pif (ColorTableSize is 32, which matches the number of bytes)

• PIF-Image-Format/Image Converter/PIFGUI.py

  Lines 772 to 779 in 74775a6

  	elif ((ImageType & 0xFF00) == PIFFormat.ImageTypeINDEXED.value):
  	if (ImageType == PIFFormat.ImageTypeIND24.value):
  	ColTableColors = ColorTableSize // 3
  	elif (ImageType == PIFFormat.ImageTypeIND16.value):
  	ColTableColors = ColorTableSize // 2
  	else:
  	ColTableColors = ColorTableSize
  	ColorTable = np.zeros(ColorTableSize, dtype=np.uint8)

• PIF-Image-Format/Image Viewer/PIF Viewer/Viewer.cs

  Lines 123 to 137 in b0cee7f

  	else if ((ImageType & 0xFF00) == PIFFormat.ImageTypeINDEX)
  	{
  	// Note the amount of colors, depending on the selected indexed format
  	if (ImageType == PIFFormat.ImageTypeIND24)
  	{
  	ColorTableColors = Convert.ToUInt16(ColorTableSize / 3);
  	}
  	else if (ImageType == PIFFormat.ImageTypeIND16)
  	{
  	ColorTableColors = Convert.ToUInt16(ColorTableSize / 2);
  	}
  	else
  	{
  	ColorTableColors = ColorTableSize;
  	}

• https://github.com/WerWolv/ImHex-Patterns/blob/3edc6ea17270d9befef95d634d1f0318a9c8d4a7/patterns/pif.hexpat#L46-L57

Number of entries:

• Specification/PIF Format Specification.pdf

  Color Table Size: Index size of the color table, only used in Indexed mode, otherwise zero.

  To me, "index size" suggests the number of entries, not bytes. I understand "index size" as the size of the index set, i.e. "the maximum color table index that a pixel can refer to" plus 1 (because indices are from 0 to the number of color table entries minus one).

• PIF-Image-Format/C Library/pifdec.h

  Line 68 in 74775a6

  uint16_t colTableSize; // Color Table Size in Entries

  typedef struct {
        // ...
  	uint16_t colTableSize;		// Color Table Size in Entries
        // ...
  }pifINFO_t;

  I know that just because there's some field in pifINFO_t doesn't mean the actual file format uses the same semantics (for example see imageType, which has different values in pifINFO_t than the file format uses). But in this case, colTableSize is copied verbatim from the input .pif file without any conversion:

  PIF-Image-Format/C Library/pifdec.c

  Line 359 in 74775a6

  p_PIF->pifInfo.colTableSize = _read16(p_PIF->pifFileHandler);

  And later in the code it's indeed treated as a number of entries (so it's not a lying code comment):

  PIF-Image-Format/C Library/pifdec.c

  Lines 421 to 425 in 74775a6

  	if (colorCounter >= (p_PIF->pifInfo.colTableSize * ColorTablePixelSize))
  	{
  	// No more colors to read from the color table
  	break;
  	}

I'm working on a project where I want to have a server component (python) that ships images to a embedded LCD system (based around a ESP32).

Currently, I'm just using raw bitmaps, but this project looks like it'd be pretty handy. On the other hand, the current code for generating PIF images only seems to live in the converter GUI file.

This seems like the kind of thing that should be extracted out to a proper library, and be available somewhere like PyPi. Or at minimum in a separate file so it can be somewhat easily vendored.

I'd be happy to handle setting all that up, if you're OK with that, but I don't want to just jump in and start pushing stuff to PyPi without at least talking first.

The PDF of the specification seems to suggest that the file signature is "PIL" but the test files use "PIF".