Не могу воспроизвести. Сбросьте файл проекта. Или запостите его текст на https://pastebin.com/ - я скопирую. Может так получится.

Не, не выходит. Давайте проект.

Получилось воспроизвести белый лист при 35мм и несохраненном проекте. Правда только на Windows. Будем смотреть.

Залил в облако 64х битую версию с поддержкой 64-х битного WinXP.

1.
xyz писал(а) 03.10.2017 :: 14:46:15:


Попробуйте это воспроизвести на 64 битах.
С моей т.з. все опять из-за нехватки памяти. Скан был в 600dpi, ему задали 300. Получился 4-х кратный перерасход памяти, да еще выводят в output в 600 dpi. Потребление RAM очень близко к границе в 2Гб, выдаваемых Win 32-х битным приложениям. Настолько, что если на этапе ориентации не поворачивать скан, то он пойдет одним куском, а не 2 страницами, и тут же обрушит приложение на этапе output. Или если с 2 страницами на этапе output зайти в закладку despeckle одной из страниц - он рухнет из-за нехватки памяти.

Где-то я видел пожелания по выводу реального размера в окне fix dpi, но не могу найти.

2.
Я все это время ловил другой баг - то что всплывало под названием "ST не подгружает результаты из кеша при повторном открытии проекта". Выяснилось, что это свойственно страницам с alignment = original. Раньше он, по-моему, дефолтным стоял. Детали описал тут. Я эту проблему исправил, должно работать.

3.
На досуге я взглянул в pull request'ы, висящие в основном проекте ST. Это фичи, которые предлагаются сторонними разработчиками в ST, но, ни в него, ни в один из форков, не вошли. Есть интересные, но интегрировать их по-быстрому не получается.

Дернул одну ради эксперимента - она есть в этом 64-х битном дистрибутиве и в ветке dev.
Под настройкой Tiff compression будет флаг "Use horizontal differencing predictor". По умолчанию он выключен.

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

В общем, для LZW и Deflate он дает сжатие файлов в папке out до 50% (чтобы перегенерировать, папочку out нужно сначала удалить/перенести). На остальных методах сжатия эффекта не видно.

Я оставил его выключенным, и вообще отношусь к нему как к эксперименту, т.к. сам результаты из out/ не храню. Я храню оригинальные сканы и файл проекта scantailor'а, чтобы при необходимости получить результаты снова. Так что, лично мне никакой пользы от этого сжатия нет, а какое-никакое замедление в процесс сохранения результата в tiff файл этот предиктор давать должен.

Что скажете, оставить отключенным или вообще убрать из настроек в ini файл?

4. Еще я посмотрел в исходники libTiff 4.0.8 и удалил в настройках STU все методы сжатия tiff, которые в этой библиотеке не реализованы. И объединил методы, по факту оказавшиеся синонимами или имеющими эквивалентную реализацию в libtiff.

Цитата:


Это стадия №5 Поля   (у меня в STU она так называется).
Причем на самом деле этот баг с указанием того, что он важный, мной уже репортился.

Почувствовал, что разработка и тестирование начали вырываться из под контроля - составил табличку по багам и хотелкам из этой ветки:


pdf:  https://yadi.sk/d/ifi_05Br3NX7PT

doc:  https://yadi.sk/i/Hn2gw2c93NX7dY

табличка составлена полностью (из ветки взято всё), но я пока не успел перепроверить, воспроизводство всех "багов".  Что воспроизвел или посчитал важным - пометил красным шрифтом.

Этот баг там сидит за №74 и №124.

Также хотел дополнить эту табличку тем, что сидит в issues вашего форка на гитхабе.
Мы тут уже наплодили больше, чем куча народа за много лет на каждом из форумов.
Надо бы в табличке сделать сортировку  "приоритетные - второстепенные - дискуссионные".



Цитата:


Так и на мой взгляд тоже ! А за счет чего ещё ? Вопрос в том, как СТ себя в этот момент ведёт.
Выпадает/не выпадает. Сохраняет результаты. Даёт предупреждения. В какой момент даёт.
Но ничего не делать и только белое поле демонстрировать - ИМХО неправильно.


Цитата:


Да, я посмотрев на ваши issues, также решил поковыряться в issues  оригинального Скантейлора  (176 открытых и 72 закрытых + 18 пуллреквестов). Работу пока не закончил.
Бестолковые они какие-то.  Часть с форумов просто уперто.  Часть в STU уже реализовано.
Особо прикололо как они закрывали неплохие предложения с формулировкой "out of scope".
Около трёх десятков идей, впрочем, наковыривается. Но это далеко не сотня, как с каждого из форумов.

Цитата:


Я не догнал, что пуллы - это уже готовый код. А так я даже не стал это предложение включать в список  оттуда имеющих хоть какой-то смысл из этих же соображений. Либо это какое-то нестандартное сжатие - и тогда зачем ? Что с ним потом делать, кто его поймёт ? Либо это замедление работы.

Цитата:

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

Цитата:

Эта версия не выпадает. (На Win 7, на мою ХР она не ставится.)

Цитата:

Если это стандартные тиффы, то оставьте. Места иногда начинает резко не хватать. (1000 стр словарь, 600 дпи сканы - 100 гигов. 8 версий/этапов обработки - вот уже, считай, и полдиска. А в словаре три тома ...).   Пригодится.

БАГ:
Вспомнил/прочитал, что ST не открывает тиффы с внутренним джипег-сжатием. Я почему-то считал, что это давным-давно поправили.
Подтверждаю. STU тоже не открывает. 
https://github.com/scantailor/scantailor/issues/141

1.
Обнаружил, что ScanTailor Enhanced   джипег в тиффах (пример из issues) открывал.

Одновременно сегодня мне новый библиотечный сканер выдал нечто новенькое, про что кромсатор говорит не просто Tiff jpeg,  а  Tiff jpeg v.5.  Этот файл STE уже не берётся, а некоторые просмотрщики открывают в неправильных цветах. XnView нормально открывает и конвертирует.

https://yadi.sk/d/wSdSuOXV3NZK9g

Ирфан, кстати,  про первый (из issues) говорит что он "JPEG (in TIFF)", а про вот этот новый "Old-style JPEG (in TIFF)".


2.
Файлы этот сканер поименовал вот так. 
Почему-то внутри STU файлы с такими именами сортируются не по порядку  (встроенная умная сортировка лажает). Возможно, нужна опция "сортировать по имени".

xyz писал(а) 06.10.2017 :: 13:36:07:

U menja ochenj-ochenj bolshaja k Vam prosjba: pozhalujsta, peremestite sje eto (i predyduschie sborniki tozhe) na GitHub. Eto ochenj pomozhet. Zaranee gromadnoe spasibo.

Зачем вам джепег в тифаках? Пусть кто их делает, тот и мудохается.

Цитата:


Вы наверное невнимательно прочитали. Сканеры их делают библиотечные.
У меня один источник таких - РГБ, другой - институтская библиотека.

Но я согласен, что это не самый приоритетный пункт в планах.

xyz писал(а) 08.10.2017 :: 10:17:05:

Vy mozhete eti pervye 20 pozitsij (so vsekh kontsov Interneta) sobratj v odin dokument i vylozhitj zdesj? Togda ja razmeschu ikh na Github s sootvetstvujuschej pometkoj.

В общем, 64 битную версию я обновил в облаке.

1. Вручную указаны кодеки, которые обязаны быть в libTiff.dll для Win. Выбрал все, кроме 2х- LZMA и JBig. Так что теперь на Win должно пддерживаться все, что умеет libtiff, кроме "LZMA2" и "ISO JBIG".
Ваш файл открывается. Он использует сжатие OJPEG.

Сборка libtiff с включенными LZMA и JBig требуют дополнительных сторонних библиотек (liblzma2 и что-то для jbig). Скрипты оригинального ST ничего подобного не предполагают. Я попробовал сходу прикрутить liblzma2 - и не вышло. Не смог пока собрать ее под моей конфигурацией Win.
Так что, пока будем считать отсутствие их поддержки known issues. Когда-нибудь я поборю это.

Линуксы эта проблема не касается.

2. Я сделал экспериментальную поддержку сохранения выделения при переключении между режимами.
"Экспериментальную" - потому-что такая поддержка в ST уже была. Но её в какой-то момент отключили. Видимо, она плохо работала с различными сортировками в разных режимах.
Я ее вернул. Поправил все всплывшие проблемы, которые смог найти. Но, не факт, что это все проблемы.

Из known issues - если вы выбрали отдельную страницу разворота, то вернувшись на этапы 1 или 2 - вам выделят весь разворот. Перейдя назад на этапы > 2, у вас будут выделены обе страницы этого разворота, а не одна. Потому что ST не запоминает с какой страницы разворота вы пришли. Т.е. если у вас выбрано 10 левых страниц, то перейдя на эап 1 или 2 и вернувшись у вас будут выбраны 10 левых и 10 правых страниц.
На мой взгляд, это логично. Исправить это будет непросто. Поэтому, я решил сначала спросить: а мешает ли такое поведение?

Цитата:


Джипеговые тиффы под вин7 теперь открываются оба типа.
Жалко, не могу проверить это под WinXP.


Цитата:

Теоретически, это мешать не должно. Ведь планируемый сценарий использования таков: неправильные зоны контента  - идём править разрезку страниц. При возврате на контент или поля эти страницы всё равно все будут подсвечены как необработанные, и кто там точно выделен уже не так важно.

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


Цитата:

Я подумал над тем, какие пункты из выложенных ранее "обзоров" отобрать в число 20 приоритетов. Как я уже отмечал, важные я старался собирать там везде в начале. У меня получился такой список:

Здравствуйте.

Давно использую ST Featured, но сильно не хватает двух опций:

1. Аналог "ластика" в Paint. Порой, чтобы удалить ненужный артефакт, требуется минимум три клика мышкой, а с ластиком достаточно было бы одного. Сильная экономия времени.

2. Аналог "карандаша" в том же Paint. В старых книгах порой буквы очень нечётки. Например "висит" отдельно хвостик буквы а. А с карандашом можно было бы быстро подрисовать соединение.

Можно ли добавить эти функции в ST?

Маркион писал(а) 08.10.2017 :: 21:40:34:


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

Принципиальной проблемой может быть то, что ST не редактирует изображение до самого последнего момента. По сути он пишет скрипт с описанием последовательности операций с изображением, и только в конце его применяет. А все что до того вы видите на экране - просто "предварительный просмотр" действий скрипта. Т.о. все ластики и черточки мне нужно будет хранить в виде векторов и полигонов в текстовом файле проекта. И на лету каждый раз применять. Можно быстро наплодить кучу элементов  и зон сложной формы. И чтобы их, скажем, редактировать или просто убирать потребуется уже рамка выделения и механизмы работы с группой выделенных полигонов.
С этим всем может быть куча проблем. Но, посмотрим.