300dpi jest takim minimum do OCR, wg mnie też lepiej się czyta.

Przeważnie skanuję pisma urzędowe do OCR (robię OCR też ze zdjęć), z czasopism pojedyncze strony również na potrzeby OCR.

"Warsztat" jest dość prosty - skanuję bez żadnych "ulepszeń" w opcjach, podkładając czarny arkusz pod każdą skanowaną kartkę (oprócz dostatecznie grubych i jednostronnie zadrukowanych). Na potrzeby OCR zdjęcia z grubsza prostuję i czyszczę (usuwam zabrudzenia, ramki, ilustracje itp.) w darmowym PhotoFiltre [wersji 6 używam też do przeskalowywania obrazków do celów Atari - bo można wyłączyć optymalizację, czyli np. można wyciągnąć fonty z przeskalowanego obrazka - co niedawno zrobiłem i może udostępnię, ale liczba pomysłów przekracza dostępność czasu...].

Pomocne przy OCR jest też wykonanie kilku różnych skanów lub w przypadku braku tej możliwości (np. gdy mam jeden skan / zdjęcie z zewnątrz) przeskalowanie obrazu. Na ogół - jak bym to nazwał - "słabe znaki" są rozpoznawane inaczej, dzięki czemu porównując pliki wynikowe łatwo znaleźć błędy - pliki porównuję przy pomocy "Compare It!", na koniec usuwam formatowanie i przepuszczam przez słownik w Open Office.

Do OCR używam Tesseract-OCR, czyli tego co Ty (kiedyś używałem programu dodanego do skanera, jednak większość fontów wymagała pracochłonnego "uczenia"). Nie wiem jednak jak wytworzyć pliki pdf z OCR i jak je edytować? Ja przed OCR dzielę plik na pojedyncze kolumny i potem składam poszczególne fragmenty w całość. Czasami nic nie pomaga i niestety tekst muszę przepisać ręcznie. Także zależy od strony, ale zajmuje to nawet do kilku godzin. Programy przeważnie są słabo rozpoznawane i wymagają korekty, ale również każdy inny tekst sprawdzam linia po linii z oryginałem.

Ostatnio skanowałem okładki, ulotki. Może za jakiś czas zeskanuję jakieś czasopisma - nie daje mi spokoju stolik, z wnęką po szufladzie, w której są jakieś stare tygodniki, ale póki co nie mogę się tam dostać, bo stół stoi tą wnęką do drzwi, które od lat są zamknięte, a żeby go odsunąć z drugiej strony nie ma teraz miejsca... Także może jak odkopię tę "szuflandię" to coś z czasopism zeskanuję.

Myślę, że byłoby dobrze, żeby już w nazwie było zaznaczone, że nie jest to całość, np przez dopisek [fragment] lub np. [wybrane strony].

Co do ankiety, to nie czytam wszystkiego, od deski do deski, ale ściągam i przeglądam wszystko, a jak mnie coś zainteresuję to czytam całość. Także im więcej tym lepiej, ale też tym trudniej przeczytać, za to jest w czym wybierać i jest to też istotne z punktu widzenia archiwizacji :).

Edit: Podpowiedź: Na niektórych skanach widać przebitki z drugiej strony. Spróbuj pod skanowaną stronę podłożyć czarny arkusz. Arkusz A1 kupisz w sklepie dla plastyków. Ewentualnie w punkcie ksero, a jak nie to może zadrukują stronę na czarno. Duży arkusz służy mi jako tło do zdjęć, do skanowania A4 z ksero. Nie miałem z tym problemu, ale pamiętam, że na PW wisiał czarny arkusz z podpisem "Ta kopia kosztuje 8zł", za co obecnie można kupić dwa czarne arkusze A1.

W archiwum: https://archiwum.allegro.pl/listing?str … 20tygodnik (jest też magazyn Razem)
Konkretnie tu: https://archiwum.allegro.pl/oferta/raze … 70487.html (stopka na tym samym zdjęciu).

Tak, zauważyłem, że niektóre są aby zapewnić ciągłość tekstu, ale jednak jest kilka na których nic związanego z komputerami nie zauważyłem, ani też nie wyglądają na kontynuacje, zrobię przegląd pod tym kontem, ale jak nawet coś więcej zeskanowałeś to niech już zostanie.

[OT: Taka ciekawostka: https://polona.pl/item/myslace-maszyny,MTI0NTMwOTYz/]

Kolejna powtórzona strona!? - w Razem nr 44 1986 i Razem 49 1986. W przypadku tego drugiego ja wybrałem stronę z Wszystko Gra Targi ("analogowa", ale może posłużyć za inspirację), a powtórzonej strony ze skanu wśród zdjęć nie było.

W pdf-ie 42 1985 jest dół plakatu :)

Przypadkiem znalazłem tutorial jak odczytywać liczniki: http://hamspirit.pl/SQ9MDD/?p=2055

Jak pisałem młodzi robią porządki z natłokiem obrazków, a tu to pierwszy przypadek i odwrotnie burza że ktoś zauważa, że to niekoniecznie dobry kierunek.

Sądzę, że natłok obrazków nie przyciągniecie młodych (jeżeli taki ma być cel?), a raczej odwrotnie - strona przestanie być traktowana poważnie...

[Szkoda, że obrazki na temat są niewidoczne.]

Nie chodzi o to czy śmieszą czy żenują czy się podobają czy nie, jak dla mnie np. obrazek z Totoro jest całkiem fajny, lubię filmy z DiCaprio, ale nie widzę uzasadnienia / potrzeby, żeby takie obrazki umieszczać w treści ich niedotyczącej. Nie wiem czy kogoś rozśmieszają obrazki, które są na temat, mnie cieszą z pewnością w odróżnieniu od tych na które tylko zerknę i które *przewijam*.

Pewnie, że każdy może *wszędzie* wstawiać obrazki np. kotów, psów, śniadania, obiadu, kolacji, ze spaceru, zdjęcia mniej lub więcej znanych osób, roślin, miejsc, klatek z filmów, a gdy już będzie tego pełno w każdym temacie, ba w każdym miejscu, czy też będziecie tego bronić, w ramach walki z kijem w d*.*e?

Co do zastępowania treści obrazkami, to akurat w tym przypadku zupełnie nietrafiona uwaga. Jednak ta uwaga pokazuje to, że widząc takie obrazki traktujemy tekst niepoważnie i z góry zakładamy, że jest o "d*.*e Maryny". W mało której poważniejszej książce są tego typu obrazki, ale nawet jak są to nie ma ich aż tyle, a już zupełnie nie ma ich w pismach urzędowych, ani innych oficjalnych.

Dla mnie jest też istotne, że wykorzystuje to transfer, za który płacę, więc jest to też kwestia szanowania cudzego portfela. Może w tej chwili to się wydawać *śmieszne*, bo *jednorazowy* koszt jest niewielki, ale już mnożąc przez liczbę wejść i liczbę animacji (których jeżeli nie ograniczymy będzie coraz więcej) może być dużo większy niż się wydaje, a na pewno jest zbędny, nawet jeżeli jest to obecnie promil w tym co zużywamy celowo.

Powiecie, że wszędzie mamy pełno grafik, filmików, reklam i innych niechcianych treści, ale jednak skoro jest tego aż tyle, a tu nie jest konieczne, to może lepiej z tego typu grafik zrezygnować? Jeżeli wklejający uważa, że jest to absolutnie niezbędne to trudno, może jednak nie ma to dla niego aż tak dużego znaczenia i zaoszczędzi nam wszystkim przewijania, a ta cała dyskusja okaże się zbędna.

Tak jak pisałem ze skanów stron magazynu Razem udostępnionych przez uicr0Bee przepisałem (z mizerną w tym przypadku pomocą OCR-a) 2 listingi, które tam znalazłem: Trzy Kostki i Kalendarz. Zrobiłem też niezbędne poprawki - szczegóły w tamtym wątku. Opis po zsynchronizowaniu plików z OCR wyszedł zupełnie bezbłędny!

Przy okazji odszukałem oryginalny program Calendar, który wraz z wieloma innymi dostępny jest tu:
http://www.atarimania.com/documents/gam … _atari.pdf
Niestety nie odnalazłem odpowiednika Trzech Kostek.

Do małej optymalizacji (do samodzielnego zaaplikowania) wykorzystałem sposób użycia POKE / PEEK zamiast / z RESTORE z tej książki:
https://www.retrocomputers.gr/media/kun … i_text.pdf

Program Trzy Kostki nieco odchudziłem, ale, że jeszcze trochę można zrobić, nie udostępniam tej wersji (może później tu dodam).

PS. Tak się złożyło, że sam kiedyś pisałem kalendarz, a niedawno program z obracaną kostką. Poprawiałem też już inne tego typu programy :)

Edit: W 3-ech Kostkach znalazłem błąd - gdy na pytanie "na jaką liczbę stawiasz?" odpowiedzią będzie liczba powyżej 6, bądź litera (nie P i nie wyraz POMOCY), to stan konta zmniejszy się o podaną krok wcześniej stawkę, można w ten sposób doprowadzić do ujemnego stanu konta (kilkukrotnie wpisując błędną wartość np. literę), jeżeli później podamy literę P to po wyświetleniu pomocy zobaczymy ujemny stan konta, bez możliwości dalszej gry, a jeżeli wpiszemy wartość oczek to niespodziewanie zakończymy grę z zerem na koncie. Kolejny błąd tym razem nie krytyczny - ilość oczek możemy podać ujemną (0 szans na wygraną).

poprawka (do zaaplikowania we własnym zakresie):

410 REM 
440 IF LI<1 OR LI>6 THEN 360
450 TRAP 34567:CS=CS-ST

Przy okazji zmieniłem "THEN 370" na "THEN 360", tak aby nie tylko przy błędzie, a również przy niewłaściwej wartości wyświetlić ponownie pytanie. Linię 410 można usunąć, choć żeby nie było wątpliwości lepiej zostawić z REM.

Edit2: W linii 1150 jest literówka "MACISNIJ", oczywiście powinno być "NACISNIJ", sorry.

Artykuł o historii teletekstu, w pierwszym numerze magazynu PIXEL Addict:

Rozmyty, ale da się odczytać.

Magazyn można nabyć tutaj: http://pixel.addict.media/

Okładka kolejnego numeru:

Zawiera artykuły o klasycznych komputerach i grach, w tym o dużym Atari.

Niektóre strony z dostępnych numerów można podejrzeć pod linkiem na stronie magazynu.

Ja używam SFK partcopy - jest wersja pod Windowsa, Linuxa (nie tylko PC) i na Mac-a.

@Mono, no nie da się... (chyba, nie wiem na ile jest to sprzętowe, a na ile programowe). Żaden tryb nie ma 3 bitowego koloru i podejrzewam, że LOCATE, itd. nie są do tego przystosowane (musiałyby czytać / zapisywać co trzecią wartość operując na dwóch Bajtach), a do tego jak wybrać tryb graficzny nie ustawiając go?!

W załączniku kolejna wersja, tym razem dopisałem konwersję oct (w obydwu kierunkach). Tak jak pisałem, aby to zrobić trzeba było trochę pokombinować. Nie było łatwo, liczenie położenia Bajtów, bitów i do tego miałem problem z ADR, adresy zmiennych czasami zmieniały się, chyba przy zmianie GRAPHICS, jednak gdy dopisałem powrót do trybu GR.8+32 problem zniknął. Na wszelki wypadek dodałem if-a na końcu, który sprawdza, czy adresy się nie zmieniły... Dla wygodniejszego testowania dodałem opcję random.

Ponieważ oct jest 3 bitowy na 8 bitach maksymalnie da się zapisać wartość 377 (FF w hex), co daje 2bity+3bity+3bity.
Czyli, żeby odczytać/zapisać wszystkie trzy cyfry trzeba rozdzielić Bajt na 3. Zrobiłem to tak, że odczytuję 2 bitową wartość w GR.15, następnie kopiuję cały Bajt do przetwarzania w nowe miejsce i w GR.8 przemieszczam trzy bity środkowej wartości (w lewo przy odczycie) i czyszczę dwa pozostałe bity (piksele).
33222111 -> 02220111 (wartości dla zobrazowania grup bitów, zera - skasowane bity po przesunięciu grupy oznaczonej 222)
Po takim przemieszczeniu mogę odczytać w GR.9 dwie połówki Bajtu, które podobnie jak przy hex, zawierają dwie w tym przypadku cyfry z przedziału 0-7 (0000-0111 binarnie).
Całą operację powtarzam w pętli dla każdej wartości - danych wejściowych i wyników działań logicznych.
Na koniec wyświetlam wszystko w oknie tekstowym GR.8 - zrzut okienka tekstowego w załączniku.
Ponieważ wartości oct dla danych wejściowych już się nie zmieściły, znajdują się pod nimi po prawej stronie ekranu.

Dla zapisu na początku dopisuję zera (gdy podany ciąg jest krótszy niż 3 cyfry), bity przesuwam w drugą stronę niż przy odczycie. Podobnie zmieniając tryby składam całość.

Przy tych operacjach ekran sporo miga, co być może wydłuża przeliczanie, można spróbować na ten czas wyłączyć ekran. Można też zrealizować to nieco inaczej - kopiując bity dla poszczególnych cyfr na nowe Bajty i odczytać je w GR.8 (bez zmiany trybów). Można sobie przy tym pomóc mnożeniem przez 0.5 czy 2 itd. lub przenosić bity przy pomocy LOCATE, PLOT, lub PRINT #6; (gdy odczytamy je do zmiennej).

No i kolejna wersja z konwersją i wyświetlaniem danych/wyników również w hex (w sumie niewielkie zmiany do poprzedniej wersji). Zająłem się pisaniem i nie widziałem, że coś napisaliście po Blukim (fajne uproszczenie poprzez wrzucenie wag do danych). Teraz zerkam i ukrycie linii jak pisałem zrobiłem pod oknem tekstowym, ale wychodzi przy zmianie GRAPHICS. Później doczytam jak to jest u was... Tu wyniki są wyświetlane w kolejności tak jak mamy wybór: bin, hex, dec (pytanie jest jednocześnie opisem). W pierwszej kolumnie wyniki, w drugiej dane wejściowe.

100 DIM S$(1),H1$(2),H2$(2),HA$(2),HO$(2),HX$(2),A$(8),B$(8),OA$(8),OO$(8),OX$(8)
105 GRAPHICS 8:E=PEEK(88)+256*PEEK(89):AD=ADR(A$):YS=191:E=E+40*YS
110 ? "(B)IN, (H)EX, DEC ";:INPUT S$:ON (S$="B")*1+(S$="H")*2 GOTO 125,135
115 TRAP 115:? "0-255 (A) ";:INPUT IA:POKE E,IA
120 TRAP 120:? "0-255 (B) ";:INPUT IB:POKE E+1,IB:TRAP 0:GOTO 155
125 ? "0-11111111 (A) ";:INPUT A$:POKE E,0:POSITION 8-LEN(A$),YS:? #6;A$
130 ? "0-11111111 (B) ";:INPUT B$:POKE E+1,0:POSITION 8+8-LEN(B$),YS:? #6;B$:GOTO 155
135 ? "0-FF (A) ";:INPUT H1$:? "0-FF (B) ";:INPUT H2$
140 FOR X=7 TO 10:A=AD-X:B=PEEK(A):IF B>64 AND B<71 THEN POKE A,B-7
145 NEXT X:GRAPHICS 9+32:POKE E,0:POSITION 2-LEN(H1$),YS:? #6;H1$
150 POKE E+1,0:POSITION 2+2-LEN(H2$),YS:? #6;H2$:GRAPHICS 8+32
155 IA=PEEK(E):IB=PEEK(E+1):A$(8)="#":B$=A$:OA$=A$:OO$=A$:OX$=A$:H1$(2)="#":H2$=H1$:HA$=H1$:HO$=H1$:HX$=H1$
160 FOR X=0 TO 7
170 LOCATE X,YS,A:POKE AD+X,A+48:LOCATE X+8,YS,B:POKE AD+X+8,B+48
180 OA=A AND B:POKE AD+X+16,OA+48:REM COLOR OA:PLOT X+16,YS
190 OO=A OR B:POKE AD+X+24,OO+48:REM COLOR OO:PLOT X+24,YS
200 OX=OO AND  NOT OA:POKE AD+X+32,OX+48:REM COLOR OX:PLOT X+32,YS
210 NEXT X:POSITION 0+16,YS:? #6;OA$;OO$;OX$
215 GRAPHICS 9+32:FOR X=0 TO 9:LOCATE X,YS,A:POKE AD-10+X,A+48+(A>9)*7:NEXT X:GRAPHICS 8+32:? CHR$(125);
220 OA=PEEK(E+2):? "AND:";OA$;" ";HA$;" ";OA;CHR$(127);A$;" ";H1$;" ";IA
230 OO=PEEK(E+3):? "OR: ";OO$;" ";HO$;" ";OO;CHR$(127);B$;" ";H2$;" ";IB
240 OX=PEEK(E+4):? "XOR:";OX$;" ";HX$;" ";OX
250 GOTO 110

Edit: Forum zamienia duże "B" w nawiasie kwadratowym występujące w kodzie na małe "b", podobnie z "H"->"h", więc zmieniam nawias na okrągły - linia 110.

Edit2: Ukrywania danych za oknem tekstowym użyłem w mojej wersji Computer Inhabitant - tam w tym obszarze ukryte są dane animacji przedmiotów i elementów domu ;) Więc tu mi to od razu przyszło do głowy. Wybrałem linię 191, bo jest to ostatnia lina ekranu, gdzie bardziej prawdopodobne, że nic tam nie umieścimy, jeszcze lepiej byłoby przenieść dane na koniec tej linii. Można też przed konwersją zrobić backup tego co tam się znajduje, a po skończonym 'liczeniu' przywrócić.

Do DL pochodzę jak do jeża, ale być może ostatnią lub inną wybraną linię da się ukryć. Jeden minus, że pewnie trzeba będzie użyć kilku instrukcji assemblera, których unikamy w tej metodzie.

@Mono nie rozumiem, dlaczego najpierw robisz POKE, a na końcu po ustawieniu koloru, PEEK? OK, chyba rozumiem, to taki niepełny przykład abstrakcja - brakuje PLOTa :)
EXOR pierwotnie zrobiłem wg wzoru z Wikipedii, czy czegoś podobnego, jednak wydawał mi się zbyt długi i poszukałem krótszego :)
@Maw a czy próbowałeś zmienić GRAPHICS na NR+32, to znaczy z zachowaniem zawartości ekranu? Ja użyłem tego powyżej wraz z Twoim sposobem konwersji - do konwersji hex - zmiana na GR.9+32 4 bity na pixel, i z powrotem na GR.8+32 1 bit na pixel.

Edit3: Zastanawia mnie czy można użyć #6 do czegoś innego niż PRINT? Wpisanie INPUT #6,A$ powoduje dłuższe jakby zawieszenie i ERROR - 141? Czyżby dało się w ten sposób odczytać ciąg Bajtów? Spróbuję umieścić bajt 155 na ekranie i zobaczyć czy uda się odczytać kilka Bajtów... Gdyby to działało można by w ten sposób odczytać kilka zmiennych jednocześnie... i np. przekopiować dane...

Edit4: Działa GR. 8 i POS.X,Y:PUT#6,1-A:POS.X,Y:GET#6,A:?A;
PUT i GET zapala/gasi i odczytuje bit (piksel). W GR.8 nie ma chyba możliwości aby INPUT #6,A$ odczytało koniec linii?

Edit5: Wygląda na to, że INPUT #6,A$ czyta dane z całego ekranu od miejsca wskazanego przez POS.X,Y. Tylko jak ten odczyt zakończyć? Może gdyby ustawić TRAP i wtedy... no właśnie co? Niestety zmienna A$ pozostaje niezmieniona (obecne dane pozostają bez zmian). Nieważne też jak długa jest ta zmienna odczyt i tak dochodzi do końca ekranu.