Зачем настройка DPI для монитора? Какой сакральный смысл в этом?

Ну, хотелось бы чтобы на мониторе все отображалось в реальных размерах при 100% увеличении.
http://prophotos.ru/data/articles/0001/6771/103640/thumb_630.jpg

Ну, и классический пример: померять линейкой приставленной к монитору
http://eurica.net/images/other/dkrulerss-demo.jpg

Desktop, а шо? :)

Это не DPI для монитора, а настройка превьюв 1:1. Обычно под понятием «DPI для монитора» подразумевают внутреннее соотношение между точками и дюймами. В sK1 это 72 dpi (как в постскрипте/пдф), у Inkscape это значение несколько раз меняли (спроси у AP детали).

Так а как этот «Desktop» в переводе будет? «Рабочий стол» («Цвет рабочего стола»)?

Ну да.

В sK1 это 72 dpi (как в постскрипте/пдф)

Так а в чём проблема сделать его настраиваемым? (+ кнопка «По умолчанию», которая бы сбрасывала на 72dpi)

Вот к примеру, в OOMapper (который как бы «Cartographic DTP», тоже для PDF и печати полиграфии) есть данная опция. У меня монитор 96dpi.

Да не связано это с монитором. Ну ваще никак. Это пересчет единиц измерения внутри аппликухи. Если он плавающий, будут косяки как у Инки со старыми файлами.

Для превьюв 1:1 нужно специальные настройки. Тем более, что у мониторов разные dpi по вертикали и горизонтали.А на качество картинки канвы этот показатель совсем не роялит.

Для превьюв 1:1 нужно специальные настройки.

Я как раз это подразумевал. Именно эту функциональность хотелось бы увидеть в sK1 2.0

Тем более, что у мониторов разные dpi по вертикали и горизонтали

Разве пиксели не должны быть квадратными на матрице монитора?..

Write *.ACO support

https://github.com/olivierberten/SwatchBooker/issues/10

related

AzPainter 2.0.1 (комментарий)

Разве пиксели не должны быть квадратными на матрице монитора?..

Они никому ничего не должны :)

https://youtu.be/f7TCkoEM0hg

Write *.ACO support

Можно написать и Write *.CDR support, но не факт, что будет выхлоп :)

Ну, насчёт ACO - там есть ссылки на готовые примеры.

Write *.CDR

А при чём здесь CDR? CDR - это же файл проекта, а не файл палитры (в отличии от ACO)

Палитру можно и в векторный формат выгнать - прямоугольниками с соотв. заливкой.

AzPainter (в принципе) может сам сгенерировать палитру на основе таблицы в виде растрового изображения (PNG, Jpeg, и т.д.)

Но это не совсем то же самое, что и загрузка уже готовых файлов палитр в форматах GPL, ACO и ASE

Ладно, уболтал - сделаю за пару-тройку дней (если ничего не помешает) для ACO импорт/экспорт в sK1 ;)

Пантон распространяет свои палитры в формате EPS, например. Scribus их оттуда даже читает.

Это не относится к теме форматов палитр.

Насколько я знаю, эталонные пронумерованные цвета PANTONE MATCHING SYSTEM® напечатаны в специальном каталоге и вроде не распространяются в электронном формате. Где-то даже упоминалось что только полиграфическое исполнение изданное (отпечатанное) компанией-правовладельцем (Pantone Inc., позже купленная компанией X-Rite Inc.) является единственно верным. И только с официальным напечатанным каталогом можно сравнивать цвета.

https://en.wikipedia.org/wiki/Pantone

Так-что приведенный пример с EPS вообще здесь неуместен.

Насколько я знаю, эталонные пронумерованные цвета PANTONE MATCHING SYSTEM® напечатаны в специальном каталоге и вроде не распространяются в электронном формате.

https://www.pantone.com/pantone-color-manager-software

Где-то даже упоминалось что только полиграфическое исполнение изданное (отпечатанное) компанией-правовладельцем (Pantone Inc., позже купленная компанией X-Rite Inc.) является единственно верным.

Ну да, а сервис Xref и упомянутый выше софт они запустили так — чисто прикольнуться.

Я не буду спорить, но в стандартах печати для спортивной картографии «ISOM 2000» указанно как раз об некоторых особенностях PMS:

http://orienteering.org/wp-content/uploads/2010/12/International-Specificatio...

В принципе уже обсуждается возможность перехода на CMYK (как более дешевый и не столь проприетарный) в новом стандарте «ISOM 2017», который должен утвержден в этом году.

http://www.attackpoint.org/discussionthread.jsp/message_1181618

В OOMapper есть некоторая поддержка PMS

http://www.openorienteering.org/mapper-manual/pages/mapping-introduction.html

Тут не о чем особо спорить.

https://www.pantone.com/software-licensees

«Pantone licenses our proprietary color systems, like the PANTONE MATCHING SYSTEM®, and the PANTONE FASHION, HOME + INTERIORS Color System to companies for use with their digital solutions.»

Поэтому палитры Пантона есть по умолчанию у Адоба, Корела и прочих Кварков. В электронном виде.

Делается это ровно для того, чтоб не надо было ручками вбивать название краски из каталога. Подобрал цвет по вееру, щёлкнул в софте нужный квадратик — и сгенерил правильный PDF. Профит! :)

Вот поэтому я сразу и сказал, что твой пример неуместен

конвертировать цвета из одного цветового пространства в другое

То есть, я могу снимать в инфракрасном диапазоне и всю картинку конвертировать в видимый?

Мне непонятна твоя логика, ну да ладно.

Если есть профайл, описывающий снимающее устройство (тот же пассивный прицел ночного видения), то можно сконвертировать в видимый RGB диапазон. Скорее всего, в этих шелезяках так оно и работает, но не на основе lcms.

atsym хорош резвиться на кормовом участке :) В sK1 палитры ACO завезли - пробуй:

https://sk1project.net/viewpage.php?page_id=24

Preferences > Palettes > Palette Management > Import|Export

Что, уже? ;)

P.S.: забрал

ACO-палитры в программах sK1 2.0 и AzPainter 2.0.2 (Linux)

Взял для примера вот «metro-ui-colors.aco» отсюда:
>>> https://github.com/englishextra/metro-ui-colors

Вот скриншот
>>> http://pasteall.org/pic/index.php?id=112900

Пояснение (слева направо)

• в sK1 2.0 (импорт оригинальной «metro-ui-colors.aco»)
  @ цвет «crimson» = R-161 G-0 B-36
• в AzPainter (импорт пересохраненной через sK1 палитры «metro-ui-colors_sk1.aco»)
  @ цвет «crimson» = R-162 G-0 B-37
• в AzPainter (импорт оригинальной «metro-ui-colors.aco»)
  @ цвет «crimson» = R-162 G-0 B-37

В «metro-ui-colors.gpl» (GPL палитра) цвет «crimson» = R-162 G-0 B-37

https://github.com/englishextra/metro-ui-colors/blob/master/metro-ui-colors.gpl

Выводы: в sK1 после импорта ACO значения всех цветов в RGB записи выглядят некорректно (не нулевые значения уменьшены на 1 пункт), при этом после экспорта в ACO файлах записи вроде выглядят нормально (после импорта в AzPainter).

При этом, к импорту/экспорту в AzPainter претензий НЕТ!

В sK1 все цвета передаются ввиде double float. Для красоты на экране демонстрируется 8bit значение (как в GPL палитре).

«Якась скотына» записала в ACO палитру дробное значение 161.9 (в ней значения хранятся в 16bit) В результате на экран выводится 161, а не 162. Нафига было записывать дробное, если оригинальные цвета заданы в 8bit - хз. Но для таких «хитросконвертированных» граждан добавил округление и теперь все норм.

Так и подозревал что проблема с округлением, но вычитывать данный ACO в HEX-редакторе было лень ))

Кстати, я так понимаю, что скоро в твоей «Palette collection» появятся и ACO вариант свободных палитр?(я надеюсь на это)

скоро в твоей «Palette collection» появятся и ACO вариант свободных палитр?

Не, пока обновлять не планирую. Для фотожопа и ASE годятся. Когда-нибудь «папизже» (с) :)

Ладно, буду конвертить через sK1 в ACO. Обнови «ночную» сборку

P.S.: «ты с этим вот, вот этим, этим всем доиграешься»(c) ;)

Ладно, буду конвертить через sK1 в ACO. Обнови «ночную» сборку

На конвертацию проблема округления не роялит. Некорректная цыфирь только в диалоговых текстах. На канве и в потрохах гораздо более точные значения, чем 8bit или 16bit.

Но из чуйства перфекционизьму сборку таки обновлю :)

palette-collection_1.0_ACO.zip

Сконвертил из GPL в ACO ;)

http://hnng.moe/f/NxF

Попутно исправил название (посмотри у себя также): "Lible_Colors.gpl" --> "Libre_Colors.aco"

«Якась скотына» записала в ACO палитру дробное значение 161.9 (в ней значения хранятся в 16bit) В результате на экран выводится 161, а не 162.

А чё, там floor() что ли? ЛОЛ.

Неа, вместо \хA2\x00 стоит \xA1\xFA. Там просто первые два байта брались для 8bit.