Balance

[zvezdochiot]

Hi @noobie-iv .

Я могу внедрить в STD фильтр Balance. Это позволит решить некоторые проблемы порогов в проекте путём префильтрации. Но с учётом того, что STD наследует глобальные настройки от STU с ГУИ и применением этого фильтра тебе разбираться самому. Как то так.

[noobie-iv]

@zvezdochiot

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

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

А глюки остаются. Например, картинки из тестового набора Page dewarping опять ломают эскизы - видимо, я там поворот где-то недоучел. Или стиль "ubuntu" под маками в темной теме полутемный выходит, видимо, там не все нужные цвета прописаны. Список разработчиков на эту ветку неправильный из-за автопереименований. Инсталлятор на маках почистить от мусорных заголовков надо. И хз, сколько там еще чинить осталось.

Еще есть ощущение, что гладкости сплайнов не хватает - у строк легкий изгиб мелкой волной заметен, тоже бы покрутить.

С автосборкой затык. Если она не позволяет получить рабочие релизные бинарники (например, как на macos-13) - то мне оно не надо. А если маки даже и соберу - так не проверю, рабочие они вышли или нет. Тут в команду маковод нужен. А лучше два - на разных процессорах. Виндовую версию я и так соберу. Могу еще какой-нибудь Ubuntu на виртуалке собрать и протестировать.

[zvezdochiot]

@noobie-iv say:

Разве что в отдельную ветку на после релиза

Не обязательно. Фильтр то я могу сокойно в https://github.com/ImageProcessing-ElectronicPublications/scantailor-deviant/blob/main/src/imageproc/ColorFilter.cpp кинуть. Это ни на что не повлияет. А в морду его подтаскивать и в этап "Вывод" я не стану. Там эти глобальные параметры, которые меня в запуп вводят. Я туда лезть не стану.

[noobie-iv]

@zvezdochiot

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

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

[zvezdochiot]

@noobie-iv say:

улучшает любой результат - то почему бы и нет.

"Улучшает" - дурацкий термин. Не имеет числового выражения. Достаточно спросить: "А сколько в граммах?" и сразу становится понятна тупизна данного термина.

Делает результат менее плохим? Да. В отношении качества контуров безусловно. Но! Всегда две стороны у "медали". Отрисовку контуров фильтр делает менее плохой, но более "грязной". И ежели зашить под капот без регулировки, то радиус ещё можно, а вот коэффициент крайне индивидуален к материалу.

С учётом целевого материала - фотосканы, полагаться на систему зашитого автоматического выравнивания освещения? Слишком наивно. Даже в STEX я счёл эту систему ненадёжной и заменил на систему регулируемого управления цветом. И она показала своё превосходство даже на целевом материале STEX. А уж на фотосканах и подавно. См. также:

• GIMP: «Сложный» порог
• GIMP: префильтрация перед порогом
• GIMP: пороговые карты и их применение
• DWG.RU: Ваши сканы, наша обработка и перевод в DJVU. # 3819