search

ImageProcessing-ElectronicPublications / scantailor-experimental

Scan Tailor Experimental is an interactive post-processing tool for scanned pages.
https://github.com/Tulon/scantailor/tree/experimental
GNU General Public License v3.0
30 stars 0 forks source link

Feature: Margins & Resolution? #6

Closed zvezdochiot closed 8 months ago

zvezdochiot commented 9 months ago

Hi @noobie-iv .

There is a need to move "Resolution" to "Margins".

stex-margins_and_resolution

This will allow you not only to set the scale for each page separately, but also (taking into account all the necessary changes) to use a single margin scale value for all pages.

noobie-iv commented 9 months ago

Maybe just add "Apply to..." button, like in other options and in other ST versions?

zvezdochiot commented 9 months ago

Привет @noobie-iv .

Суть не в кнопках. Суть в том, чтобы завести масштабный фактор в опции Page Layout и черпать его от туда. И что то надо сделать с итератором Page Layout, чтобы он выдавал максимальную область контента без полей. Именно без полей! Тогда этот размер можно будет пользовать как масштабный фактор для Margins всех страниц. То есть поля наконец станут одинаковыми.

noobie-iv commented 9 months ago

Для меня суть в объеме работы. Скопипастить кнопку "применить" - одно, переделывать логику - другое. Потом еще выяснится, что логика неудачная, и все надо взад вернуть. Я вот на починку сборки для STU уже неделю потратил, и только под вынь. А еще как минимум под линь надо поправить, про маки даже не заикаюсь. И это я еще даже не начал делать то, ради чего сюда вообще полез. Так что я просто сортирую задачи по объему, жирные улетают в конец списка, до которого могут и годы пройти.

zvezdochiot commented 9 months ago

@noobie-iv say:

А еще как минимум под линь надо поправить

Так под линь и STA и STU и STEX прекрасно собираются без всяких помощников. Не собирается исходный ST, так как Qt4 канул в "небытие". Как минимум так было до сих пор.

PS: Не в кнопках дело. Скопипастить с одного виджета в другой и я могу. Дело в конструкторах различных Options и методах доступа к их содержимому, а так же области их видимости. А итераторы - это вообще какая то плюсовая муть жуткая.

noobie-iv commented 9 months ago

@zvezdochiot

Так под линь и STA и STU и STEX прекрасно собираются без всяких помощников

В процессе починки вынь происходит поломка линь.

Под вынь в оригинале вообще ручная работа над каждым файлом. Каждая зависимость собрана вручную - перечислен каждый файлик исходника, и на каждое копирование своя самодельная команда. Там даже стандартный инсталлятор заблокирован (что дает лишнее сообщение об ошибке при сборке). Собственно, инсталлятор STU в исходном репозитории кривой, он не удаляет все, что поставил. Наверное, так было надо в древнем cmake, но теперь с этого одни проблемы.

Я эти ужасы снес, и сделал "по учебникам" с сайта cmake - все ставится через INSTALL, и пакуется через INCLUDE(CPack).

Хочешь просто программу:

Нужны исходники:

Нужны инсталляторы + портативка :

Такие команды уже можно в Actions запихать, и просто забрать автособранные артефакты.

Так же должно быть и под линь:

Но я даже зависимости в DEB не в курсе как правильно указать. Про мак вообще молчу. Если доделать сборку под линь - результат можно и в оригинал зареквестить. А если оставить как есть - то только для личного пользования.

zvezdochiot commented 9 months ago

@noobie-iv , ну ежели про зависимости готового, то можно в моих сборках deb-пакетов посмотреть:

Depends:
 libc6 (>= 2.31),
 libgcc-s1 (>= 10.2.1),
 libstdc++6 (>= 10.2.1),
 libjpeg62-turbo (>= 1:2.0.6),
 libpng16-16 (>= 1.6.37),
 libtiff5 (>= 4.2.0),
 libqt5core5a (>= 5.15.2),
 libqt5gui5 (>= 5.15.2),
 libqt5opengl5 (>= 5.15.2),
 libqt5widgets5 (>= 5.15.2),
 libqt5xml5 (>= 5.15.2),
 license-gpl

Но dev-зависимости "слегка" отличаются (libeigen3-dev появляется, например).

noobie-iv commented 9 months ago

Под линь сейчас DEB собирается отдельно каким-нибудь менеджером пакетов? В cmake-файлах же не настраиваются всякие libc6. А уж ">= 2.31" - это вообще подозрительно: как это библиотека с точностью до сотых 😄? Это, видимо, просто версии, которые стояли в системе на момент сборки? Тогда надо собирать программу на самой древней системе, которую удастся поставить, или собранное на старой на современных не запустится? И туда вписываются все зависимости, на которые ссылается программа (то, что показывает readelf)?

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

zvezdochiot commented 9 months ago

@noobie-iv say:

Под линь сейчас DEB собирается отдельно каким-нибудь менеджером пакетов?

Ну DEB - это ar упаковка (более простая, чем tar) двух tar-архивов:

Первый содержит информацию о пакете (включая Depends) и опционально скриты настойки, а вторая сами устанавливаемые в систему файлы.

Не знаю как кто чего, а я собираю пакеты с помощью собственных скриптов, использующих tar, gzip, lzma и ar: bash-deb-build.

plzombie commented 9 months ago

@noobie-iv

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

Ну по сути работает только в прямую сторону. Собираешь под Debian 11 - будет работать под Debian 11 и скорее всего дальше, если мажорную версию пакетов не дропнут (как было с Qt4 в Debian 11)

@zvezdochiot

Так под линь и STA и STU и STEX прекрасно собираются без всяких помощников. Не собирается исходный ST, так как Qt4 канул в "небытие". Как минимум так было до сих пор.

Ты в этом уверен? Просто в альтье например даже Qt3 есть. Есть, так сказать, потребители. А в debian 10 оставили Qt 4.

UPD: Дай ссылку на оригинальный ST, я попробую под альтом собрать

zvezdochiot commented 9 months ago

@plzombie , ST архив

plzombie commented 9 months ago

@zvezdochiot собралось, ставил libqt4, libqt4-devel. Кроме того, что уже ставил для STE. изображение

noobie-iv commented 9 months ago

Собираешь под Debian 11

Например, у гитхаба в Actions предоставляется на выбор Ubuntu 20 / 22. Если автоматизировать сборку, более ранние системы будут недоступны. Это очень важно, или более старые уже не в ходу? Если в ходу, то не надо и на автоматизацию рассчитывать, а собирать в образах на виртуалке?

Я не линуксоид, и не в курсе, как принято. Есть какая-то система, на которой надо собирать, чтобы подошло всем, или на каждую собирают отдельно? Например, у меня, STEX не собирается на Ubuntu 18 из-за старого cmake. Там надо проект под cmake переделывать, или считать, что желающий его обновить может?

zvezdochiot commented 9 months ago

@noobie-iv , совершенно верно. У каждого дистрибъютива своя команда мантайнеров (сборщиков). И каждая команда собирает дистрибъютив из отдельных пакетов. Для этой команды важно только, чтобы внутри данного дистрибъютива всё конектило, а до всех остальных им дела нет и быть не может.

noobie-iv commented 9 months ago

Тогда в малоизвестных проектах, которые не включены в дистрибутивы, в релизах должны лежать сборки под все основные системы?

zvezdochiot commented 9 months ago

@noobie-iv , это ненужно. Для линя достаточно одного исходного кода и одной сборки (любой), показывающей, что пакет собирается. Бинарные сборки - это для быстроты развёртывания/обновления. Соответственно делаются только на самые потребные пакеты.

PS: Для 18-ой бунты попрбуй в CMakeLists.txt убавить требуемую версию до имеющейся. Глядишь соберётся. https://github.com/ImageProcessing-ElectronicPublications/scantailor-experimental/blob/8df725554459d8322e13af22d1f946b107b46446/CMakeLists.txt#L1

noobie-iv commented 9 months ago

$cmake --version make version 3.10.2

CMake Error at CMakeLists.txt:276 (INSTALL):
  INSTALL TARGETS given target "scantailor-experimental" which does not exist
  in this directory.
CMake Error at cmake/UpdateTranslations.cmake:46 (LIST):
  LIST sub-command REMOVE_DUPLICATES requires list to be present.
Call Stack (most recent call first):
  CMakeLists.txt:314 (FINALIZE_TRANSLATION_SET)

Видимо, там какие-то новые фишки использованы. Если обновить сам cmake, глюк пропадает и сборка проходит.

Конкретно это неважно, я не буду разбираться что не работает. STU на U18 собирается без ошибок. U18 - потому что это минимум, который был указан в действиях гитхаба, и потому, что у него образ самый маленький. Сейчас смотрю, уже минимум заявлен U20.

Вопрос только в том, не надо ли в принципе исходники тестить на каком-нибудь старом образе, чтобы у тех, кто качает не готовую сборку, не возникало проблем.

zvezdochiot commented 9 months ago

@noobie-iv , вообще то всё наоборот. Работает это так. Старые релизы всегда остаются, надо тебе под старую ось - пожалуйста. А новые релизы тестятся на как можно более новых осях, например STA тестится на чем-то-там с Qt6. Чтобы новые версии точно взлетали на новых осях. Такая вот система.

zvezdochiot commented 9 months ago

@noobie-iv . Чем больше смотрю, тем больше понимаю, что для ваших целей необходим отдельный шаг между 5.Margins и 6.Output => 6.Zones (+ 7.Output), со своими объектами Options/Params и ImageView. Это позволит свести все типы зон в один ComboBox, а их параметры в скрытые/появяющиеся при выборе виджеты. Такие вот дела.

noobie-iv commented 9 months ago

@zvezdochiot

все типы зон в один ComboBox

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

На руборде в начале темы автор прям обижался на предложение добавить галочку-другую, говорил "это вам не SK, тут не больше 10 кнопок в одни руки". А у меня представляется уже какая-то система действий, по типу модификаторов в 3dmax. Это уже не skantailor-universal какой-то, а scantailor-deviant.

zvezdochiot commented 9 months ago

@noobie-iv , ну как нет. Пока два типа: PictureZone и FillZone: https://github.com/ImageProcessing-ElectronicPublications/scantailor-experimental/blob/7d8a4f520a24af704e88a70bdcf265313e01f1d6/src/filters/output/OutputGenerator.cpp#L542 https://github.com/ImageProcessing-ElectronicPublications/scantailor-experimental/blob/7d8a4f520a24af704e88a70bdcf265313e01f1d6/src/filters/output/OutputGenerator.cpp#L556

Для ваших целей явно понадобятся ещё типы FilterZone и, возможно отдельно, LowcolorZone.

Смысл в том, что сейчас работать с зонами неудобно. Вы так сами сказали ранее. А я это подтверждаю.

noobie-iv commented 9 months ago

С точки зрения пользователя, Picture и Fill - это действия внутри зоны. Есть еще действия AutoImage, Blur, DPI, Binarization, и т.п. Сейчас набор действий прибит гвоздями к зоне, потому у нее и "тип" есть. А надо дать этот набор настраивать, тогда и тип отпадет. Сейчас одни действия бывают лишними (максимум - в ноль скрутишь), а бывает, что и не хватает какого. Эскизно пока что-то такое представляется: Zones

zvezdochiot commented 9 months ago

@noobie-iv say:

Эскизно пока что-то такое представляется:

Это сложно. Я даже не представляю, как это всё в XML представить, не то что выполнить, как прописано.

noobie-iv commented 9 months ago

Так ведь XML не ручками пишется, его designer рисует. QT Книжка по Qt - Бланшет, Саммерфилд. Qt 4. Программирование GUI на C++.

zvezdochiot commented 9 months ago

@noobie-iv , так я ж не про интерфейс, а про проекты ST. Их то прописывать уже нам приходится. Сейчас запись/парсинг простые, но то, что вы предлагаете, я даже визуально как то сообразить не могу.

zvezdochiot commented 8 months ago

Не актуально.