Да, весьма интересно. По какой-то причине не сталкивался с ним раньше — декодеры спокойно дают на выходе 24-битное изображение, не думая об оригинале. А с энкодерами я мало сталкивался по разной причине. Да и инфрмации на эту тему весьма мало.
Imagemagick пишет в такой формат, если ему принудительно это указать. Что интересно, при этом параметр quality не работает вообще, PSNR остается неизменным (51.1808 в моем случае), но это не Lossless сжатие, где-то еще есть внутренние преобразования.
P.S. В Википедии как раз ошибка, формат JFIF подразумевает и Y, и YCbCr:
The RGB components calculated by linear conversion from YCbCr shall not be gamma corrected (gamma = 1.0). If only one component is used, that component shall be Y.
Это удивительно, но от вашей статьи тоже есть польза — сравнение разных библиотек весьма полезно. Но все перечёркивается очень странными бенчмарками.
FreeImage считывает в память 4220 байт картинки за 5мс? Даже для 1000 итераций это нереально долго, скорость памяти исчисляется в тысячах мегабайт в секунду. Вызов jpeg_start_decompress/jpeg_read_scanlines/jpeg_finish_decompress занимает разное время в разных обертках вокруг одной библиотеки? Почему?
В конце-концов, раз речь шла о кросс-платформенности, где результаты других платформ?
В целом, сравнение разных оберток над одинаковыми libPNG/libJPEG/libTIFF должно было показать почти одинаковый результат. Если это не так, то либо дело в накладных расходах (читай — ошибках реализации), либо в ошибках тестирования. Вам обязательно надо было попробовать напрямую замерить скорость самих этих библиотек, без оберток. Отдельно в TIF файле может быть сжатие RLE, JPEG и LZW (+ чуть более редкие варианты), поэтому libTIFF использует libJPEG и в идеальном варианте скорость открытия TIFF-JPEG должна совпасть со скоростью чистой libJPEG.
Так же замерять скорость чтения BMP файла размером 32х32 откровенно несерьезно — после прогрева кеша его чтение должно быть менее 1мс для абсолютно любой реализации и если это не так, то вы что-то делаете не так.
P.S. Я же надеюсь, вы в курсе, что кодирование в DXT1 отличается в разных реализациях в разы по качеству и скорости? Простенький кодер есть и в ImageMagik, который вы почему-то обозвали древним артефактом, хотя он развивается не в пример лучше того же DevIL. Просто, его задачей никогда не была производительность или удобство встраивания, это универсальный комбайн для всех возможных и невозможных операций с картинками. А в целом, сжатие в DXT1 может быть существенно оптимизировано и разбито на потоки, что хорошо сделали ребята из Unity в своей версии crunch.
Более того, CRC для порядковых номеров будет откровенно неудачным решением, ведь это получается очень короткая последовательность байт, где старшие 2-3 байта нулевые или такие же, как у прошлого идентификатора. Какой-нибудь простой Fletcher-16 вообще может начать давать коллизии на ровном месте. Тут надо не лениться использовать хеш-функцию, при чем лучше даже от строкового представления.
Я тоже так сразу и подумал, но судя по стилю текста, общим описаниям и т.д. автор вполне адекватен, значит дело в чем-то другом, включая банальный ступор или интерференцию синтаксиса языков. Нормально, если человек не знает синтаксис fixed или unchecked, но не знать virtual он не может, скорее просто забыл в мандраже слово или не понял вопрос. И вполне он может знать и про работу vtbl, просто надо сбавить обороты и разобраться, что происходит. В этом и посыл статьи. Гораздо легче сразу завернуть кандидата, чем подумать.
Ну так тут два варианта: либо у вас был ступор, либо вы — fraud. Многие почему-то принимают первое за второе. У меня когда-то спросили можно ли написать
class object : object
{ }
Мои шестеренки сразу заклинило, я с трудом выдавил «нет» и на вопрос «а как сделать, чтобы можно было?» я не ответил, потому что не мог понять, что от меня вообще хотят и зачем это надо. А собеседующий всего лишь хотел услышать, что я знаю как работать с префиксом @:
Смотрите, реакция может быть положительная на:
а) идею проекта
б) его реализацию
Вы надеетесь, что идея настолько хороша, что потом можно будет задним числом исправить реализацию. Но это не совсем так, поэтому разумным шагом была бы разработка документации, вычитка и чистка кода, приведение к единому стилю и выпуск версии 1.2 уже не для себя, а для гипотетического сообщества. Вам надо вывести его с уровня «домашний эксперимент» на «интересный проект, может кому-то пригодится».
Готовые не устраивают тем, что есть уже свое рабочее решение, на нем написано сколько-то игр и впиливать вместо него что-то совершенно чужое, на другом языке смысла нет.
Но смысл есть выбрать какую-то готовую GUI библиотеку за эталон и привести свое решение к аналогичной архитектуре, вплоть до совпадающих методов. Банально, можно будет и чужие редакторы подключить, и просто на чужом опыте многие подводные камни пройти.
Я о том и говорю, что в случае собственных UI фреймворков, разработчики часто реализуют лишь то, что надо их проектам, а условия иногда меняются и мы получаем игры, где в поле ввода нельзя вставить текст из буфера, списки без быстрого поиска, тексты без поддержки стилей и т.д.
В своем движке я столкнулся с интересной проблемой: UI компоненты делались по мере надобности, а не методом «реализовать все возможные контролы с всеми возможными вариантами использования». В итоге код каждого контрола переписывался много раз, кое-где оброс костылями, а всякие Progress Bar вообще не вошли в библиотеку и каждый раз реализуются по-разному. И, как водится, без юнит тестов.
Уже отлично видно, что это огромная самовыкопанная яма и выбраться из нее можно только если таки сделать шаг назад и таки сделать отдельно библиотеку базовых компонентов и тесты для них. Может даже попробовать имитировать частично UI стек готовых решений, а-ля wxWidgets или QT.
Может кто-то встречал гайдлайны «базовые UI компоненты и какими свойствами они должны обладать»? Или может имеет опыт и желание заняться чем-то таким? :)
Забавно, я находил во многих статьях упоминания про фейк. И Quirk в линукс-драйвере тоже намекает на не-родное происхождение HX. Ну, так уж и будет тогда. Спишем все на желание производителя, а не подделку. :)
Отличная была история с дешевыми TTL-USB чипами Prolific 2303. Чип мега-популярный, его выпущено очень много, но неожиданно пару лет назад часть из них перестала работать под Windows — обновились драйвера и подделки стали несовместимыми. Во многих случаях нареканий на чипы не было, поэтому люди просто ставят более старые драйвера и пользуются.
У меня же нашлось сразу две проблемы: инверсия уровней TTL/UART сигналов не работала (галочка в драйвере не делала ничего), а от UART 5V чип сильно грелся и в итоге сгорел, хотя по спецификации поддерживается и TTL 3.3V, и UART 5V.
Куда девается стружка от сверления в невесомости? Сколько надо времени, чтобы она попала в организм человека и насколько это плохо? Может ли она исчезнуть Июбесследно? Если на это нет явных ответов, то версию "просверлили на месте" рассматривать, кхм, не целесообразно.
Ну вы полностью правильно сказали, большой UI проект на С++ это как опера, написанная под одного выдающегося исполнителя — она красива, когда есть достойный певец, но абсолютно провальна во всех остальных случаях. Для примера можно почитать про Simon Boccanegra. Естественно, могут быть исключения, в основном за счет соблюдения идеальной дисциплины и единого стиля в команде.
P.S. Кучу лет жизни я отдал работе с MMC оснастками, поддерживая и развивая воотчину лапшекода. Но потом в момент появления MMC 3.0 с поддержкой .Net, мой скилл очень быстро стал не нужен — новый инструментарий позволил молодым разрабам писать красивый код, использовать сторонние библиотеки, а не мучаться на C++ с встроенным IE 6 движком и передачей данных COM-объектами а-ля `COM_INTERFACE_ENTRY2(IOleWindow, IOleInPlaceObjectWindowless)`. Так что, мало ли, может и JS в вебе что-то рано или поздно заменит. Ну или все привыкнут и будут работать как есть :)
Выпасть может и над морем, и в местах не подходящих для сбора энергии. А выработка энергии в пересохшей реке будет падать и падать. В итоге мы получим безжизненную пустыню на месте ГЭС в долгосрочной перспективе.
После заполнения водохранилищ существенно повышается площадь поверхности испарения, а также строится множество ирригационных каналов. Также заметно падает скорость в месте расширения, что приводит к образованию новых русел. Еще, мне кажется, водохранилище сглаживает сезонные и дождевые колебания силы потока. Например, Нил после Асуанской плотины перестал разливаться вообще. Для такой большой реки это нормально, а в случае с Rio Grande естественный песочный вал мог бы быть смыт во время дождя без особых проблем, но этого несколько лет не происходило.
Выпадет в другом месте. Экосистема в изначальном месте вымрет, дельта засолонится, жизнь закончится. См Аральское море
(пример не идеален, потому что не река, но процессы схожие).
Imagemagick пишет в такой формат, если ему принудительно это указать. Что интересно, при этом параметр quality не работает вообще, PSNR остается неизменным (51.1808 в моем случае), но это не Lossless сжатие, где-то еще есть внутренние преобразования.
P.S. В Википедии как раз ошибка, формат JFIF подразумевает и Y, и YCbCr:
FreeImage считывает в память 4220 байт картинки за 5мс? Даже для 1000 итераций это нереально долго, скорость памяти исчисляется в тысячах мегабайт в секунду. Вызов jpeg_start_decompress/jpeg_read_scanlines/jpeg_finish_decompress занимает разное время в разных обертках вокруг одной библиотеки? Почему?
В конце-концов, раз речь шла о кросс-платформенности, где результаты других платформ?
Так же замерять скорость чтения BMP файла размером 32х32 откровенно несерьезно — после прогрева кеша его чтение должно быть менее 1мс для абсолютно любой реализации и если это не так, то вы что-то делаете не так.
P.S. Я же надеюсь, вы в курсе, что кодирование в DXT1 отличается в разных реализациях в разы по качеству и скорости? Простенький кодер есть и в ImageMagik, который вы почему-то обозвали древним артефактом, хотя он развивается не в пример лучше того же DevIL. Просто, его задачей никогда не была производительность или удобство встраивания, это универсальный комбайн для всех возможных и невозможных операций с картинками. А в целом, сжатие в DXT1 может быть существенно оптимизировано и разбито на потоки, что хорошо сделали ребята из Unity в своей версии crunch.
Но вот этого, к сожалению, не заметно.
Я тоже так сразу и подумал, но судя по стилю текста, общим описаниям и т.д. автор вполне адекватен, значит дело в чем-то другом, включая банальный ступор или интерференцию синтаксиса языков. Нормально, если человек не знает синтаксис fixed или unchecked, но не знать virtual он не может, скорее просто забыл в мандраже слово или не понял вопрос. И вполне он может знать и про работу vtbl, просто надо сбавить обороты и разобраться, что происходит. В этом и посыл статьи. Гораздо легче сразу завернуть кандидата, чем подумать.
Мои шестеренки сразу заклинило, я с трудом выдавил «нет» и на вопрос «а как сделать, чтобы можно было?» я не ответил, потому что не мог понять, что от меня вообще хотят и зачем это надо. А собеседующий всего лишь хотел услышать, что я знаю как работать с префиксом @:
а) идею проекта
б) его реализацию
Вы надеетесь, что идея настолько хороша, что потом можно будет задним числом исправить реализацию. Но это не совсем так, поэтому разумным шагом была бы разработка документации, вычитка и чистка кода, приведение к единому стилю и выпуск версии 1.2 уже не для себя, а для гипотетического сообщества. Вам надо вывести его с уровня «домашний эксперимент» на «интересный проект, может кому-то пригодится».
Но смысл есть выбрать какую-то готовую GUI библиотеку за эталон и привести свое решение к аналогичной архитектуре, вплоть до совпадающих методов. Банально, можно будет и чужие редакторы подключить, и просто на чужом опыте многие подводные камни пройти.
Я о том и говорю, что в случае собственных UI фреймворков, разработчики часто реализуют лишь то, что надо их проектам, а условия иногда меняются и мы получаем игры, где в поле ввода нельзя вставить текст из буфера, списки без быстрого поиска, тексты без поддержки стилей и т.д.
Уже отлично видно, что это огромная самовыкопанная яма и выбраться из нее можно только если таки сделать шаг назад и таки сделать отдельно библиотеку базовых компонентов и тесты для них. Может даже попробовать имитировать частично UI стек готовых решений, а-ля wxWidgets или QT.
Может кто-то встречал гайдлайны «базовые UI компоненты и какими свойствами они должны обладать»? Или может имеет опыт и желание заняться чем-то таким? :)
У меня же нашлось сразу две проблемы: инверсия уровней TTL/UART сигналов не работала (галочка в драйвере не делала ничего), а от UART 5V чип сильно грелся и в итоге сгорел, хотя по спецификации поддерживается и TTL 3.3V, и UART 5V.
Куда девается стружка от сверления в невесомости? Сколько надо времени, чтобы она попала в организм человека и насколько это плохо? Может ли она исчезнуть Июбесследно? Если на это нет явных ответов, то версию "просверлили на месте" рассматривать, кхм, не целесообразно.
P.S. Кучу лет жизни я отдал работе с MMC оснастками, поддерживая и развивая воотчину лапшекода. Но потом в момент появления MMC 3.0 с поддержкой .Net, мой скилл очень быстро стал не нужен — новый инструментарий позволил молодым разрабам писать красивый код, использовать сторонние библиотеки, а не мучаться на C++ с встроенным IE 6 движком и передачей данных COM-объектами а-ля `COM_INTERFACE_ENTRY2(IOleWindow, IOleInPlaceObjectWindowless)`. Так что, мало ли, может и JS в вебе что-то рано или поздно заменит. Ну или все привыкнут и будут работать как есть :)
(пример не идеален, потому что не река, но процессы схожие).