Skip to content
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

Open
zvezdochiot opened this issue Jan 9, 2024 · 4 comments
Open

feature: luma(Y) and lightness(L) #3

zvezdochiot opened this issue Jan 9, 2024 · 4 comments

Comments

@zvezdochiot
Copy link
Member

zvezdochiot commented Jan 9, 2024

Hi @noobie-iv .

Так как проблемы с кешем в STEX свели её разработку с моей стороны в ноль, то буду участвовать в развитии STD. Но аккуратно.

❓ Вопрос: сейчас для порогов используется компонента яркости (Y), посредством преобразования исходного изображения в GrayImage. Но это не единственное известное преобразование в серое. Из самых распространённых назову светлоту (L). Результат порога по яркости (Y) и светлоте (L) несколько отличается. Не стоит ли внести в STD переключатель Y/L?

@noobie-iv
Copy link
Member

Мой взгляд на развитие ST не поменялся:

  • У ST есть фишки, которых нет в аналогах: автонарезка, развертка, удобный макет и т.п. Из-за них я и пользуюсь ST, а не фотошопом.
  • Однако, фишек по обработке изображений тут явно не хватает. Из-за этого я вынужден дорабатывать картинки после ST, что неудобно.
  • Если начать прикручивать недостающие фишки в сам ST, это будет попытка сделать "фотошоп на базе ST". Это слишком много работы, и слишком сложно для непрограммистов.
  • Я вижу только один относительно простой вариант - добавить возможность вызывать внешние программы там, где не хватает возможностей самого ST.

Поэтому я не хочу тратить время на добавление очередных переключателей в фильтры, на новые типы областей и т.п. - это все большие трудозатраты с маленьким кпд. Я уже потратил на возню с ST больше времени, чем потенциально выиграл бы, даже если бы уже прикрутил туда фотошоп. Чисто по трудозатратам для меня уже логичнее эту возню прекратить; не хочется только бросать, раз уж начал; успокаиваю себя тем, что по дороге что-нибудь полезное выучу.

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

Чтобы поменять логику, надо сначала выяснить, в чем она состоит. Пара дней игр с отладчиком оставили портянку вызовов под сотню строк с десятикратными уровнями вложенности, и нелнейными вызовами каких-то обработчиков событий и потоков, в которых я теперь не могу понять, как там параметры передаются: они все запрятаны в виде сплошных ссылок друг на друга внутри десятков классов. Не зря, видимо, у всех версий ST есть глюки в пакетной обработке, не я один там запутался. Теперь еще столько же времени надо потратить, чтобы и передачу данных отследить. А потом еще что-нибудь всплывет. Видимо, до моего следующего коммита хоть на какую-то тему пройдет несколько месяцев.

@zvezdochiot
Copy link
Member Author

@noobie-iv say:

Однако, добавление вызова внешней программы ломает всю логику обработки.

Так спецом для этого же в ST расчёт какого то хэша встроен. Просто запоминать хэши и добавить в нужных местах проверку их же? Не?

@noobie-iv
Copy link
Member

@zvezdochiot

Там имена файлов кеша вычисляются по имени исходного файла и номеру страницы (0/1). А если какой-то фильтр по дороге сделал подмену картинки, у Id от этого ни имя файла, ни номер страницы не меняются. И, когда превьюшки рисуются, они грузятся в отдельном потоке, в который просто передается исходный Id страницы - т.е. по существующим Id превьюшка не может понять, что ей нужно из другого файла загрузиться. Разве что в сам хеш идентификатор подмены примешивать - но это и значит, что надо править и работу хешей, и все вызовы от них до фильтров, а там несколько уровней вложенности. И в сам Id, который где-то в списке в главном окне лежит, тоже надо сведения про подмену внести, иначе как про них превьюшки узнают. А подмен может быть несколько, в разных фильтрах (например, если деварп тоже дать внешний использовать). И даже у одного фильтра может быть несколько подмен, если разрешить несколько внешних действий при обработке делать.

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

Да я даже до сих пор не понял, почему при одном переключении на другую стадию обращения к превьюшкам по несколько раз происходят. То ли это просто неоптимальное дублирование от повторной обработки каких-то GUI-событий, то ли там где-то параллельно какие-то другие данные меняются, которые я еще не обнюхал как следует.

Короче, либо я тут сильно застрял, либо сильно затупил 😄 .

@zvezdochiot
Copy link
Member Author

@noobie-iv .

Посмотри ветку plus. В ней как раз решалась "проблема" с превьюшками и фиксацией выполнено/невыполнено.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants