Вот не надо только с одного на другое перескакивать. ИТ в России строилось и начиналось с самоучек, без всякого интернету, и 99% учителей у учеников консультировались и до сих пор консультируются. А тут вдруг бац "Сам никогда не разберёшься по той простой причине что находясь на нулевой отметке, ты понятия не имеешь с чем именно тебе надо разбираться и в какой последовательности." - здрасти, приехали.
Еще один пример и пища для размышления. Если взять не 64 значения, а всего лишь два, и считать для них своеобразный аналог DCT то упремся в ту же проблему. Коэффициенты будут получаться в диапазоне +127.5 -128.5, что потребует на 1 бит больше для их хранения. В то же время эта пара коэффициентов будет взаимосвязана по величинам как единичный вектор. То есть чем больше значение одного из коэффициентов тем меньше возможный диапазон другого, это автоматом сокращает несущую часть битов, и благодаря тому же Хаффману возвращает к максимальным 8 битам на значение.
Также нужно не упустить пример где эти два коэффициента считаются несмотря на переполнения байта. Средний с отсечением дробной части, а разница с отсечением старшего бита. Тут также возможно восстановить значения без погрешности используя те же 8 бит. Отмасштабировать это на 64 коэффициента будет проблематично, но сделать преобразование yuv без потери и лишних бит будет возможно. Конечно, это будет не тоже самое.
Двойки просто для аналитики и наглядности не больше, можете хоть 0.5 написать в погоне за точностью все равно будут неточности. Погрешность один бит на компоненту (разница между изображением оригинальным и фильтрованным через DCT), которую можно решить используя более точную таблицу для DCT как я описал раньше.
можно убрать второе округление (оно там лишнее) и получить без погрешности, но таблицу dct лучше все же брать из документации.
dequant = (v,i) -> (v * quantMatrix[i])
результат
Справедливости ради, в jpeg используется минимум 16 битная точность для расчета DCT квантизации и последующей упаковки Хаффмана, не зависимо от входящих 8 битных компонент (по крайней мере в кодеках 90-x). Благодаря тому же Хаффману и DCT (без RLE Для нулей) объем информации не вылезет дальше оригинального размера файла, это уже говорит что в среднем байта хватает. Кроме этого в оригинальном формате есть теги описывающие начало блока 8x8, а это лишняя информация, которая помогает восстановить повреждение файла.
Было когда-то дело https://www.youtube.com/watch?v=ptiE9u-bf38
Вот не надо только с одного на другое перескакивать. ИТ в России строилось и начиналось с самоучек, без всякого интернету, и 99% учителей у учеников консультировались и до сих пор консультируются. А тут вдруг бац "Сам никогда не разберёшься по той простой причине что находясь на нулевой отметке, ты понятия не имеешь с чем именно тебе надо разбираться и в какой последовательности." - здрасти, приехали.
Демосцена
Еще один пример и пища для размышления. Если взять не 64 значения, а всего лишь два, и считать для них своеобразный аналог DCT то упремся в ту же проблему. Коэффициенты будут получаться в диапазоне +127.5 -128.5, что потребует на 1 бит больше для их хранения. В то же время эта пара коэффициентов будет взаимосвязана по величинам как единичный вектор. То есть чем больше значение одного из коэффициентов тем меньше возможный диапазон другого, это автоматом сокращает несущую часть битов, и благодаря тому же Хаффману возвращает к максимальным 8 битам на значение.
Также нужно не упустить пример где эти два коэффициента считаются несмотря на переполнения байта. Средний с отсечением дробной части, а разница с отсечением старшего бита. Тут также возможно восстановить значения без погрешности используя те же 8 бит. Отмасштабировать это на 64 коэффициента будет проблематично, но сделать преобразование yuv без потери и лишних бит будет возможно. Конечно, это будет не тоже самое.
Двойки просто для аналитики и наглядности не больше, можете хоть 0.5 написать в погоне за точностью все равно будут неточности. Погрешность один бит на компоненту (разница между изображением оригинальным и фильтрованным через DCT), которую можно решить используя более точную таблицу для DCT как я описал раньше.
можно убрать второе округление (оно там лишнее) и получить без погрешности, но таблицу dct лучше все же брать из документации.
результат
Справедливости ради, в jpeg используется минимум 16 битная точность для расчета DCT квантизации и последующей упаковки Хаффмана, не зависимо от входящих 8 битных компонент (по крайней мере в кодеках 90-x). Благодаря тому же Хаффману и DCT (без RLE Для нулей) объем информации не вылезет дальше оригинального размера файла, это уже говорит что в среднем байта хватает. Кроме этого в оригинальном формате есть теги описывающие начало блока 8x8, а это лишняя информация, которая помогает восстановить повреждение файла.
Ну и главное не будем изобретать велосипед: https://ru.wikipedia.org/wiki/JPEG-LS