"Эти люди" просто предпочитают сначала починить базовый случай неправильного применения алгоритмов, а потом учитывать частные случаи. Масштабирование изображений это, хотя и, скорее всего, самое популярное преобразование, но не единственное, а вот игнорирование правильной работы с цветом происходит повсеместно :)
uint16 может очень сильно терять точность при повторении нескольких преобразований по цепочке. Если учесть, что для существенного количества алгоритмов нужна схема pow(f(pow(x, 1/gamma)),gamma), то получаемая потеря точности может сильно повлиять на результат из-за накопления ошибки и округлений, особенно если один из алгоритмов рассчитывает локальную производную методом сэмплирования (например, при генерации карт нормалей или edge detection).
Да, но когда человек берёт «в руки», грубо говоря, ImageMagick (то ещё решето, после известных дыр его только в сэндбоксе и запускать), и начинает им масштабировать картинку с почти любым не-nearest neighbour фильтром (хоть spline-based, например Catmull-Rom, хоть sinc-based, например Lanczos), то он уже совершает ошибку =)
Судя по тому, что «пишут в интернете» люди вообще не заморачиваются с отличением хотя бы device-dependent и device-independent цветов, а это весьма существенная проблема.
Мне очень хотелось бы, чтобы кто-нибудь развеял эти неприятные стереотипы, думаю статья об этом был бы _очень_ полезной.
Я хочу ещё отметить, что существенное количество алгоритмов предназначено для работы с линейными (а не гамма-скорректированными, что является вариантом по умолчанию) значениями цвета или вовсе не предназначено для модели RGB.
А ещё есть цветовые профили, и всякие штуки типа low-light sRGB.
Всё-таки для большинства практических целей алгоритм Кэхэна достаточно минимизирует погрешность. Если же погрешность настолько критична, то мне кажется, что стоит отказаться от представления чисел в таком формате и переходить на рациональные дроби. Конечно теряется «аппаратное ускорение» (FPU, SSE/AVX, GPU), да и проблема сокращения дробей и представления чисел условно бесконечной длины не то чтобы совсем тривиальна с точки зрения производительности, зато проблема погрешности устраняется как класс.
Да, это один из вариантов. Я согласен, что структуры данных, которые поддерживают версионирование более эффективны, но именно проблему с копированием таблиц страниц можно обойти таким способом. Конечно, у больших страниц есть минусы при случайном доступе, возможно для вашего сценария они неприменимы.
Здесь вам на помощь придёт уменьшение уровня изоляции — виртуальные машины, контейнеры или даже просто изолированные среды исполнения (отдельные application pool в IIS, pool в php-fpm и т.д.).
Например у нас более-менее стандартная схема nginx->haproxy->backend, где в качестве бэкендов выступают IIS, где на каждом сервере есть b/g apppool. Основная нагрузка обрабатывается только одним экземпляром, второй через минуту (в нашем случае) просто выгружается, потому что haproxy не передаёт на него новых запросов. А запас по памяти на бэкенде организовать обычно не проблема.
"Эти люди" просто предпочитают сначала починить базовый случай неправильного применения алгоритмов, а потом учитывать частные случаи. Масштабирование изображений это, хотя и, скорее всего, самое популярное преобразование, но не единственное, а вот игнорирование правильной работы с цветом происходит повсеместно :)
Судя по тому, что «пишут в интернете» люди вообще не заморачиваются с отличением хотя бы device-dependent и device-independent цветов, а это весьма существенная проблема.
Мне очень хотелось бы, чтобы кто-нибудь развеял эти неприятные стереотипы, думаю статья об этом был бы _очень_ полезной.
Я хочу ещё отметить, что существенное количество алгоритмов предназначено для работы с линейными (а не гамма-скорректированными, что является вариантом по умолчанию) значениями цвета или вовсе не предназначено для модели RGB.
А ещё есть цветовые профили, и всякие штуки типа low-light sRGB.
И да, я прошу прощения за недостаточно развёрнутый комментарий, сказывается низкий навык публичного общения. Slack низводит до уровня чат-бота :)
Например у нас более-менее стандартная схема nginx->haproxy->backend, где в качестве бэкендов выступают IIS, где на каждом сервере есть b/g apppool. Основная нагрузка обрабатывается только одним экземпляром, второй через минуту (в нашем случае) просто выгружается, потому что haproxy не передаёт на него новых запросов. А запас по памяти на бэкенде организовать обычно не проблема.