[Android Software Development] iBotPeaches:
Didn't really read enough of that, but it looks like its the same problem of the version qualifier being added. This commit should fix it.

If they are a new image format. They will have to be researched like 9patches. 9patches are easy because you can read AOSP documentation for this blurp of text.

/** ********************************************************************
* PNG Extensions
*
* New private chunks that may be placed in PNG images.
*
*********************************************************************** */

/**
* This chunk specifies how to split an image into segments for
* scaling.
*
* There are J horizontal and K vertical segments. These segments divide
* the image into J*K regions as follows (where J=4 and K=3):
*
* F0 S0 F1 S1
* +-----+----+------+-------+
* S2| 0 | 1 | 2 | 3 |
* +-----+----+------+-------+
* | | | | |
* | | | | |
* F2| 4 | 5 | 6 | 7 |
* | | | | |
* | | | | |
* +-----+----+------+-------+
* S3| 8 | 9 | 10 | 11 |
* +-----+----+------+-------+
*
* Each horizontal and vertical segment is considered to by either
* stretchable (marked by the Sx labels) or fixed (marked by the Fy
* labels), in the horizontal or vertical axis, respectively. In the
* above example, the first is horizontal segment (F0) is fixed, the
* next is stretchable and then they continue to alternate. Note that
* the segment list for each axis can begin or end with a stretchable
* or fixed segment.
*
* The relative sizes of the stretchy segments indicates the relative
* amount of stretchiness of the regions bordered by the segments. For
* example, regions 3, 7 and 11 above will take up more horizontal space
* than regions 1, 5 and 9 since the horizontal segment associated with
* the first set of regions is larger than the other set of regions. The
* ratios of the amount of horizontal (or vertical) space taken by any
* two stretchable slices is exactly the ratio of their corresponding
* segment lengths.
*
* xDivs and yDivs are arrays of horizontal and vertical pixel
* indices. The first pair of Divs (in either array) indicate the
* starting and ending points of the first stretchable segment in that
* axis. The next pair specifies the next stretchable segment, etc. So
* in the above example xDiv[0] and xDiv[1] specify the horizontal
* coordinates for the regions labeled 1, 5 and 9. xDiv[2] and
* xDiv[3] specify the coordinates for regions 3, 7 and 11. Note that
* the leftmost slices always start at x=0 and the rightmost slices
* always end at the end of the image. So, for example, the regions 0,
* 4 and 8 (which are fixed along the X axis) start at x value 0 and
* go to xDiv[0] and slices 2, 6 and 10 start at xDiv[1] and end at
* xDiv[2].
*
* The colors array contains hints for each of the regions. They are
* ordered according left-to-right and top-to-bottom as indicated above.
* For each segment that is a solid color the array entry will contain
* that color value; otherwise it will contain NO_COLOR. Segments that
* are completely transparent will always have the value TRANSPARENT_COLOR.
*
* The PNG chunk type is "npTc".

I doubt you can find a whitepaper for QMGs, but the first step is to understand the file format. I have too many Apktool bugs to worry about to focus on that, but if someone can start gathering information on the internal struct of a QMG we might be able to add a decoder for it. Maybe just email Samsung Developer center / whatever its called and ask if they will give any information of the structure of it. Always worth a shot.

Well right now your options are wait or help fix it. As I just discovered minutes ago in #713, this appears to be Apktool at fault in decoding resources improperly. I'm just guessing here, but I bet those resources would appear in a dump of the resources (aapt d resources apk_name.apk | grep 'resource id'). The next step is to figure out which resources are being decoded improperly and why.