Анонсирован открытый колориметр ColorHug

Лично мне бы хотелось healing brush, clone stamp, liquify и, таки, рисовать на screen/multiply слоях. Но с меня-то спрос маленький.

Я очень хорошо тебя понимаю, в общем-то :)

Единственное, что мне в это разрезе нужно: это чтобы при просмотре на экране снимки, сделанные цифромыльницей, соответствовали реальности хоть в какой-то степени. Печать для меня действительно избыточна. Это как-нибудь решается?

У-у-у-у... Ты не представляешь какое количество деталей в этом вопросе, в которых дьявол.

Предположим типичный случай байеровского сенсора. Что там за фильтры на нём RGB — сложный вопрос. На разных сенсорах они разные, Никон, например, ослабляет фильтры (как минимум в некоторых камерах), чтобы получить лучше высокие ISO, кто-то фильтрует зелёный 555 nm, кто-то 560 nm — и пр. Т.е. изначально данные со сферического сенсора уже не имеют абсолютного значения. Затем мыльница преобразует байеровское изображение в «нормальное» — каким алгоритмом? Да фиг его знает, а от этого тоже многое зависит и в цвете тоже. Затем мыльница накладывает какие-то корректировочные кривые, шарпит, мылит и прочие эффекты. Что там на выходе в жипеге — фиг знает, хоть и считается, что это sRGB, в типичном случае. Если кто-то ставит другой профиль, то он должен знать что делает. Т.е. ещё до того как фотка попадёт на компьютер, преобразования в мыльнице уже каким-то образом испортили («улучшили») изображение, что было в реальности. Но это всё фигня, по сравнению с тем, что пусть даже всё было идеально, и жипег соответствует очень точно тому что было, наш мозг может быть при этом кардинально не согласен, он помнит по-другому. Не просто по-другому, но даже от настроения и твоего воспоминания об этом настроении зависит. Это не говоря про автоматическую корректировку баланса белого в голове, автоматическую корректировку экспозиции к разным участкам изображения, на которое смотрели твои глаза, ну и т п.

В общем, для сферического пользователя тут один совет: крутить крутилки, пока не станет «зашибись», колориметр ему нафиг не нужен.

3. Ну и понеслась...

Да, я что-то такое думал. Но в частных случаях проблема так или иначе решается, типа того же darktable.

Хочется схемы вида: есть эталонное изображение, которое фотографируем мыльницей и кажем цветометру на экране, а цветометр сообщает экрану что нужно подкрутить.

Таких много в интернете. Без колориметра, просто глазами. Это ещё проще для сферического пользователя.

> У-у-у-у... Ты не представляешь какое количество деталей в этом вопросе, в которых дьявол.

А зачем мне? Я же сферический в вакууме пользователь :)

В общем, для сферического пользователя тут один совет: крутить крутилки, пока не станет «зашибись», колориметр ему нафиг не нужен.

У меня есть сомнение, что это хороший совет. Точнее я уверен, что это плохой совет. Сферический в вакууме пользователь затрудняется сказать когда будет «зашибись» — это _основная_ проблема. Автомат нужен именно для сферического в вакууме пользователя, а вот профи вполне может и с помощью крутилок всё настроить.

У меня есть сомнение, что это хороший совет. Точнее я уверен, что это плохой совет. Сферический в вакууме пользователь затрудняется сказать когда будет «зашибись» — это _основная_ проблема. Автомат нужен именно для сферического в вакууме пользователя, а вот профи вполне может и с помощью крутилок всё настроить.

У меня есть сомнение, что сферическому пользователю не пофиг вообще. Внимание к деталям — это уже не сферический пользователь. Поэтому, я вообще не понимаю о чём речь.

Не пофиг, так как я его яркий представитель :)

Речь идёт об автоматической подстройки экрана под реальность.

Речь идёт об автоматической подстройки экрана под реальность.

Вау. Мне кажется, это уже к психотропным препаратам надо прибегать ;)

> Ты просто потрясающее хамло.
О, я вас узнал. Капитан, это же вы?!

Анонимус заметил весьма справедливо - при наличии альтернатив

(от Атмела, или АРМы ) использовать микроконтроллер,

который наименее всего совместим с опенсорсом и называть это

решение «свободным» - как-то глупо и нелогично.

Вот и я не понял - зачем сватать штуку как якобы для линуксоидов и при этом использовать максимально враждебный к оным камень, программируемый только под виндовозной прогой, когда вокруг полно камней фирмварь к которым можно было написать в обычном гцц. Кстати еще нелогичный момент: изучать 2 комплекта компилеров вместо 1 - ну не впадлу же, да? Хотя у подтролленого вами господина похоже логики тоже нет.

Ричард крут, я его уважаю ещë с тех пор, когда начал работать над PackageKit. :-) Желаю ему успешных продаж ColorHug. :-)

IMHO зря так. Это было бы действительно фишкой. Ну нельзя — так нельзя.

Когда же анонимус наконец перепишет всё на AVR? :)

>> У меня есть сомнение, что сферическому пользователю не пофиг вообще.

Не пофиг, так как я его яркий представитель :)

Мне только кажется, или кто-то здесь кокетничает? :)

> У меня есть сомнение, что сферическому пользователю не пофиг вообще. Внимание к деталям — это уже не сферический пользователь.

А если у меня 2 разных монитора, например, LCD и CRT, и я хочу их быстро заставить более или менее одинаково показывать фотки?

Если чесно, то вот пофик - синие морды на картинке, или зеленое тело. Глаз человека (типа меня) легко адаптируется.

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

В смысле? Человек может быть спецом в одной области и сферическим в вакууме пользователем в другой. Вопрос цветопередачи для меня является последним.

Прогрессоры среди нас :)

Это было бы действительно фишкой. Ну нельзя — так нельзя.

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

> линукс - в первую очередь стабильность и удобство разработки.

Я тебя разочарую. Далеко не все пользователи Linux - разработчики чего-либо. Есть просто пользователи.

> У меня дома вроде IPS. Цветомер мне поможет?

А чего ты хочешь добиться? Чего не хватает? Ты знаешь, зачем он тебе нужен?

Скорее всего он тебе поможет, но он тебе не нужен, т.к. поможет в чем-то очень второстепенном для тебя.

> А хочется именно одного - удобного растрового редактора, с нерудиментарной поддержкой основных цветовых пространств, слоёв (в т.ч. корректирующих), смешения каналов и набором инструментов для выборочной коррекции. Если он ещё и в 32float будет работать, будет вообще отвал башки.

А че такой редактор вообще есть?

P.S. Photoshop в 32 бита почти ничего делать не умеет, в 16-ти кое-какие возможности уже работают, и только в 8 битах он пашет в полный рост.

P.P.S. HDR придумали всего лет 6 назад.

> А чего ты хочешь добиться? Чего не хватает? Ты знаешь, зачем он тебе нужен?

а) фотографии на разных компьютерах выглядели одинаково (как я понимаю это проще всего)

б) походили на то, что запомнил мой мозг

Ой, только не нужно рассказывать как это сложно — сложными словами не запугаешь, так как я их всё равно не понимаю.

Вопрос1: можно это сделать или нет?

Вопрос2: можно ли этот процесс деланья автоматизировать?

Вопрос3: причём тут цветометр?

Подозреваю всем лоровцам данный девай нужен для тонкой настроки шрифтов :-)

>Сколько лет пилят GIMP, OpenOffice, Scribus (добавить по желанию) и все это еще не дотягивает до коммерческих образцов?

Это пока у тебя оперативка резиновая. Я помню сколько у друга-дизайнера на компе фотожоп грузится.

И потом - для редактирования картинок для курсовых гимпа вполне хватает. И LOо тоже имхо удобнее последних MSO

Кстати, а почему бы и нет?

> P.S. Photoshop в 32 бита почти ничего делать не умеет

Последней версией, которую ты видел, был CS2? :)

Я huey, дорогая редакция.

В интернет-магазине одной новосибирской фирмы сразу за названием писалась транскрипция — [хью]. И в рекламе в фотожурналах, вроде.

Кто знает, что там за датчик? А то файл схемы посмотреть нечем. Какие-то конкретного типа фототодиоды? Автор калибрует по имеющемуся у него калибратору. Т. е. наверняка есть процесс калибровки (цветовой датчик ведь индивидуален), выставления коэффициентов для каждого из каналов и прописки их в прошивку. Т.е. помимо виндовой софтины (MPLab) нужен наверняка ещё образцовый колориметр. Кстати, насчёт отсутствия для PIC18 софта под Linux - это ещё надо проверить, а не верить одному-двум анонимусам сходу (резонно, кстати, возмущающимся). Что-то тут недавно пробегало в новостях про свежий софт для контроллеров, и даже как бы не под пики.

Кто знает, что там за датчик?

Вот пишут что сенсор TCS3200, который, будучи установлен на плате, с дополнительными светодиодами подсветки в комплекте, стоит не дороже 8 баксов.

Добавить любой дешёвый AVR бакса за три-четыре и адаптер к USB за те же 3-4 бакса - и будет готовое устройство. Откуда автор придумал 48 фунтов - непонятно.

Какой же это GPL, если полный vhdl-код микроконтроллера не выложен?

> Добавить любой дешёвый AVR бакса за три-четыре и адаптер к USB за те же 3-4 бакса - и будет готовое устройство. Откуда автор придумал 48 фунтов - непонятно.

Ты думаешь, что у него там фабрика по производству комплектующих дома? 48 — это реально предел окупаемости.

Перетащить код на другой камень вовсе несложно. Только код весьма странный. Вот например измерение частоты:

/**
 * CHugTakeReading:
 **/
static UINT16
CHugTakeReading (void)
{
	UINT16 i;
	UINT16 cnt = 0;
	unsigned char ra_tmp = PORTA;

	/* count how many times the output state changes */
	for (i = 0; i < SensorIntegralTime; i++) {
		if (ra_tmp != PORTA) {
			cnt++;
			ra_tmp = PORTA;
		}
	}

	/* scale by the integral time */
	CHugScaleByIntegral(&cnt);

	return cnt;
}

Ты думаешь, что у него там фабрика по производству комплектующих дома? 48 — это реально предел окупаемости.

Расскажи это разработчикам Raspberry Pi

О каких измерения тут может идти речь непонятно.

Лютый п-ц. А вот использовал бы он Атмел, то мог бы просто задействовать аппаратный таймер в input capture режиме и получал бы длительность импульсов с точностью до такта генератора. Независимо от режима оптимизации, определяющей за сколько тактов будет такой цикл, и независимо от работы прерываний, которые автор вроде не запретил на время цикла. Вобщем устройство годится только для пользователей 8-ми разрядного ГИМПа, которым нужен формальный функционал, а не сколько-либо приемлемое качество.

Причём здесь AVR? 18.0 ENHANCED CAPTURE/COMPARE/PWM (ECCP) MODULE PIC18F46J50 family devices have two Enhanced Capture/Compare/PWM (ECCP) modules: ECCP1 and ECCP2. These modules contain a 16-bit register, which can operate as a 16-bit Capture register, a 16-bit Compare register or a PWM Master/Slave Duty Cycle register. These ECCP modules are upward compatible with the standard CCP module found in many prior PIC16 and PIC18 devices.

Причём здесь AVR?

Ну сам же видишь, разработчику под PIC не удалось задействовать эти роскошные возможности аппаратной платформы - видимо есть тому резон: либо у микрочипа камни полное говно, либо автор проекта норкоман. Но не можем же мы плохо думать об авторе опенсорсного проекта который нельзя скомпилировать опенсорсными средствами или хотя бы схему посмотреть с помощью EESchema. Значит проблема в PIC-ах, однозначно.

Жаль, что не калориметр.

AP> Разве нет? :)

Судя по Humble Bundle - нищеброды как раз пользователи Windows. И они зачастую не могут найти работу, на которой даже не могут заработать на лицензию фотошопа ;)

Korwin> Сколько лет пилят GIMP, OpenOffice, Scribus (добавить по желанию) и все это еще не дотягивает до коммерческих образцов?

На практике уже дотянуло.

Evgueni> А сферическому в вакууме пользователю оно нужно?

Оно и не для простых смертных. Эта штуковина нужна для профессиональных нужд.

С чего ты взял, что он неточный?

ну схему допустим хорошо видно gschem.

GPL EDA — проектирование электронных устройств (редактор схем) Проект gEDA создал и продолжает вести работу над набором GPL-инструментов системы автоматизированного проектирования электроники. Эти инструменты используются для проектирования электронных устройств, создания схемотехники, эмуляции, создания прототипов и производства. В настоящее время проект gEDA предлагает сложившийся инструментарий проектирования электронных устройств, состоящий из свободных программ для создания схемотехники, редактирования атрибутов, создания списка элементов, списка соединений (в более чем 20-ти форматах), аналоговой и цифровой эмуляции, и топологии печатной платы. . Пакет содержит утилиту gschem, редактор схем.

либо автор проекта норкоман

Норкоман? Девушка-мажор, что-ли?

> Расскажи это разработчикам Raspberry Pi

А что, им интересно меня слушать? :)

Нет, хоббит.

> Расскажи это разработчикам Raspberry Pi

А что, им интересно меня слушать? :)

Не понимаю почему тебя это заботит в случае разработчиков Raspberry Pi - ведь здесь же ты не задаёшься таким вопросом.

Софт на плюсах падает, и если он сумеет попортить стек, то искать ошибку придется вечность. Очень весело на живом сервере ставить дебажные символы и собирать коредампы из софта который падает раз в неделю/месяц. GC не мешает писать качественный софт, а его отсутствие - мешает.

c++ переносим весьма относительно - гуи не переносим например. c# я предлагаю именно как клиентский язык. Судя по тому что ты пишешь - ты не пользовался c#. Как ты можешь утверждать что-то про производительность и память - мне не понятно. Если у тебя предубеждение против runtime и gc - это твои проблемы. Я могу сказать, что передача объектов _всегда_ по ссылке быстрее, чем копирование, а gc быстрее чем new/delete.

Софт на плюсах падает

Я же удалял уже в этой новости кучку оффтопика. Обсуждение падучести с++ надо вести в соответствующем разделе. Кому скор не нужен, можете продолжать оффтоп.