Skip to Content

Q: samsung galaxy note battery

А я верно понимаю, что если батарее в телефоне 2.5 года и телефон внезапно начал очень быстро садиться, то не надо искать жрунчика среди обновленных программ, а надо просто батарею поменять?

P.S. Мелкий карманный телефон у меня того же возраста, но эффекта в *такой* степени не проявляет, как раз в неделю заряжал, так и заряжаю вроде бы.

Ненависти к Qt псто

А вот представим себе такое вот:

  • QGraphicsView и QGraphicsScene
  • Показываем картинку с каким-то увеличением, так что есть скроллбары (или только один)
  • И хотим показать следующую картинку "примерно так же" (в смысле относительного положения окна просмотра относительно всей картинки)
  • И хотим, чтобы когда мы вернулись к предыдущей - позиция сохранялась бы.
Нормальное желание, правда?

Ну вот казалось бы решение:

  • Рассчитать какая (относительная, в координатах 0-1) точка исходной картинки расположена в центре экрана.
  • Рассчитать далее, какая абсолютная точка следующей картинки должна быть в этом самом центре.
  • Дальше - view->centerOn()
Почти работает.

Почти - потому что есть скроллбары, они могут быть, они могут не быть, они могут быть у первой картинки, но не у второй (размеры другие) и наоборот. Скроллбары - меняют центр View (потому что занимают ширину).

И приходится нецензурно закатывать солнце вручную:

  • Если исходно скроллбар есть - запоминаем его относительную позицию (где у нас value() между minimum() и maximum()). Если нет - берем запомненную ранее, когда скроллбар был.
  • Дальше нужно посчитать, будет ли скроллбар при показе следующей (какой размер больше, картинки или viewport()
    • Если не будет, то скроллбар надо явно выключить, потому что если разница в несколько пикселов, то его может включить.
    • Если будет - то явно включить, доверять автоматике нельзя (бывает клево: view ставит скроллбары и зовет resizeEvent(). resizeEvent() знает, что режим у нас fit-to-screen и ресайзит картинку. view - видит что картинка поресайзилась, убирает скроллбары, зовет resizeEvent().....).
  • И если скроллбар будет - то явно ему поставить value (пересчитать из предыдущего относительного)
  • А если не будет - то припрятать относительное value до следующего раза, когда скроллбар появится.
Работает. Можно листать 10 картинок (разного размера и aspect ratio) вперед, потом назад - и вернуться ровно в ту точку/экранную позицию, с которой начинали.

Но, сука, 98 строк кода (считая пробелы). Вместо эдак 8-и, с которыми работает, но примерно.

Про AMD FirePro W9100

Вот между прочим, AMD выступила очень достойно с FirePro W9100: они сделали чип у которого отношение производительности Single Precision : Double Precision 1:2, вместо обычных для AMD 1:4 (а на HD5xxx было 1:5)

В результате у них 2.6TFlops DP (теоретической), что в 1.85 раза больше, чем у (самой толстой на сегодня) NVidia Tesla K40 (1.4Tflops теоретических).

Да, у AMD не все здорово с софтовой частью: все кто вычислял вычисления уже привыкли к CUDA, перенос кода на OpenCL и оптимизация для AMD займут время, но почти двукратный выигрыш по перформансу (и еще больше, по прайс-перформансу, если сравнивать с Теслой) - взбодрит разработчиков.

Я ожидаю, в первую очередь, взбодрения всяких CAD-ов. Это FirePro не выглядит картой для вычислительных кластеров (коим 6 видео-выходов без нужды), а вот на рабочих станциях, и 3D-графика и ее обсчет на одной карте - очень к месту ж.

Ждем, естественно, ответа NVidia. Так, по идее, Maxwell - хороший, 750Ti обгоняет 650Ti на вычислениях прилично так (при меньшем количестве cores и достаточно близких частотах).

P.S. Конечно, лидером по price/perf (DP) остается NVidia Титан, но это другая история (на Титан, в числе прочего, драйвера от Квадры не натянуть, т.е. всякие CAD-ы пролетают).

Про нейтральные фильтры Haida

Один из способов убрать "трясучку" у Sony A7R - это уехать из области опасных выдержек (1/200 - 1/4, в первом приближении). Укоротить - легко (в некоторых пределах), просто увеличим чувствительность на пару стопов, проблема - увеличить выдержку, особенно если диафрагма задана сюжетом (или каким-то еще соображениями).

Насколько я слышал, большинство Vari-ND-фильтров не полностью нейтральны. И чем нейтральнее, тем получается дороже.

Пластик (Formatt/Hitech), который я пользовал (4-9 стопов) - тоже достаточно сильно окрашен, многое выправляется балансом белого, но осадок остается. У Formatt появились еще ProStop IRND, стал про них читать, наткнулся на сравнение с Haida. А Haida - есть на Ebay, дешевле простопа раза в два-три (100mm: $85 /стекло/ с бесплатной доставкой против 100/150 фунтиков за пластик/стекло+ доставка), плюс еще вот хвалят.

Сегодня приехал 6-стопный (1.8D) и вот результат:

Это два кадра, с одинаковыми установками ББ в ACR (тупо Daylight, magenta cast не убирал), посередине там шовчик (на облаках видно, они уехали немножко пока фильтр снимал). По цвету - практически не отличаются, кривую яркости пришлось вывести по трем точкам, потому что:
  • Светорассеяние с фильтром заметно побольше, поэтому тени "поднялись"
  • Экспонометр в камере, не видя в положенном месте хайлайтов, разницу в экспозиции сделал примерно 1:100, вместо 1:64, снимок с фильтром получился малость недодержан.
Итого: я очень доволен. 10-стопный мне не нужен вроде бы, а 6-стоповый очень оказался хорош.

Про Adobe DNG и Adobe Bridge

Изучал тут поведение Adobe Bridge с DNG и XMP файлами, а оно смешное:

  • В DNG может быть XMP-секция, Bridge ее, естественно, читает. И пишет. Можно туда Keywords или рейтинги написать.
  • Если рядом с DNG лежит его XMP-файл (c тем же именем и, опционально, с тегом photoshop:SidecarForExtension="DNG"), то все берется оттуда, а XMP-секция в DNG - игнорируется.
  • Если начать редактировать метаданные, содержимое XMP + результаты редактирования будут записаны в DNG, а XMP-файл - удален.
  • С другими известными Бриджу файлами он так себя не ведет - пишет все в XMP (хотя в том же CR2 - может быть XMP-секция).
Меня это все сильно удивляло - ну сказано ведь "писать все в XMP", но нет.

А потом - доперло. Наберут по объявлениям. Типичный же workflow с DNG такой (если они не из камеры вылезают):

  • Запускаем DNG-конвертор
  • И фигачим DNG прямо в тот же каталог, откуда берем исходные RAW (сделать что-то отдельное - это ж морока)
В результате - в одном фолдере оказываются filename.raw, filename.dng, соответственно filename.xmp может быть только один. И прятать метаданные прямо в DNG - это хоть какой-то разумный выход из этой дурацкой ситуации. Потому что 8.3, завести filename.raw.xmp и filename.dng.xmp - не моги.

Вишенка на торте - поведение бриджа с файлами, которые он вроде бы знает (формат известен), а вроде бы и нет. Я пробовал с файлами от Sony A6000 (обычный ARW) и от Canon G1X Mark 2 (в этом файле есть XMP-секция):

  • Sony: писать метаданные отказывается, говорит не наш участок не знаю такого формата.
  • Canon: отказывается писать кейворды, но пишет рейтинги. Но пишет их не в сам файл (хоть там и есть XMP-секция) и не в sidecar-XMP, а в отдельный файл в каталоге .BridgeLabelsAndRatings (сказано, конечно, писать в XMP)
Все мысли на эту тему уже выражены в реплике Ильи. Количество специальных случаев, которые приходится обрабатывать, - удивляет.

Раскапывая RAW: Nikon Small NEF (NEF S)

Продолжаем традицию анонса наших публикаций. На этот раз на русском:

Раскапывая RAW: внутреннее устройство Nikon Small Raw

Для удобства ленивых читателей выводы вынесены в начало текста. Перевод на английский будет, но не мгновенно.

Комментировать можно там (требуется регистрация), можно тут, как удобнее.

P.S. И рабочий крик души про этот формат.

Q: embedded JPEG на вертикальных кадрах

Уважаемые читатели,

Если вас не затруднит, не могли бы вы сделать следующий эксперимент:

  1. Взять любой вертикальный кадр в RAW (или RAW+JPEG) с вашей камеры.
  2. Заглянуть в JPEG-часть (внутреннюю или внешнюю) Exiftool-ом (или чем хотите) и ответить на следующий вопрос:
    • Это действительно вертикальный JPEG (высота больше ширины)
    • Или он на самом деле горизонтальный (высота меньше ширины) и повернут тегом
Для Canon, Sony, Nikon у меня получился вариант два (поворот сделан тегом), но конечно я не все модели камер изучал. Хочется понять, есть ли камеры, которые пишут вертикальные JPEG-и для вертикальных кадров, или же оно всегда тегом.

UPD. В таком вот духе:

  1. exiftool -*image* -*thumb* -*preview* -a -e filename.raw
Оно выдаст пачку *width/*height (на все картинки, что есть в файле), интересен случай, когда blablaHeight больше blablaWidth.

Про дюральки Sunwayfoto (или не Sunwayfoto?)

Как я уже писал, Sony A7R подвержена Shutter Vibration, по меньшей мере на длинных фокусах. Следовательно, под объектив нужны подпорки в таком вот духе.

Я подумал, что в такой простой штуке испортить что-то сложно и заказал Long lens support package имени Sunwayphoto. По смыслу, это то же самое что и у RRS, но в 3.5 раза дешевле (а с учетом доставки - и вчетверо). Разница только в том, что у RRS в комплект входят двусторонние челюсти "с одной ручкой", а у китайцев - две пары, свинченные.

Имею по этому поводу сказать следующее

  • С учетом цены - качеством я доволен.
  • Без учета цены - нет, не доволен:
    1. RRS делает 'camera bars' толще (жестче), но при этом прорезает в них большие дырки и они еще и легче получаются. Разница в весе - изрядная, процентов 20 при одной длине.
    2. У RRS больше внимания к мелочам:
      • Сантиметровые шкалы на этих самых camera bars (не нужны для lens support, но крайне полезны если из тех же палок лепить панорамную головку)
      • Мелкие челюсти можно соединить параллельно и перпендикулярно (мне надо - именно перпендикулярно), у китайцев - только параллельно.
      • 6-гранные головки в трех разных местах у китайцев - трех разных размеров. Нужно три ключа. Хватило бы и одного.
      • Универсальная Arca-style площадка, которая приехала в комплекте - сделана из совсем странного дюраля. Слишком легкий, легко шоркается, в голову приходит слово "силумин", но доказать не могу. У всего остального металл, по первым впечатлениям, нормальный. Не исключаю, правда, что площадку подложили от широты китайской души, в описании лота на eBay ее нет.
    3. Есть, впрочем, обратный пример: у Sunwayphoto везде вкручены стопорные винтики, которые не дадут хреновине выскочить из головки самопроизвольно. У RRS - не везде.
Короче, по price/performance китайцы выигрывают вчистую (при разнице в цене вчетверо - немудрено), но если вы экономите граммы/удобство - то понятно за что RRS берет деньги. Лично я буду у кетайцев брать только то, что трудно испортить (хотя вот головы штативные Sunwayphoto - хвалят уважаемые люди).

Update: читатели заметили, что это может быть вовсе не Sunwayfoto, а просто непонятный китай. И действительно, те же camera bars у SWF на сайте - с сантиметровыми рисками и вообще все сильно отличается.

Вполне возможно, что мне приехал безымянный (и потому такой дешевый) китай.

Q: Garmin GPSMAP 64s

Оказывается, Гармин выпустил GPSMAP 64s.

Совсем как я хочу: 62s c бриджем и монашками ГЛОНАСС.

И даже в младшей модели, без s, есть слот для Micro-SD, то есть если кому не нужен компас-барометр, те могут сотку поэкономить без страданий о месте для карт.

Так вот, мои вопросы

  • Щупал уже кто? Я пару обзоров в сети нашел (и, грубо, пишут "тот же 62s, только приемник точнее"), но хочется еще.
  • Кто-нибудь вживую с 600-м Орегоном сравнивал в смысле качества экранчика на ярком солнце?

Про адаптеры Canon - Sony E-mount

Как я уже писал, Sony A7R я купил как задник к имеющейся оптике Canon и Nikon. Соответственно, через переходники.

С оптикой Nikon-F все понятно: механический переходник, все как всегда, переходники подороже с поводком для Nikon-G, переходники подешевле без поводка, никакой фантазии. Отличаются, как водится, качеством изготовления, качеством чернения, но обсуждать особо нечего. У меня - Metabones, но подошел бы и любой другой попроще. Metabones в положительную сторону отличается только большим ходом кольца поводка диафрагмы, но принципиально важно это только для Nikon-G (а такой оптики у меня нет, версию для G-mount брал на всякий случай, там разницы $40).

С Canon ситуация полностью противоположная. Управление диафрагмой в этих объективах - электронное, следовательно нужен чип, который примет команды от камеры по протоколу Sony и странслирует их в команды Canon. При этом может работать и автофокус и стабилизатор. А может и не работать. А может вообще ничего не работать.

У меня таких (кэноновских) переходников теперь два (из текста - понятно почему) и имею про них сказать (применительно к моему парку оптики и камере Sony A7R).

Metabones Mark III:

  • Работает практически со всей моей оптикой кроме Canon 300/4L IS. Впрочем, автофокусной оптики у меня мало: Sigma 35/1.4, Canon: 70-200/4 IS, 135/2, 400/5.6, Tamron 28-75 (это который очень старый). С неавтофокусными цейсами и кэнонами - тоже работает (диафрагма закрывается, а больше там ничего и нет).
  • Автофокус весьма условный (очень медленный и дрыгается туда-сюда), но есть.
  • Качество изготовления: хорошее, мне нравится.
  • Внутренняя шахта - расширяется "наружу", у светосильной оптики виньетирование будет меньше, для несветосильной - вроде бы неважно.
  • Чернение шахты - средненькое. Пишут, что для тильт-шифтов надо заклеивать бархатом-самоклейкой, еще не делал, жду пока самоклейка приедет.
Проблема с 300/4, который у меня очень ходовой меня мучала и я купил еще один переходник Techart EOS-iNEXII:
  • 300/4 заработал. Ну то есть автофокуса нет, IS есть, диафрагма работает. Я счастлив.
  • Автофокус с другой оптикой работает хуже, чем в случае Metabones: 28-75 фокусируется еще медленнее, 135/2 - вовсе не фокусируется, дрыгается туда-сюда.
  • Возможно, автофокус у 135/2 спасет апгрейд фирмвары (он там wireless, в комплекте есть USB-адаптер для этого), но пробовать я не буду, боюсь что может отвалиться 300/4 ради которого все и затевалось.
  • Качество изготовления: хорошее.
  • Пятка для штатива шире чем стандартный Arca-style (и у Metabones и в исполнении RRS), но в винтовые челюсти RRS влезает. С защелками могут быть проблемы.
  • Шахта не расширяется наружу, с светосильной и Shift оптикой будут проблемы с винетированием бОльшие чем у Metabones.
  • Шахта оклеена бархатом, блестит меньше, чем метабоновская пластмасска.
Итого

Будьте готовы, что EOS-NEX/A7 адаптеров вам потребуется больше одного.

Помимо Techart, на Ebay есть еще адаптеры с маркировкой King (дешевле, примерно $160) и начали появляться еще более дешевые (сейчас вижу за $108, но видел и дешевле $100). Что у них внутри - мне неизвестно.

На списки совместимости оптики на Ebay смотреть, похоже, бессмысленно - один и тот же адаптер у разных продавцов может иметь разные списки. Это может быть разница в версии фирмвари, а может быть (и скорее всего) - просто копипастят друг у друга.

Подземный сверхзвуковой китайский EMS

Продолжаем тему посылок

Китай, доставка EMS-ом (бесплатным!): 7 марта оплатил, сегодня принесли.

При этом в трекинге, что в китайском, что нашем - только экспорт. Следов импорта, таможни и всего такого - никаких.

Q: про почту и таможню

Граждане читатели, а у кого какой опыт по срокам доезда обычной почты (не EMS)

  1. С Брянской таможни в Москву?
  2. С Питерской (Пулково) таможни в Москву
Че-то у меня фигульки из Китая поехали, впервые в моей практике, через эту растаможку. Раньше - один раз был Оренбург, все остальное - Москва.

О самозанятом населении

Платил налоги. Два дня. Заплатил. Сплю спокойно теперь.

Но. Там столько новаций в оформлении платежек, что ой. Гуглить "приказ минфина рф от 12.11.2013 № 107н", пересказывать не буду. У ПФР - тоже новации, той же системы (дополнительные метаданные записываются в несвойственные им поля документа)

Будьте внимательны, короче.

Про Raw и ББ

Все мы знаем, "установка баланса белого не влияет на RAW-значения".

Старожилы, впрочем, помнят одно исключение, Nikon D1.

На днях добавилось еще одно: Nikon D4s в режиме small raw - накладывает ББ перед записью оного RAW. И кто они после этого?

P.S. Не старожилы, но опытные, еще знают, что установки ББ могут влиять на замер (а значит и на RAW-значения).

P.P.S. Не вздумайте пользоваться этим никоновским small raw. Еще хуже кэноновского....

Читая changelog-и

Читаю Release Notes у Акрониса:
Rebranding

Acronis Backup & Recovery 11.5 is renamed to Acronis Backup. The advanced product editions are now called the Acronis Backup Advanced suite.

Понимаю это так, что бэкапить оно будет, а вот насчет Recovery - уже никто ничего не обещает.

RawDigger 1.0.5: обнаружение (возможной) постеризации в файлах Sony cRAW

Тема «потерь при сжатии» в файлах Sony cRAW (а этот формат используют все современные камеры Sony) поднималась у меня многократно. Вот только за последнее время:
  1. RawDigger 1.0.3: раскапывая Sony – описание (в очередной раз) формата данных и новых фишек RawDigger для его анализа.
  2. Sony cRAW ETTR: сжатие с потерями, теория и практика – практический пример поиска проблемных областей
  3. Sony A7: околозвездная постеризация – (ссылка на diglloyd.com) еще один пример, который был в точности предсказан.
Но для быстрой практической оценки изображения – имеющегося в RawDigger режима показа только дельт (относительно нуля) – оказалось недостаточно. Пришлось добавить еще один режим, о котором, собственно, эта заметка.

О светах у цифровых камер

Мы продолжаем публикации на тему "для чего нужна RAW-гистограмма":

RawDigger Histograms, part 3: Overexposure Shapes

Как и в прошлый раз, без русской версии, но там по картинкам почти все понятно.

Краткое резюме:

  1. Поведение в светах у разных ЦФК - разное. То есть производитель сам выбирает где делать талию где света обрезать, руководствуясь, в первом приближении, двумя соображениями:
    • Если не обрезать (Panasonic GM1 @ISO125), то можно использовать весь диапазон емкости пикселя, но вверху будет область нелинейности, pixel non-uniformity и все такое прочее.
    • Если обрезать "пониже" (Pentax K-3), то отрежется кусок потенциально-рабочей области (пусть и нелинейной, но кого это парит в светах)
  2. Поведение в светах у одной ЦФК - может отличаться (тот же Panasonic GM1), резать можно на разных уровнях (Canon).
  3. Максимумы в разных каналах - могут отличаться (Nikon).

Следует понимать, что правильная обработка светов - сильно отличается в разных случаях. Проще всего, понятно, если они "hit the wall" т.е. верхний нелинейный участок обрезали при записи RAW и сделать ничего больше нельзя, данные утеряны.

В случае же, если "странности в светах" присутствуют, они скорее всего будут сильно индивидуальны для каждого экземпляра камеры (pixel non-uniformity и все такое), а еще могут плавать в зависимости от фазы венеры .... разных обстоятельств (как я уже описывал на примере Oly EPL3).

Если никаких калибровок конкретной камеры не предполагается, то лучшее что может сделать автор конвертора - это таки обрезать данные ниже нелинейности. Хорошо, если для того же Panasonic GM1 (да и других панасоников, других кэнонов и т.п.) это делается конвертором на разных уровнях для нижнего и "остальных" ISO.

Но авторы конветора могут и не заморачиваться, у них 500+ камер поддержано, что теперь, каждую взять и отснять? Это дорого и долго (судя по одинаковым цветовым профилям разных моделей Sony NEX у Adobe - даже Adobe не заморачивается профилированием всех камер - сенсор похож? Следующий!).

Что, в связи с этим, нужно бы знать про сочетание "камера - используемый конвертор":

  1. Есть ли "странности в светах" у камеры.
  2. Меняются ли эти странности в зависимости от ISO.
  3. Где конвертор реально режет данные.
  4. Делает ли он это правильно при смене ISO.
  5. Какие ISO (в связи с вышеизложенным) не стоит использовать.
P.S. Проще всего, по всей видимости, сделать неконтрастную мишеньку (серые буквы на сером фоне, а еще лучше - синие на красном), осветить ее одним источником света под углом и снять с такой экспозицией, чтобы один край ушел в пересвет, а второй - нет. Ну и дальше смотреть - что происходит с областями около насыщения. Одним глазом в конвертор, другим - в RawDigger.

Q: FreeBSD 10

Два вопроса
  1. Кто-нибудь уже использует FreeBSD 10 в бою?
  2. В апгрейде с 9.2 есть грабли какие-нибудь?

Я прийшов, а тебя два!

В прошлой заметке я написал:
После этого начинаешь любить Win32 особенно остро.
Это продолжалось недолго, я познакомился с Registry Redirector в WOW64. В сочетании с тем, что в в Win7 оно отличается от более старых версий.

Я прийшов, тебе нема

Вот есть такой вызов, strnlen:

     size_t
     strnlen(const char *s, size_t maxlen);

DESCRIPTION
     The strnlen() function attempts to compute the length of s, but never scans beyond the
     first maxlen bytes of s.
И он есть, например, в Mac OS X 10.7 и новее.

Берем код с этим вызовом, собираем с -mmacosx-version-min=10.5 (должен получиться совместимый c 10.5 код, да?) на 10.8, несем на 10.6, запускаем.

Все падает.

И ладно бы падало с внятным сообщением, вот не могу залинковать такое. Нет, SIGSEGV, нулевой указатель (на функцию?).

После этого начинаешь любить Win32 особенно остро.

Про гистограммы RawDigger

Два текста про гистограммы RawDigger (наверное, со временем станут частью мануала): На русском языке, увы, не существуют.

P.S. В конце второго текста есть ссылка на полезняшку, шкалу Q13 в DNG. Помогает понять тоновую кривую вашего конвертора, например.

Sony A7: околозвездная постеризация

Год с хвостиком назад, когда я в первый раз озаботился соневским cRAW, я из общих соображений предсказал, что должны быть проблемы на кадрах типа "звезда на фоне темного, но не черного неба".

И таки да. Вот у Ллойда Чамберса: нашелся пример (промотать до раздела Example).

UPD: Ллойд завел отдельную страничку под это чудо.

Такие дела.

И таки да, со star trails все плохо т.к. в артефактах будет весь снимок, не начистишься (лечение - убирать небо в черноту, но не всегда это годится).

Экспозамер: для RAW или для JPEG?

Меж тем, у нас родился текст (и видео):

Exposure for RAW vs. Exposure for JPEG

Это продолжение и развитие уже поминавшегося в данном бложике текста Ильи, но продолжение и развитие было уже на басурманском наречии, русского оригинала не существует.

Ну и многие примеры поминались/обсуждались у меня в комментариях.

Sony cRAW ETTR: сжатие с потерями, теория и практика.

Продолжим обсуждение ETTR на камерах Sony (первая часть тут) и разберемся с lossy-компрессией и ее возможным влиянием на ETTR.

Напомню устройство сжатия с потерями в этом формате:

  • Строка изображения разбивается на блоки по 32 пиксела, в каждом из блоков содержатся пиксели двух цветов, зеленого и какого-то еще из двух оставшихся, по 16 пикселов каждого цвета.
  • Для этих 16 пикселов записываются
    • Минимальное и максимальное значение в 16-пиксельном блоке – с точностью 11 бит.
    • Координаты минимума-максимума (номер в блоке).
    • 14 остальных пикселов кодируются в виде дельт с 7-битной точностью.
    • Шаг дельт равен (максимум – минимум) / 128 (округленное до ближайшей бОльшей степени двойки).
    • Соответственно, если (максимум – минимум) в блоке больше 127, то шаг дельты - больше единцы, то есть дельта-кодирование записывает значение пиксела приближенно.
  • После раскодирования дельт, к раскодированным значениям применяется тоновая кривая, о которой подробно писалось в прошлой заметке
Приведем эту тоновую кривую еще раз:
Как мы видим, наклон кривой в области «тени-полутона» равен 2, в самых светах – 32, в промежутке – (ступенчато) меняется.

Посмотрим теперь, как тоновая кривая сочетается с дельта-кодированием.

Q: Qt 5.2 и Retina

Граждане разработчики,

Особенно использующие Qt, вы же тут читаете, я знаю.

Вот есть Qt 5.2 и Маки с ретиной. Надо, значит, чтобы было Щастье.

На самом деле, 99% Щастья есть сходу: если в Info.plist написан NSPrincipalClass, то все стандартные элементы (шрифты, к примеру) рендерятся в ретину и все работает.

Но.

У меня используется свой OpenGL-код, который зовется из QGraphicsScene::drawBackground(). Он, понятно, сходу рисует в четверти окошка в таком случае.

Эксперименты показали, что достаточно поменять одну строчку. Вместо:

  1. glViewport(x,y,w,h);
написать
  1. int dpr = painter->device()->devicePixelRatio();
  2. glViewport(x*dpr,y*dpr,w*dpr,h*dpr);
И все начинает (вроде бы?) работать как надо. Зумится, ротейтится, сдвигается - все вроде как надо.

Так вот, вопрос: Что Я Делаю Не Так?. Не упускаю ли я что-то важное?

P.S. Рассматривание кода Qt-шных примеров не дало ответа. А именно: в части примеров делают именно так. И все работает. А вот в qtbase\examples\widgets\graphicsview\boxes - вообще нет никакого следа devicePixelRatio(), все каким-то чудом работает "само" (и ретина поддерживается нормально)

Syndicate content


.