High-quality JPEGs may store quantization divisors that exceed 255, using two bytes each. Today you read a precision-1 table, the other DQT format, so your parser handles both.
Read a precision-1 (16-bit) quantization table, where each of the 64 values is a two-byte big-endian number.
When a quantization divisor would not fit in a single byte - anything above 255, common in very high or very low quality settings - the table is stored at precision 1, with each of the 64 entries taking two big-endian bytes. So 00 10 is 16 and 01 2C is 300. A precision-1 table therefore occupies 128 bytes rather than 64, and your DQT reader must branch on the precision nibble you split out two lessons ago to know which width to read.
That the value type is already a 16-bit integer means both formats land in the same table shape; only the reading loop differs. With this in place your quantization parsing is complete for both precisions, and the divisors are ready for the dequantize step - a plain multiply - that you will reach once the entropy decoder has produced coefficients to multiply.
// for Pq==1, each value is 2 bytes big-endian: hi<<8 | lo.// 64 values -> 128 bytes consumed.func readQuant16(b []byte, pos int) (t QuantTable, next int) {// value = uint16(b[pos])<<8 | uint16(b[pos+1])}