Приветствую Вас Гость | RSS


Главная страница » Ошибка в просчете палитры? - ZX-Форум » Регистрация » ВходЧетверг
2024-03-28
11:49:06
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
  • Страница 1 из 1
  • 1
ZX-Форум » Unreal Speccy переехал http://dlcorp.nedopc.com/viewforum.php?f=8 » Ошибки » Ошибка в просчете палитры?
Ошибка в просчете палитры?
moroz1999Дата: Воскресенье, 2009-08-02, 13:55:11 | Сообщение # 1
Юзер
Группа: Человеки
Сообщений: 2
Репутация: 0
Статус: Offline
В общем, если я не ошибаюсь, то в процедуре расчета палитры закралась ошибка.
При расчете палитры результат делится не на 255, а на 256, из-за чего реальные RGB цвета высчитываются с небольшой погрешностью.
Экспериментальным путём подтвердил, что, например, при выставленной в настройках палитре от pulsar, ярко-красный цвет получается #FE0000 вместо #FF0000.

Вот формула из конфига:
; Rnn - matrix for post-processing:
; real_Red = (Red*R11 + Green*R12 + Blue*R13) / 0x100
; real_Green = (Red*R21 + Green*R22 + Blue*R23) / 0x100
; real_Blue = (Red*R31 + Green*R32 + Blue*R33) / 0x100

Вот палитра от Pulsar:
pulsar=00,76,CD,E9,FF,9F:FF,00,00;00,FF,00;00,00,FF

По формуле для ярко-красного выходит следующее:
real_Red = (0xFF*0xFF + 0*0 + 0*0) / 0x100 = 0xFE
И это более чем логично - деля 0xFF*0xFF на 0x100, мы никогда не получим 0xFF.
Следовательно, в формуле - логическая ошибка и 0x100 должно быть поменяно на 0xFF.

Я никогда не писал на C++, поэтому проверить свои измышления не смогу, но, руководствуясь своей интуицией, могу сказать, что изменения надо вносить в draw.cpp, линии 220, 221, 222. Исходники брал us0.37.3-src.rar

 
deathsoftДата: Понедельник, 2009-08-03, 00:38:05 | Сообщение # 2
Retry, Abort, Ignore?
Группа: Человеки
Сообщений: 1587
Репутация: 9
Статус: Offline
Ошибки там никаокй нету, это обычное математическое нормирование, делится на размер диапазона 0-255 (всего целых чисел там 256). А FF там не получить из за погрешности расчета в 8битной арифметике, более того - там еще и переполнение возможно, когда все коэффициенты FF. От этого никуда не дется, либо надо считать не целочисленно и не в 8бит.

Коэффициент 255 в матрице не соответствует единице, для единицы в матрице должно быть 256.

[Ro] [R11 R12 R13] [Ri]
[Go]=[R21 R22 R23]*[Gi]
[Bo] [R31 R32 R33] [Bi]

В случае преоразования 1 в 1 матрица должна состоять из чисел

  [0x100 0 0]
I=[0 0x100 0]
  [0 0 0x100]

8-битный цап никогда не дает единицу на выходе, он дает значения от 0 до 255/256

P.S. Тут еще и арифметику с насыщением надо использовать, если результат превышает 255, то нужно брать 255.

Сообщение отредактировал deathsoft - Понедельник, 2009-08-03, 12:37:39
 
lvdДата: Понедельник, 2009-08-03, 15:02:11 | Сообщение # 3
Retry, Abort, Ignore?
Группа: Человеки
Сообщений: 2528
Репутация: 13
Статус: Offline
А что мешает считать единицей 0xFF, кроме предрассудков?

Многого нет здесь: http://lvd.nedopc.com
 
deathsoftДата: Понедельник, 2009-08-03, 16:14:27 | Сообщение # 4
Retry, Abort, Ignore?
Группа: Человеки
Сообщений: 1587
Репутация: 9
Статус: Offline
Quote (lvd)
А что мешает считать единицей 0xFF, кроме предрассудков?

Тогда нуля не будет и будет неточно, надо просто в матрицу записывать коэффициенты 0..256 и все, а в унриале исправить расчет, чтобы внутринние вычисления были int а на байт, и будет все как надо, т.е. результирующий цвет будет 0..255. Еще сделать проверку на насыщение (не знаю сделано ли сейчас).

P.S. Ну и все палитры в ини файле надо будет поправить, чтобы где 1 было 0x100.

Сообщение отредактировал deathsoft - Понедельник, 2009-08-03, 16:16:30
 
lvdДата: Понедельник, 2009-08-03, 20:22:41 | Сообщение # 5
Retry, Abort, Ignore?
Группа: Человеки
Сообщений: 2528
Репутация: 13
Статус: Offline
Quote (deathsoft)
Тогда нуля не будет и будет неточно,

Ты шо, тормоз?
0 это ноль
255 это 1
ff*ff/ff === ff

Quote (deathsoft)
надо просто в матрицу записывать коэффициенты 0..256 и все, а в унриале исправить расчет, чтобы внутринние вычисления были int а на байт, и будет все как надо, т.е. результирующий цвет будет 0..255. Еще сделать проверку на насыщение (не знаю сделано ли сейчас).

Ну или так сделай, но 1 хуй получишь ты 0x100, и куды ты будешь пихать это в РГБ? Проще сделать 1===0xFF и не епсть мозг. Делить придётся на 255, а не сдвигать на 256, вот и всё.


Многого нет здесь: http://lvd.nedopc.com
 
deathsoftДата: Понедельник, 2009-08-03, 23:27:13 | Сообщение # 6
Retry, Abort, Ignore?
Группа: Человеки
Сообщений: 1587
Репутация: 9
Статус: Offline
Quote (lvd)
Ну или так сделай, но 1 хуй получишь ты 0x100, и куды ты будешь пихать это в РГБ?

Там же написано - арифметика с насыщением если > 255 то записывается 255. Посмотри любые алгоритмы преобразования цветов (в MMX даже спец команды есть для сложения с насыщением).
 
lvdДата: Вторник, 2009-08-04, 20:09:46 | Сообщение # 7
Retry, Abort, Ignore?
Группа: Человеки
Сообщений: 2528
Репутация: 13
Статус: Offline
Quote (deathsoft)
Там же написано - арифметика с насыщением если > 255 то записывается 255.

Какая должна быть матрица, чтобы тройку RGB тождественно перевести в её же саму? Для случая 1===0xFF матрица ff 0 0;0 ff 0;0 0 ff.
Для случая 1===0x100 в студию. Используй любые насыщения в процессе расчёта, матрицу в студию и алгоритм пост-обработки.


Многого нет здесь: http://lvd.nedopc.com
 
deathsoftДата: Среда, 2009-08-05, 01:10:01 | Сообщение # 8
Retry, Abort, Ignore?
Группа: Человеки
Сообщений: 1587
Репутация: 9
Статус: Offline
Quote (lvd)
Какая должна быть матрица, чтобы тройку RGB тождественно перевести в её же саму?

Quote (deathsoft)
В случае преоразования 1 в 1 матрица должна состоять из чисел


  [0x100 0 0]
I=[0 0x100 0]
  [0 0 0x100]

Ro=(Ri*0x100+Gi*0+Bi*0)/0x100
Go=(Ri*0+Gi*0x100+Bi*0)/0x100
Bo=(Ri*0+Gi*0+Bi*0x100)/0x100

Собственно все уже сделано в унриале, только коэффициенты в матрице неверные. Вместо 1.0 там 255/256

Сообщение отредактировал deathsoft - Среда, 2009-08-05, 01:12:56
 
lvdДата: Среда, 2009-08-05, 07:23:40 | Сообщение # 9
Retry, Abort, Ignore?
Группа: Человеки
Сообщений: 2528
Репутация: 13
Статус: Offline
Quote (deathsoft)
Ro=(Ri*0x100+Gi*0+Bi*0)/0x100 Go=(Ri*0+Gi*0x100+Bi*0)/0x100 Bo=(Ri*0+Gi*0+Bi*0x100)/0x100

Это выходит за пределы 8*8->16 умножения и за пределы 8-битной матрицы. Если это приемлемо, то да, всё ОК.


Многого нет здесь: http://lvd.nedopc.com
 
deathsoftДата: Среда, 2009-08-05, 12:07:54 | Сообщение # 10
Retry, Abort, Ignore?
Группа: Человеки
Сообщений: 1587
Репутация: 9
Статус: Offline
Quote (lvd)
Это выходит за пределы 8*8->16 умножения и за пределы 8-битной матрицы. Если это приемлемо, то да, всё ОК.

Приемлемо, промежуточные расчеты просто int, а результат char, если бы были ограничения с разрядностью - то пришлось бы извращатся.


Сообщение отредактировал deathsoft - Среда, 2009-08-05, 12:08:22
 
deathsoftДата: Четверг, 2009-09-17, 23:53:34 | Сообщение # 11
Retry, Abort, Ignore?
Группа: Человеки
Сообщений: 1587
Репутация: 9
Статус: Offline
Quote (deathsoft)
Коэффициент 255 в матрице не соответствует единице, для единицы в матрице должно быть 256.

[Ro] [R11 R12 R13] [Ri]
[Go]=[R21 R22 R23]*[Gi]
[Bo] [R31 R32 R33] [Bi]

В случае преоразования 1 в 1 матрица должна состоять из чисел

[0x100 0 0]
I=[0 0x100 0]
[0 0 0x100]


Сделал в соответствии с формулой, теперь белый 255,255,255 а не 254,254,254


Сообщение отредактировал deathsoft - Четверг, 2009-09-17, 23:54:22
 
ZX-Форум » Unreal Speccy переехал http://dlcorp.nedopc.com/viewforum.php?f=8 » Ошибки » Ошибка в просчете палитры?
  • Страница 1 из 1
  • 1
Поиск:

the DLCorp © 2006