-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: luma(Y) and lightness(L) #3
Comments
Мой взгляд на развитие ST не поменялся:
Поэтому я не хочу тратить время на добавление очередных переключателей в фильтры, на новые типы областей и т.п. - это все большие трудозатраты с маленьким кпд. Я уже потратил на возню с ST больше времени, чем потенциально выиграл бы, даже если бы уже прикрутил туда фотошоп. Чисто по трудозатратам для меня уже логичнее эту возню прекратить; не хочется только бросать, раз уж начал; успокаиваю себя тем, что по дороге что-нибудь полезное выучу. Однако, добавление вызова внешней программы ломает всю логику обработки. Надо менять все, начиная с идентификаторов изображений, через все вызовы фильтров по дороге, и до кеша изображений. Потому я и туплю сейчас над превьюшками: они - частный случай подмены изображения. Чтобы поменять логику, надо сначала выяснить, в чем она состоит. Пара дней игр с отладчиком оставили портянку вызовов под сотню строк с десятикратными уровнями вложенности, и нелнейными вызовами каких-то обработчиков событий и потоков, в которых я теперь не могу понять, как там параметры передаются: они все запрятаны в виде сплошных ссылок друг на друга внутри десятков классов. Не зря, видимо, у всех версий ST есть глюки в пакетной обработке, не я один там запутался. Теперь еще столько же времени надо потратить, чтобы и передачу данных отследить. А потом еще что-нибудь всплывет. Видимо, до моего следующего коммита хоть на какую-то тему пройдет несколько месяцев. |
@noobie-iv say:
Так спецом для этого же в ST расчёт какого то хэша встроен. Просто запоминать хэши и добавить в нужных местах проверку их же? Не? |
Там имена файлов кеша вычисляются по имени исходного файла и номеру страницы (0/1). А если какой-то фильтр по дороге сделал подмену картинки, у Id от этого ни имя файла, ни номер страницы не меняются. И, когда превьюшки рисуются, они грузятся в отдельном потоке, в который просто передается исходный Id страницы - т.е. по существующим Id превьюшка не может понять, что ей нужно из другого файла загрузиться. Разве что в сам хеш идентификатор подмены примешивать - но это и значит, что надо править и работу хешей, и все вызовы от них до фильтров, а там несколько уровней вложенности. И в сам Id, который где-то в списке в главном окне лежит, тоже надо сведения про подмену внести, иначе как про них превьюшки узнают. А подмен может быть несколько, в разных фильтрах (например, если деварп тоже дать внешний использовать). И даже у одного фильтра может быть несколько подмен, если разрешить несколько внешних действий при обработке делать. А еще вызов внешней программы нельзя на автомате повторить (например, кисточкой в фотошопе поводил), придется обработанную картинку сохранить на будущее, и дальше использовать обработанное изображение - значит, надо добавить еще кеш основных изображений. И подружить этот кеш с кешем превьюшек, да еще так, чтобы превьюшки не читались раньше, чем главное изображение. А то сейчас в трассировках обращения к кешу превьюшек раньше генерации основного изображения выскакивают. Да я даже до сих пор не понял, почему при одном переключении на другую стадию обращения к превьюшкам по несколько раз происходят. То ли это просто неоптимальное дублирование от повторной обработки каких-то GUI-событий, то ли там где-то параллельно какие-то другие данные меняются, которые я еще не обнюхал как следует. Короче, либо я тут сильно застрял, либо сильно затупил 😄 . |
Посмотри ветку plus. В ней как раз решалась "проблема" с превьюшками и фиксацией выполнено/невыполнено. |
Hi @noobie-iv .
Так как проблемы с кешем в STEX свели её разработку с моей стороны в ноль, то буду участвовать в развитии STD. Но аккуратно.
❓ Вопрос: сейчас для порогов используется компонента яркости (Y), посредством преобразования исходного изображения в
GrayImage
. Но это не единственное известное преобразование в серое. Из самых распространённых назову светлоту (L). Результат порога по яркости (Y) и светлоте (L) несколько отличается. Не стоит ли внести в STD переключательY/L
?The text was updated successfully, but these errors were encountered: