Войти
ПрограммированиеФорумГрафика

Корректный алгоритм декомпрессии *.dds (DXT5) (6 стр)

Страницы: 1 2 3 4 5 6
#75
12:15, 2 окт. 2012

RPGman
> Оказывается, погрешностей при вычислених для ТС достаточно, чтобы реализации
> одного и того же алгоритма называть разными алгоритмами.

о погрешностях стоит рассуждать когда один и тот же алгоритм рассчёта упирается в технические возможности (например вместимость чисел с плавающей точкой) и существуют незначительные отличия. Здесь мы имеем дело с принципиально разными подходами в рассчётах. Есть большая разница между Round(X/31*255) и (X << 3) | (X >> 2). Чисто практически разница колеблется максимально в диапазоне +-4. Но на 5-8 битном пространстве это слишком непозволительная "погрешность"


#76
12:28, 2 окт. 2012

DevilDevil
> Есть большая разница между Round(X/31*255) и (X << 3) | (X >> 2).
Понятно, что 255.0*x/31.0 - правильное масштабирование 5-битного значения до 8-битного, а (x<<3)|(x>>2) - дешевый целочисленный способ родить шум там, где его не было.
Алгоритма декодирования оно никак не меняет. И как там именно будет выводить карточка - зависит от стоимости железяки, и абсолютно неважно.

#77
12:31, 2 окт. 2012

RPGman
> И как там именно будет выводить карточка - зависит от стоимости железяки, и
> абсолютно неважно.

если бы твоей целью было разобраться в вопросе, а не умничать на форумах, ты бы больше вчитывался в слова ТС
мы склоняемся к мнению, что DXT декодируется на всех GPU ОДИНАКОВО

и как показывает практика (отчёт), это не "255.0*x/31.0", а именно "(x<<3)|(x>>2)"
от тебя было бы больше толку, если бы ты просто молчал

#78
12:55, 2 окт. 2012

DevilDevil
> ты бы больше вчитывался в слова ТС
> мы склоняемся к мнению,
Мы, наше императорство? :)

>Чисто практически разница колеблется максимально в диапазоне +-4
Разница между первым и вторым  +- 1 отсчет в восьмибитной шкале. Как ты получил +-4 ?

> и как показывает практика (отчёт), это не "255.0*x/31.0", а именно "(x<<3)|(x>>2)"
И кому какая разница, как оно в видухе?
(x<<3)|(x>>2) врет, округляя не до ближайшего целого а в сторону ближайшей границы шкалы. Некорректно, зато дешево.

На досуге нарисуй табличку квадратов отклонений. Впрочем, ты же не снизойдешь. Держи готовую: http://ideone.com/R5rLA

#79
13:13, 2 окт. 2012

Мне вот интересно...
От GPU при выборки получаем тип float,  сравнивают int.
Вопрос кто виновин в округлении в int?

#80
14:15, 2 окт. 2012

RPGman
> Мы, наше императорство? :)

люди, которые тестировали утилиту и получили везде равенство GPU вариантам

RPGman
> Разница между первым и вторым +- 1 отсчет в восьмибитной шкале. Как ты получил
> +-4 ?

кроме 5битных, есть 6битные и 8битные альфа

Чисто практически разница колеблется максимально в диапазоне +-4. Но на 5-8 битном пространстве это слишком непозволительная "погрешность"

ещё раз говорю - вчитывайся в слова ТС


susageP
> Мне вот интересно...
> От GPU при выборки получаем тип float, сравнивают int.
> Вопрос кто виновин в округлении в int?

всё круто, предположение правильное
но если бы опять таки ты посмотрел отчёты и мои сообщения, понял бы, что DXT распаковывается первоначально в int. Потому как не может float "255.0*x/31.0" во всех тестах быть равен int "(x<<3)|(x>>2)"

#81
14:49, 2 окт. 2012

DevilDevil
> кроме 5битных, есть 6битные
6-битный цвет:  http://ideone.com/rU5ML , разница +- 1 отсчет по итоговой шкале.

> и 8битные альфа
Исходные два значения для альфы уже 8-битные.
Какими читами они будут интерполированы - опять же для алгоритма неважно.

> понял бы, что DXT распаковывается первоначально в int
Откуда дровишки, что в gpu это так?
Расскажи, как ты достал инт, если семплинг из текстуры возвращает флоат?
Расскажи, как ты отличил погрешности при семплинге текстуры от погрешностей округления финального фрагмента при рендере в текстуру/на экран?
Разжуй тезис важности софтверного декодирования dxt, один в один воспроизводя погрешности конкретных gpu?

> ещё раз говорю - вчитывайся в слова ТС
А чего говоришь о себе в третьем лице? :)

#82
15:08, 2 окт. 2012

RPGman

мне лень тебе расписывать вещи, которые многократно расписаны в этой ветке
меньше слов, больше дела

как минимум просто ради приличия сравни отчёт сквиш и gpu

#83
15:13, 2 окт. 2012

DevilDevil
> мне лень тебе расписывать вещи, которые многократно расписаны в этой ветке
Я внимательно перечитал всю ветку. Ответов на предыдущие вопросы тут нет.

>меньше слов, больше дела
Так заради правды напрягись. Пока что не вижу никакого дела, одна только навязчивая идея угадать как именно gpu округляет.

#84
15:19, 2 окт. 2012

RPGman

пока ты не научишься ознакомиться сначала с тем, что тебе дают
и не откроешь для себя Beyond Compare
объяснять тебе что-то нет смысла
мне кажется с этой задачей сможет справиться даже пятиклассник

#85
16:29, 2 окт. 2012
Извините, что вмешиваюсь DevilDevil, RPGman, но вы откровенно гоните друг на друга.

Я результаты тестов не смотрел. Чисто из любопытства, то что написано в спеках таки совпадает с тем что делает железо? Я имею виду картинку, или идентичность не возможна, а получается некий довольно близкий, приемлемый вариант ?
#86
17:45, 2 окт. 2012

KKH

в спеках описано очень схематично, обобщённо
никакого конкретного рабочего кода нет

исходя их этих "спеков" каждый реализует "как левая нога пожелает". В целом результат похож
но я ещё не видел, чтобы результат был как на gpu

почему эти +-5 важны
скорее всего потому, что DXT - достаточно требовательный формат. Существуют быстрые алгоритмы сжатия, но они дают отвратительный результат. Существуют сложные и медленные алгоритмы (например squish, NVTT) которые дают результат очень похожий на оригинал. Чтобы оценить насколько важны эти погрешности - достаточно взглянуть на алгоритмы компрессии. Например в NVTT для сжатия альфа используют брутфорс с поиском наименьшей погрешности. Очень тяжёлый алгоритм. Ну и какой смысл от этого брутфорса, если они элементы палитры не могут нормально заполнить? Компрессия цвета - тоже ОЧЕНЬ тяжёлая функция, тоже брутфорс почти. И тоже ищут наименьшие погрешности. И тоже плюют на правильную палитру. Уж если я трачу секунды жизни на компрессию DXT,  я хочу быть уверен, что они действительно выжимают максимум из качества. К тому же вопрос принципа. Если я просматриваю DXT текстуру - я хочу видеть как ДЕЙСТВИТЕЛЬНО она интерпретируется видеокартой, а не как кому-то захотелось её интерпретировать.

#87
19:49, 2 окт. 2012

DevilDevil
> в спеках описано очень схематично, обобщённо
> никакого конкретного рабочего кода нет
>
> исходя их этих "спеков" каждый реализует "как левая нога пожелает".

Покажи в спеках, а лучше в стандарте какие части можно реализовать по разному  "как левая нога пожелает"?

#88
9:56, 3 окт. 2012

susageP
> Покажи в спеках, а лучше в стандарте какие части можно реализовать по разному
> "как левая нога пожелает"?

а самому то посмотреть не судьба ?

RGB0 = UNSIGNED_SHORT_5_6_5 color0
RGB1 = UNSIGNED_SHORT_5_6_5 color1 

bits   = bits_0 + 256 * (bits_1 + 256 * (bits_2 + 256 * bits_3))
code(x,y) = bits[2*(4*y+x)+1 .. 2*(4*y+x)+0]

RGB0,              if color0 > color1 and code(x,y) == 0
RGB1,              if color0 > color1 and code(x,y) == 1
(2*RGB0+RGB1)/3,   if color0 > color1 and code(x,y) == 2
(RGB0+2*RGB1)/3,   if color0 > color1 and code(x,y) == 3

RGB0,              if color0 <= color1 and code(x,y) == 0
RGB1,              if color0 <= color1 and code(x,y) == 1
(RGB0+RGB1)/2,     if color0 <= color1 and code(x,y) == 2
BLACK,             if color0 <= color1 and code(x,y) == 3

Начнём с того, как распаковывается RGB из 16 битного цвета
Вообще я часто встречал обычное смещение B << 3, G << 2, R << 3. Собственно в коде, который привёл haper - так и делают (откуда взял - не знаю). Однако в других местах (в том числе и в GPU) делается двойным смещением и логическим сложением.

Далее. (2*RGB0+RGB1)/3, (RGB0+2*RGB1)/3, (RGB0+RGB1)/2
Казалось бы всё очевидно. Но:
1) в DevIL к примеру добавляется 1 для "правильного округления"
2) во всех остальных местах которые я видел "округления" не делается
3) по спекам для рассчёта третьего и четвёртого элемента палитры используют распакованные цвета RGB0 и RGB1. Однако, как показывает отчёт, всё это хрень собачья. И для рассчётов берутся нераспакованные 565 цвета. Например "(RGB0+RGB1)/2" на самом деле выглядит так (только G ещё не понял как считается):

  // типа (a + b) / 2
  palette[2].r = ((a.r+b.r) << 2) | ((a.r+b.r) >> 3);
  palette[2].g = ?
  palette[2].b = ((a.b+b.b) << 2) | ((a.b+b.b) >> 3);

Страницы: 1 2 3 4 5 6
ПрограммированиеФорумГрафика

Тема в архиве.