JPEG: YCrCb <-> RGB точность преобразования

Question

Я реализовал RGB-> YCrCb и ycrcb-> RGB преобразование с использованием формул преобразования JPEG из
http://www.w3.org/Graphics/JPEG/jfif3.pdf
(то же самое на: http://en.wikipedia.org/wiki/YCbCr (преобразования JPEG)).

При проверке правильности результатов (оригинал-> YCrCb-> RGB) некоторые пиксели отличаются друг от друга, например, 201-> 200.

Средний процент ошибок точности составляет 0,1%, поэтому он не критичен.

/// converts RGB pixel to YCrCb using { en.wikipedia.org/wiki/YCbCr: JPEG conversion } 
ivect4 rgb2ycrcb(int r, int g, int b) 
{ 
    int y = round(0.299*r + 0.587*g + 0.114*b) ; 
    int cb = round(128.0 - (0.1687*r) - (0.3313*g) + (0.5*b)); 
    int cr = round(128.0 + (0.5*r) - (0.4187*g) - (0.0813*b)); 
    return ivect4(y, cr, cb, 255); 
} 
/// converts YCrCb pixel to RGB using { en.wikipedia.org/wiki/YCbCr: JPEG conversion } 
ivect4 ycrcb2rgb(int y, int cr, int cb) 
{ 
    int r = round(1.402*(cr-128) + y); 
    int g = round(-0.34414*(cb-128)-0.71414*(cr-128) + y); 
    int b = round(1.772*(cb-128) + y); 
    return ivect4(r, g, b, 255); 
} 

Я использую круглую формулу:
этажа ((х) + 0,5)

При использовании других типов округления, например, float (int) или std :: ceil(), результаты еще хуже.

Итак, Есть ли способ сделать YCrCb < -> Преобразование RGB без потери точности?

Answer 1

Проблема не в режимах округления.

Даже если вы преобразовали константы с плавающей запятой в отношения и использовали только целую математику, вы все равно увидите разные значения после инверсии.

Чтобы узнать, почему, рассмотрим функцию, где я говорю вам, я собираюсь сдвинуть числа от 0 до N в диапазон от 0 до N-2. Дело в том, что это преобразование просто не имеет обратного. Вы можете представить его более или менее точно с вычислением с плавающей запятой (f(x) = x*(N-2)/N), но некоторые из соседних значений будут сопоставляться с одним и тем же результатом в целочисленной математике (принцип пигментных отверстий!). Это упрощение и «сжимает» диапазон, но то же самое происходит в произвольных аффинных преобразованиях, подобных тому, который вы используете.

Если у вас были r, g, b в плавающей запятой и сохранялся таким образом, пока вы не квантовали на целое число, это было бы другой историей, но в целых числах обязательно обязательно увидите разницу между исходным и обратным ,

Answer 2

Другая проблема заключается в том, что между rgb и YCbCR не существует сопоставления от 1 до 1. Имеются значения YCbCr без соответствующих значений RGB и RBG без соответствующих значений YCbCR.

Answer 3

Только приблизительно 60% всех значений RGB могут быть представлены в пространстве YCbCr при использовании того же количества бит для обоих триплетов. Это означает, что наибольший урон происходит в RGB-> YCbCr, когда вы берете триммер RGB 3 * 8 бит, конвертируете и округлите его до 3 * 8 бит точности. Хитрость заключается в том, чтобы хранить триплет YCbCr с более высокой точностью, пока не наступит время для перехода на DCT. Там все равно необходимо масштабировать данные, поэтому вы можете сделать это, например. 16 бит * 16 бит -> MSB16 умножается, которые хорошо поддерживаются различными наборами инструкций SIMD.

В декодере это обратное: результаты обратного DCT должны храниться с большей точностью, пока не наступит время для преобразования YCbCr-> RGB.

Это не делает процесс без потерь, но для JPEG он может купить несколько дБ PSNR на крайнем высоком уровне шкалы качества, то есть где разница не может быть видна невооруженным глазом, но может быть измеренным.

Answer 4

Да, предположительно JPEG XR определяет преобразование цвета, которое является обратимым. Код является открытым исходным кодом, если вы хотите подробно рассказать о том, как они это делают.Этот метод свободно описан на странице Wiki-страницы, с которой я связан.

Также this SO post может дать вам некоторые идеи.