- Сообщения
- 34 337
- Реакции
- 11 265
одна тысячная из "Убрать ненужный цвет"
- Автор темы Emergency
- Дата начала
- Сообщения
- 930
- Реакции
- 134
Ну так дайте правильное объяснение разницы между 0,1 и 0,2 процента черного, и я с радостью с вами соглашусь. А если у вас нет правильного объяснения, то обоснуйте неправильность моего предположения об округлении однобайтной величины до нуля.
- Сообщения
- 34 337
- Реакции
- 11 265
Я разве где то говорил про то что у меня есть более вразумительная гипотеза? Я чисто про периодические безграмотные определения, что такое неонка в ваших постах. Вот, к примеру, в процитированном, внимательно вчитайтесь в это свое "округление однобайтной величины до нуля"?
С какого перепугу значение с плавающей точкой будет округляться до восьмибитного целого (как правильнее было бы сказать, чтобы все поняли)?
- Сообщения
- 930
- Реакции
- 134
При переводе числа с плавающей точкой в двоичное 8-битное число округление будет происходить почти всегда (за исключением случаев, когда число с плавающей точкой будет целым и не превышать 255).
- Сообщения
- 34 337
- Реакции
- 11 265
Я рад, что вы, наконец, научились выражать свои мысли научным языком. Теперь ответьте на следующий вопрос
?
Последнее редактирование:
- Сообщения
- 930
- Реакции
- 134
- Сообщения
- 34 337
- Реакции
- 11 265
Нет, ну вы же исходя из какой то логики сделали такое странное предположение? Давайте я напомню - вы "когда то где то слышали, что внутри адобовских программ внутреннее представление цвета целочисленное, причем, uint8/uint16" , так?
- Сообщения
- 930
- Реакции
- 134
Ага.
Логика простая - округления 0,1% до uint8 дает ноль, а округление 0,2% дает 1. Почему uint8? Потому что тип данных uint8 часто используют для эффективности памяти, когда достаточно небольших положительных чисел.
- Сообщения
- 34 337
- Реакции
- 11 265
Вы всерьез так думаете? Я, конечно, делаю вам скидку на возраст, возможно, это было эффективно, когда вы начинали знакомство с компьютерами. Они были большими, памяти было 64К и регистры процессора были 8битными. Но сейчас вторая четверть 21 века, в процессоры встроена плавающая математика охрененной разрядности, которая, ЧСХ, считается быстрее целочисленной и даже целочисленные 8битные операции эмулируются (с замедлением) на 64битных регистрах, формат хранения данных - тоже (текстовая!!!) плавающая точка охрененой точности после запятой; на выходе печати гладкие многометровые полутоновые переходы, итак, я повторяю свой вопрос:
?
- Сообщения
- 930
- Реакции
- 134
- Сообщения
- 34 337
- Реакции
- 11 265
- Сообщения
- 930
- Реакции
- 134
Нет, использовал совет проверять себя.
Расчет тут не при чем. Я вечером вспомнил как в 90-х писал перекодировщик текстов (тогда макинтоши не понимали кодировку виндоус) и что фотошоп сплошь работает на таблицах. Так вот, арифметика работает только на этапе построения таблиц пересчета цвета, а потом идет преобразование входного цвета в выходной, и происходит оно практически со скоростью чтения + записи оперативной памяти. Если Акробат использует этот механизм, то ему нужны целочисленные входные данные, которые можно преобразовать в адреса.
Я могу расписать это подробно, но получится очень длинно...
- Сообщения
- 930
- Реакции
- 134
- Сообщения
- 34 337
- Реакции
- 11 265
Не нужно, я прекрасно понял, что вы имели в виду, вероятно, хэширование массивов, так?
Оно используется для быстрого поиска по большим таблицам, но ошибочно полагать, что все данные, содержащиеся в массивах при этом округляются до битности хэша, который, вдобавок, сильно длинее 8 бит.
Вы матчасть внимательнее подтягивайте, не ограничиваясь нейросетевыми ответами на вопросы, которые вы, вдобавок, еще и правильно сформулировать не можете.
- Сообщения
- 930
- Реакции
- 134
Нет.
Поясню на примере. Допустим, в фотошопе вы хотите исправить градации в большом (не обязательно) файте и устанавливаете в кривых несколько точек, задающих функцию преобразования. Обсчитывать каждый пиксель по этой функции было бы безумием. Фотошоп задает эту функцию в виде таблицы выходных значений одно- или двухбайтовыми числами (в зависимости от выбранного вами режима). После этого считывает один из каналов (R, G или B) первого пикселя в виде адреса таблицы и записывает в первый пиксел нового файла значение из этого адреса после чего повторяет эту операцию для каждого следующего пикселя и канала. То есть осуществляет только операции чтения и записи без вычислений. Вуаля - задача выполнена предельно быстро.
- Сообщения
- 34 337
- Реакции
- 11 265
Паазвольте, у нас разве фотошоп и попиксельный пересчет одного растрового изображения в другое? Насколько я понимаю, у нас весьма сложная (нецелочисленная) математика с усреднением, на выходе число с плавающей точкой. Где там в алгоритм можно влепить описанное вами табличное преобразование с округлением, а главное, зачем - ума не приложу.
- Сообщения
- 2 045
- Реакции
- 598
Нет, кстати, для массовых формульных преобразований идея хорошая, максимально быстрая, мне нравится, я такое тоже делал как-то давно. Только вот к теме топика это не имеет никакого отношения
- Сообщения
- 930
- Реакции
- 134
Нет, у нас Акробат, который изначально был предназначен для показа документов на экране, и распечатке его на принтере. Обе задачи предполагают финальную пикселизацию всех изображений и текстов.