25 января

Старому доброму джипегу настала пора потесниться.

Собственно, она настала уж давно - минусов у формата не так уж мало. Чего, например, стоит лишь отсутствие прозрачности...

Но потеснит джипега новый претендент на его трон не из-за прозрачности. Из-за качества. Программирование не стоит на месте и со временем выясняется, что есть способ сделать то же самое гораздо лучше. Насколько лучше? А принципиально, категорически лучше.

Да сравните сами.

Это - JPEG	А это - JPEG 2000

(источник - http://ltswww.epfl.ch/~neximage/decoder/applets/)

Эти фрагменты получены из двух файлов одинакового размера и, соответственно, степени компрессии. (Рекомендую, кстати, открыть их в полный размер.) Но левый претерпел издевательства обычным джипегом, а правый - новым, двухтысячным. Конечно, чтобы показать их вам их пришлось ещё раз сжать jpeg-ом, но несравнимо слабее, так что его искажениями можно пренебречь.

Двухтысячник, конечно, отличается от предшественника так разительно лишь если компрессия достигает запредельных величин - когда jpeg уже доводит картинку до полной невменяемости, старший брат, конечно, тоже проявляет себя, но мягче. Никаких квадратов. Вейвлет-компрессия ведёт себя спокойно - размывает, да. Но не грызёт! Побеждён, наконец, этот отвратительный джипежий квадрат:

JPEG	JPEG 2000

При увеличении видно: границы разных цветовых зон искажаются, конечно, но такие искажения глаз прощает ку-уда легче, чем напиливание изображения на квадратики.

Я сделал простой эксперимент - вычел результаты компрессии одного и того же кадра (сведённого, впрочем, для простоты в grayscale) обычным и новым джипегом друг из друга.

Результат показателен (для очевидности я подконтрастил его до упора):

Чтобы лучше его понять откройте оба изображения (JPEG, JPEG 2000) в полный размер - станет понятно, в чём отличия. Кстати, различие достигало в некоторых случая семи бит! Напомню, сравнивались восьмибитные чёрно-белые изображения, полученные из вышепоказанных цветных. Семь бит различия из восьми возможных - очень много. Впрочем, надо отметить, что различия в седьмом бите чрезвычайно редки - основная масса разницы приходится на младшие пять бит диапазона. Что, впрочем, тоже очень много.

Что кроме качества интересно в новом джипеге? Ну, например, lossless режим. Справедливости ради, старый джипег тоже существует в lossless-версии (довольно бестолковая, кстати, штука), но это отдельная песня, и вряд ли наш с вами броузер умеет её петь. У 2000-ного режим "без потерь" - штатный, любой стандартный декодер будет его поддерживать.

Интересна возможность прервать скачивание, как только достигнут нужный уровень качества - файл JPEG 2000 устроен так, что вначале идут грубые детали (точнее, информация о низкочастотных компонентах изображения), дальше - всё более мелкие. Поэтому как только вы достигли нужного уровня качества изображения, можно остановиться, и не продолжать скачивание его с сети, считывание его с диска и т.п. Файл JPEG 2000 - сам себе thumbnail (прочёл часть, декодировал грубо, уменьшил - быстро получил иконку), и сам себе - версия в низком разрешении. Для сети - находка, а не формат.

Да - а прозрачность там, вроде, наконец поддержана. Во всяком случае упоминание её я нашёл. На странице 157 черновика стандарта. Черновик раздают с веба, но читать его невесело - душный документ. :-)

Ещё о Фантоме. Представляю заинтересованным концепцию ленивых нитей.

Идея вот в чём. Иногда запуск нити не обязателен семантически, но лишь возможен и/или желателен, плюс объём выполняемого в потенциальной нити кода недостаточен, чтобы так уж настаивать на запуске нити для его выполнения. В такой ситуации уместно дать системе лишь хинт - указать на то, то вот то-то и то-то может быть сделано параллельно основному коду, особенно, если под руку подвернётся простаивающий процессор в SMP-компьютере.

Решать же - запускать нить, или исполнить код в рамках "отчей" нити - можно предоставить операционной системе. Заявка на запуск такой нити - это всего лишь один mov - помещение в специальный стек запросов адреса элемента в основном стеке, где начинается контекст новой нити. Сам же код нити в этом случае запускается обычным вызовом подпрограммы. Если в процессе её работы контекст ни разу не переключался, никакой второй или третий процессор не освобождался и вообще ничего существенного не произошло - нить не состоится. Код её отработает, как простая подпрограмма, а при возвращении снимет запрос на образование нити.

Если же мы и так переключились в ядро - из-за системного ли вызова, или у нас обнаружился избыток процессорной мощи, то заглянем в стек запросов на ленивые нити. Есть запрос? Оформляем уже работающий код "ленивой" нити как настоящую нить, а в той нити, что породила её симулируем возврат в точку, где ленивая нить была запущена. С этого момента она работает параллельно и в своём контексте.

В чём прелесть такой схемы? Она позволяет резко понизить стоимость запуска нити (полный запуск случается не всегда и только если контекст переключился на ядро по иной причине, а в таком случае запустить нить - дёшево), а значит меньше задумываться о том, уместно ли их применение там и тут.

Придумана она была по смешной причине. На одной из стадий обдумывания Фантома я пришёл к вопросу, не имеет ли смысла запускать в отдельных нитях просто все методы вообще и всегда. Первой реакцией была мысль, что это дико дорого, но как раз эту проблему удалось решить "ленивыми" нитями. Впрочем, от идеи непрерывного нитерождения я отказался по банальной причине - пож такую систему было бы нелегко программировать, а я, в конце концов, хотел бы вовсе обратного. :-)

Реклама
	Люди, если кто знает хорошего UNIX-администратора, который ищет работу -- дайте ему, пожалуйста, ссылку: http://www.comptek.ru/job/index.html Мы также набираем: могучих С++ программеров, людей способных писать SQL-ные приложения в интернете, а также классного прикладника-программиста на 1С.