С новым фотошопом регулярно натыкаюсь на проблему: при печати больших форматов на печать вылазит только узкая полоска (1-3 сантиметра) с нижней стороны картинки. Обычно у меня там рамка и все.
Проблема меня реально мучала, экспериментируя выяснил что
Если включить Print Preview в драйвере принтера, то проблему видно и в нем. Т.е. это проблема печатающего приложения, а не драйвера.
А3 и меньше я печатаю редко, но не могу вспомнить чтобы столкнулся с проблемой. Вылезает только на А2, особенно часто вылезает на полюбившемся мне 17-дюймовом рулоне (типичный размер печатаемого: 420x660 мм).
Проблема редко была у Photoshop CS3, у 32-битного CS4 проявляется гораздо чаще. Если на preview увидели, надо закрыть фотошоп, открыть фотошоп и скорее всего пройдет.
Проблемы нет у 64-битного фотошопа. Вообще. Ни разу не видел.
Другими словами, что-то где-то с памятью намудрили. Или буфер выделяется не целиком, или что-то (иногда) переполняется, чего не случается. Кто там поближе к Сан-Хосе, зашлите им диарейных лучей.
Workflow с этими двумя версиями фотошопа получается какой-то ужасающий:
Основные действия производим в Lab, в 64-битном фотошопе (ибо быстрее).
Переводим в RGB, закрывает 64-битный, запускаем 32-битный, делаем финальный sharpen (Photokit Sharpener, у них есть 64-битная версия, но у меня не заработало).
Во всяком случае, попытка поставить апдейт на разрекламированную ранее виртуальную машину 10.5.5 не удалась: Vmware ругается страшными словами, что приложение решило подизейблить себе процессор, MacOS требует перезагрузки, а потом все вместе - не работает.
Последние два месяца я собирался прикрутить к Drupal кэширование на memcached. Останавливало меня то, что модуль Memcache был только для Drupal 5.x (у меня используется 6-я версия), а Cache Router был в разобранном неработающем состоянии. Доводить же до ума еще и это место не хотелось.
Как выяснилось, в течение ноября оба модуля были починены и сейчас выглядят полностью рабочими под Drupal 6.8. Правда производительность у них резко отличается:
Memcache не дал мне заметного прироста производительности, более ~50 запросов в секунду из него вытащить не удалось (а у меня с кэшированием родными средствами Drupal - ну чуть меньше).
Cache Router, наоборот, честно все кэширует и скорость работы из кэша - порядка 850-880 req/sec
Соответственно, поставил я CacheRouter, выглядит работающим.
Тестирование проводилось путем накатки суточного лога LibRaw.SU утилитой http_load. Считался, естественно, второй проход, подразумевалось что все разлеглось в кэши. Сервер: Dual Opteron 875, FreeBSD 6.4, Postgresql 8.3.5.
Прочитал вчера статью Алексея Шадрина Воспитание по доктору Маргулису: работа над ошибками и, кажется, осознал в чем заключается противоречие между двумя подходами к обработке изображений. О чем и написал сам.
Кит против слона: о двух подходах к цифровым изображениям
Позволю себе пару цитат:
....Есть "два лагеря" (Илья Борг предлагает называть их "колориметристами" и "перцептуалистами"), которые на текущий момент договориться не могут и я не уверен, что в ближайшее время это вообще будет возможно. ....
....фотограф вынужденно попадает в самый центр вышеописанного конфликта и избежать его не может. А основная ошибка, которая регулярно делается многими уважаемыми людьми, - это отрицание ... одного из подходов.....
Что-то я анонс пропустил, а сегодня случайно наткнулся на Pixel Bender от Adobe Labs.
Казалось бы, отличная идея: пишешь шейдеры kernels на скриптовом языке, они исполняются на видеокарте или на CPU.
Анонс тоже завлекал: дескать поддержвается любая разрядность цвета, все такое мультиплатформенное и хорошее. Есть плагин для Photoshop т.е. все изыски можно прямо в бою и использовать.
В-общем, я раскатал губу, скачал, поставил, закатал рукава и приготовился творить.
Мне кажется про это уже писали в комментах, но я не понял. А получив спам от ACM - понял.
Для членов ACM доступна сильно урезанная по выбору книжек версия сервиса Safaribooks (про который я уже писал), но зато на халяву (вы платите только за членство в ACM :). Помимо урезанности выбора, нельзя еще скачивать главы в .pdf, что обидно.
Напоминаю, что если в ACM при регистрации указать, что вы из России (что в моем случае правда), то регистрация будет стоить $35 $43 в год вместо ~$200. Даже не надо притворяться студентом.....
Бурное обсуждение моей предыдущей заметки про аппаратный RAID заставило меня потратить немножко времени в выходные на изучение software raid5 в FreeBSD (других подопытных ОС не оказалось).
Приборы и материалы
FreeBSD 7.1-PRERELEASE - i386, Core2Duo 1.86, 2GB RAM, 3 диска Western Digital WD7500AAKS (750Gb).
Диски я извлек из рабочей станции, там они показывали 140MB/sec на чтение и 120-125 на запись будучи прицеплеными к Areca ARC-1120 в режиме RAID5 под WinXP/Vista.
GEOM RAID5 все еще не входит в комплект FreeBSD, поэтому использовались две из трех имеющихся внешних реализаций: GEOM RAID5 TNG и GEOM RAID5 PP. Забегая вперед скажу, что существенной разницы в производительности я не увидел.
Помимо этого, я посмотрел на производительность RAID0 (GEOM stripe).
Тестирование проводилось на чтении-записи длинных файлов т.к. меня интересуют именно они. На коротких операциях всё может быть иначе, все "короткие" нагрузки настолько разные, что требуют тестирования по месту.
Мы с Ильей Боргом написали в Компьютерру статью, в которой постарались описать наше видение современного состояния дел с RAW-форматами. Прошло три недели с выхода журнала и, согласно первоначальной договоренности, перепечатываем у себя:
Позволю себе процитировать вводный раздел целиком.
За последние 10—15 лет цифровая фотография вытеснила фотопленку практически из всех традиционных областей применения. Конечным потребителям проданы сотни миллионов цифровых фотокамер, не считая камер, проданных в мобильных телефонах. Столь массовая индустрия не может существовать без стандартов — и таковые, казалось бы, имеются: стандартизованы устройства для хранения данных (flash-карточки) и формат изображений JPEG — наиболее массовый и удовлетворяющий потребности подавляющего числа пользователей.
Однако формат JPEG далеко не всегда удовлетворяет требованиям профессионалов — фотографов, дизайнеров, персонал prepress-бюро, а тем более фотобанков и фотоархивов. Зачастую не удовлетворяет он и требованиям "продвинутых" фотолюбителей. Именно поэтому многие модели фотокамер, обычно позиционируемые производителем как профессиональные и полупрофессиональные, поддерживают, кроме JPEG, и запись изображения в так называемом "формате RAW". У стороннего наблюдателя может создаться впечатление, что RAW — это тоже такой стандартный формат, обеспечивающий лучшее качество — "качество для профи".
В нашем маленьком тексте мы хотим показать, что на самом деле жизнь гораздо сложнее, а положение профессионалов на сегодняшнем цифровом фоторынке не просто ужасно, а совершенно ужасно, и к тому же еще и быстро ухудшается (в то время как у менее притязательных любителей — все отлично).
Как мне кажется, обсуждать данный текст лучше рядом с ним, поэтому комментарии тут я закрываю. LibRaw.SU дает комментировать без авторизации, хотя авторизованым пользователям доступно чуть больше пряников.
Это вот - бенчмарка нового красивого массива (4 диска в RAID5):
Только вот размер блока при построении массива я взял мегабайтный, а обычные средние бенчмарки от этого дуреют (график HD Tach - просто обсмеяться).
Вспомним, для чего дома 3Tb диска? Хранить всякий мусор (тут скорость не важна) ну и мувать его. А при муванье - скорость важна, ибо сидим, пялимся в монитор, ждем пока отмувается. Так вот, в жизни все не так, как в бенчмарках:
Как нам и обещали, SAS-версия терабайтной барракуды действительно быстрая (на графике выше - RAID5 из трех дисков с блоком 64кб), причем не только в тестах - на файловую систему реально получается лить 210-230 мегабайт в секунду при копировании больших файлов.