Windows 10 i problem z RAM

[pawel764587k]

Mam w komputerze 8 GB RAM. Windows już po uruchomieniu komputera zajmuje ok. 35-40% RAM. Ale to jeszcze pół biedy. Gdy próbuję uruchomić skrypt Pythona wymagający ok. 2 GB RAM, to wywala błąd, że jest niewystarczająca ilość pamięci ("Insufiicient memory (case 4)"), mimo że ma do dyspozycji jeszcze ok. 5 GB wolnego RAM-u. Konkretnie jest to ten skrypt służący do zszywania dużych obrazów z setek lub tysięcy małych płytek umieszczonych na stronach internetowych w okienkach zoomify: sourceforge.net/projects/dezoomify/ . Z mniejszymi plikami pracuje dobrze.

Zwiększyłem plik wymiany nawet do 8 GB, ale nic to nie dało. Spróbowałem włączyć komputer w trybie awaryjnym i wtedy uruchomić skrypt (wówczas zużycie RAM przez Windows spadło do ok. 1 GB), ale nadal wywala ten sam komunikat błędu. Gdzieś wyczytałem, że 32-bitowe programy mają ograniczenia w wielkości plików właśnie do 2 GB. Zainstalowałem Pythona w wersji 64-bit, ale nadal bez rezultatów. Czy ktoś wie, jak rozwiązać ten problem?

[wariant_b]

A próbowałeś to zrobić na linuxie?
W razie powtórzenia się problemu jest więcej opisów, jak poradzić sobie z pamięcią.

[pawel764587k]

Myślałem też nad tym rozwiązaniem, ale jeszcze nie próbowałem. Nie mam zbyt dużego doświadczenia z linuxem.

Da się zainstalować Pythona w wersji live dowolnego linuxa?

[wariant_b]

Wersja "live" jak sama nazwa wskazuje jest ulotna - po wyłączeniu linuxa nic nie zostaje.

Potrzebujesz 64-bitowej i w miarę pełnej dystrybucji - Python zapewne w niej już będzie.
Jeśli pobierasz linuxy z distrowatch.com, sprawdź co dokładnie jest w dystrybucji.
Mogą być dodatkowe problemy wynikające z użytej wersji Pythona.

Jeśli jesteś w stanie wygospodarować dość wolnej pamięci w Windows możesz
spróbować podziałać na maszynie wirtualnej np. VirtualBoxie.

Może się mylę, ale w dezoomify jest program do obróbki zdjęć jpegtran.exe i być może
to on powoduje problem z pamięcią - jest dużo opisów problemów pamięciowych 2GB
w Windows 10 dla innych, podobnych programów np. popularnego ImageMagic.

[pawel764587k]

Chodziło mi o to, czy da się użyć Pythona w którejś wersji live linuxa. Oczywiście, że po wyłączeniu linuxa znika również Python.

Być może są jakieś linuxy, które już w podstawowej wersji live mają wbudowanego Pythona i niczego (poza skryptem) nie trzeba do nich dokładać.

Instalacja linuxa raczej odpada - musiałbym (chyba) znaleźć dla niego drugi dysk lub nową partycję, a z tym byłoby dużo problemu. Podobnie VirtualBox. Niektóre pliki mogą wymagać 5 GB RAM i więcej i wtedy może nie wystarczyć pamięci.

wariant_b napisał:

> Może się mylę, ale w dezoomify jest program do obróbki zdjęć jpegtran.exe i być
> może
> to on powoduje problem z pamięcią - jest dużo opisów problemów pamięciowych 2GB
> w Windows 10 dla innych, podobnych programów np. popularnego ImageMagic.

Tak, jest tam jpegtran.exe. O problemach z pamięcią w ImageMagic czytałem. Tam często polecanym rozwiązaniem jest zainstalowanie programu w wersji 64-bit. W przypadku Pythona u mnie to się nie sprawdziło. Nie wiem, czy istnieje wersja 64-bit dla jpegtran. Szukałem w internecie, ale nic nie znalazłem, więc używam wersji jpegtran dołączonej do skryptu przez autora.

[wariant_b]

pawel764587k napisał:

> Chodziło mi o to, czy da się użyć Pythona w którejś wersji live linuxa.
> Oczywiście, że po wyłączeniu linuxa znika również Python.

W tej chwili nie mam jak sprawdzić, ale wydaje mi się, że nie ma przeszkód. Python
jest w każdej pełnej dystrybucji, bo jest używany przez inne programy. Rozumiem,
że nie ma ograniczeń co do używanej przez ciebie wersji - w opisach widzę zwykle 3.9x.
Trzeba pobrać jakąś dystrybucję na pena i spróbować.

> Niektóre pliki mogą wymagać 5 GB RAM i więcej i wtedy może nie wystarczyć pamięci.

Może, bo jak sam piszesz system zajmuje sporo. Problem jest w tym, ile pamięci może
przydzielić system. W przypadku 32-bit programów Windows przydziela do 2GB, w linuxie
może być wykorzystane więcej, ale również mniej niż teoretyczne 4GB.

[pawel764587k]

Spróbuję pobawić się linuxem w weekend (mam gdzieś instalkę Xubuntu) i zobaczę, co z tego wyniknie. W wymaganiach skryptu dezoomify podana jest wersja 3 Pythona, więc na 3.9x też powinien działać.

Jeśli masz zainstalowanego Pythona i chciałbyś sprawdzić, jak jest u Ciebie, to można to zrobić np. na tej mapie: chartae-antiquae.cz/en/maps/29220

Trzeba pobrać skrypt, rozpakować i wrzucić zawartość katalogu do folderu Pythona. Następnie w wierszu poleceń wejść do Pythona i wpisać takie polecenie: python dezoomify.py -b ht tps://www.chartae-antiquae.cz/tiles/ntm/mapy/1440_400dpi/ImageProperties.xml obraz.jpg -v (w "https" trzeba usunąć spację).

Ogólnie to nie jest pracochłonna rzecz - wprawdzie zszycie całego obrazu może trwać dość długo (ok. 0,5-1 godz.), ale już po 1-2 minutach powinny pojawić się komunikaty (lub nie) o niewystarczającej ilości pamięci.

Dla mnie taki "eksperyment" byłby cenny, gdyż wiedziałbym, czy problem występuje tylko u mnie, czy jest bardziej ogólny, a Tobie może łatwiej byłoby zdiagnozować wtedy przyczynę problemu, działając na konkretnym przykładzie.

[wariant_b]

Nie znalazłem czasu, żeby spróbować linuxa live, bo komp miałem cały czas zajęty
więc wrzuciłem temat na wirtualkę (Virtualbox, 8 GB, 4 pingwiny) i mam obrazek.
Zajmuje ok. 123 MB, pobierał i składał się prawie 30 minut. A konkluzje takie:
- nie używaj Windows 10, bo to jego problemy z zarządzaniem pamięcią, a nie jej brak
- nie używaj Pythona 3.10.4 - powiedział, że skrypt ma błędy, więc nie pójdzie i tyle.
- natomiast Python 3.9.2 na linuxie przełknął skrypt bez problemów.

Najpierw zainstalowałem sobie aktualne Xubuntu 22.04 z Pythonem 3.10.4 - wyrzuciłem.
Potem spróbowałem o miesiąc starszego MX-21.1 z tym właściwym Pythonem.
Oprotestował mi certyfikaty, więc poszło http zamiast https - i dobrze.

Uruchomiony skrypt zajmuje powyżej 2GB, a sam jpegtran dochodził do 2.2 GB -
widać, dlaczego w Windows 10 była klapa z brakiem pamięci.
Tak naprawdę maszynie wirtualnej wystarczy 4GB pamięci (u mnie dochodziło do 3.2GB)
i jeden wirtualny procek, więc możesz ją sobie przygotować i używać w razie potrzeby.

[wariant_b]

Przy okazji - kilka lat temu problemy z pobieraniem map zgłaszała użytkowniczka malgorzata543.
Skojarzyło mi się to, ponieważ również dotyczył zasobów map archiwalnych na czeskich serwerach.

Może warto żebyś spróbował z jeszcze innym, specjalistycznym linuxem: OSGeoLive-14.0
Tu jest ich strona: live.osgeo.org/en/index.html

[pawel764587k]

Na razie próbuję coś zdziałać z Xubuntu.

W końcu udało mi się zrobić nośnik instalacyjny z Xubuntu (Windows 10 powgrywał mi na pendrajwa jakieś pliki w folderze "System Volume Information" i wczoraj przez kilka godzin męczyłem się, jak go usunąć). :-( Ma wbudowanego Pythona 3.6.

W jaki sposób teraz uruchomić skrypt w linuxie live? Wszystkie płytki potrzebne do sklejenia obrazu mam już pobrane na dysk, trzeba teraz tylko je połączyć. W skrypcie do tego służy polecenie: python dezoomify.py -b ht tps://www.chartae-antiquae.cz/tiles/ntm/mapy/1440_400dpi/ImageProperties.xml obraz.jpg -x -v. W Windowsie sprawa była prosta - trzeba było wrzucić folder ze skryptem dezoomify i folder z płytkami do katalogu Pythona, wejść do tego katalogu i użyć podanego wyżej polecenia. A jakich poleceń należy użyć w linuxie, żeby skleił ten obraz? Foldery z dezoomify i z płytkami mam na windowsowskiej partycji D. Próbowałem skopiować te foldery do katalogu z Pythonem (/usr/bin/), ale się nie da. Trzeba chyba jakoś podać ścieżki do tych folderów...

[pawel764587k]

Wrzuciłem skrypt do katalogu roboczego ( /home/xubuntu/ ), ale nie widzi jpegtran, mimo że wrzuciłem go do tego samego katalogu. Wyrzuca komunikat, że nie znaleziono jpegtran w katalogu skryptu...

[wariant_b]

pawel764587k napisał:

> W jaki sposób teraz uruchomić skrypt w linuxie live?

Jak napisałem wcześniej, ponieważ nie bardzo mogę wyłączyć komputer, zrobiłem to
w maszynie wirtualnej (VirtualBox, pamięci musisz dać 4GB, linux MX-21.1 linia debian stable)
Jak już masz linuxa ściągasz dezoomify (pobierze się wersja dezoomify-1.4.tar.gz dla linuxa).
Rozpakowujesz ją do swojego folderu (ja zrobiłem sobie folder DEZOOMIFY na pulpicie).
Zapisałem skrypt .sh z poleceniem, które mi podałeś. W moim linuxie python nazywa się "python3",
a https musiałem przerobić na http. Sprawdź, czy używane pliki mają atrybut wykonywalności "x",
bo nie zostaną uruchomione. Uruchamiasz skrypt z użyciem konsoli i leci.

[pawel764587k]

Tak jak pisałem, nie ma sensu u mnie robić to w VirtualBoxie, bo nie wystarczy pamięci. Ta mapa składa się z 11904 płytek, a są takie, które mają 30 tys. płytek i więcej.

Ściągnąłem dezoomify-1.4.tar.gz, rozpakowałem, ale po odpaleniu skryptu wyrzuca komunikat: "jpegtran does not have the '-drop' feature" (i dalej, że należy użyć jpegtran dołączonego do Dezoomify lub pobrać z jakiejś stronki, komunikacja z jpegtran została przerwana a proces ubity). Nie wiem, o co w tym chodzi. Używam Xubuntu 18.04.4 w wersji live, też mam python3. Zarówno polecenie z https jak i http daje taki sam błąd.

Mógłbyś wrzuć swój skrypt .sh na jakąś stronkę, spróbowałbym go odpalić u siebie.

[wariant_b]

pawel764587k napisał:

> Ściągnąłem dezoomify-1.4.tar.gz, rozpakowałem, ale po odpaleniu skryptu wyrzuca
> komunikat: "jpegtran does not have the '-drop' feature" (i dalej, że należy użyć jpegtran
> dołączonego do Dezoomify lub pobrać z jakiejś stronki, komunikacja z jpegtran została
> przerwana a proces ubity). Nie wiem, o co w tym chodzi.
> Używam Xubuntu 18.04.4 w wersji live, też mam python3.

Potwierdzam - Xubuntu 18.04.5, bo takie było dostępne, daje powyższe komunikaty.
Na MX-21.1 w wersji live dezoomify chodzi, jak bozia przykazała (aczkolwiek zerwało
mi się połączenie z serwerem w trakcie pobierani kafli, co ew. trzeba by wyjaśnić)
Zatem ultimatum - albo robisz, o co cię proszą, albo sam rozwiązujesz swoje problemy.

> Mógłbyś wrzuć swój skrypt .sh na jakąś stronkę, spróbowałbym go odpalić u siebie.

To skopiowany tekst z twojego postu: python3 dezoomify.py -b ... itd., żeby nie trzeba
było wpisywać ręcznie lub nie kopiować do terminala przez schowek.
Gdybyś go sobie chciał wprowadzić, pamiętaj o atrybucie wykonywalności "x".
MX-21.1 live ma domyślnie użytkownika demo i hasło demo.

[pawel764587k]

wariant_b napisał:

> Na MX-21.1 w wersji live dezoomify chodzi, jak bozia przykazała...

Fajnie, tylko zmieści się to na pendrajwie 2 GB? Większego nie mam. Której konkretnie wersji MX-21.1 używasz (na stronie projektu widzę kilka wersji 64-bitowych)? Wolałbym jakiegoś lżejszego linuxa, także (a może przede wszystkim) dlatego, że obecnie mam bardzo słaby internet i pobranie 2 GB to nie taka prosta i łatwa rzecz jak u Ciebie.

Zerwanie połączenia to mały pikuś, gdyż - jak już napisałem - wszystkie płytki mam już pobrane na dysk.


> Zatem ultimatum - albo robisz, o co cię proszą, albo sam rozwiązujesz swoje pro
> blemy.

Robienie czegoś inaczej niż Ty nie musi oznaczać czyjejś złej woli, tylko na przykład brak możliwości technicznych, jakie masz Ty (mniej RAM w kompie, mały pendrajw, słabe łącze internetowe itd.). Warto się trochę zorientować w tej kwestii, zanim się postawi takie ultimatum.

[wariant_b]

pawel764587k napisał:

> Fajnie, tylko zmieści się to na pendrajwie 2 GB? Większego nie mam.

Musisz sprawdzić, ile miejsca oferuje twój pendrive - plik MX-21.1_x64.iso ma 1 920 991 232 bajty.
W razie czego poszukamy jakiejś mniejszej dystrybucji, ale są to kolejne próby, bo problemy być mogą.


> Robienie czegoś inaczej niż Ty nie musi oznaczać czyjejś złej woli...

Ale robienie czegoś inaczej bez podania uzasadnień już tak - niepotrzebnie marnuję czas.
Mam prawo domniemywać, że jesteś wyposażony adekwatnie do wykonywanych prac.

[pawel764587k]

Ja nie jestem "wyposażony adekwatnie do wykonywanych prac"? Mnie zależało na rozwiązaniu tego problemu w Windowsie 10 (patrz tytuł wątku), to Ty wymyślasz rozwiązania naokoło i każesz mi ściągać linuxy ważące po kilka GB (w których pewnie dobrze się czujesz, ale ja ich kompletnie nie znam). W takiej sytuacji mam prawo oczekiwać, że poprowadzisz mnie mniej więcej za rękę i nie będę musiał szukać wszystkiego w Google. Tak jak ja, żeby nie marnować Twojego czasu, już na samym początku podałem Ci, jakie konkretnie polecenia gdzie trzeba wpisać w skrypcie.

Ale mniejsza z tym, ja nie zakładam Twojej złej woli i doceniam Twoją chęć pomocy. Widać nie zrozumieliśmy się. Obecnie, z powodów jakie podałem wyżej, chyba będę szukał jakiejś możliwie najlżejszej dystrybucji linuxa. Wystarczy, żeby miał Pythona 3 (lub możliwość łatwego doinstalowania w wersji live) i umożliwiał dostęp do wifi. Każda pomoc będzie dla mnie przydatna.

Zabawę z większymi dystrybucjami linuxa muszę odłożyć na później.

[wariant_b]

pawel764587k napisał:

> Ja nie jestem "wyposażony adekwatnie do wykonywanych prac"?

Takie odniosłem wrażenie - możesz (choć jak widać nie bez problemów) pobrać
i poskładać pojedyncze mapy, bardziej masowe prace raczej ciężko będzie
wykonać w sensownym czasie.

> Mnie zależało na rozwiązaniu tego problemu w Windowsie 10 (patrz tytuł wątku)

Ale już wiemy, że rozwiązania wymagałby problem limitu 2 GB dla programów 32-bit.
Teoretycznie są takie możliwości, praktycznie wątpliwe i lepiej ich nie stosować.
Jeśli chcesz spróbować, zrekompiluj źródłowy jpegtran z flagą /LARGEADDRESSAWARE.
Program jpegtran ma również parametr -maxmemory N (co widać w helpie: jpegtran --help)
ale nie jest on wykorzystywany w skrypcie dezoomify.py. Można spróbować dopisać
go do dezoomify.py, ale skrypt jest zbyt skomplikowany, żebym chciał się tego podjąć.

> ... to Ty wymyślasz rozwiązania naokoło i każesz mi ściągać linuxy ważące po kilka GB

W linuxie widać, że jpegtran może zażądać więcej pamięci (u mnie było 2.2 GiB) i działać dalej.
Problem map był już tu kilka lat temu dyskutowany i stąd wiem, że linuxy nadają się do tego
celu lepiej niż Windows. Wspominałem już o specjalistycznej dystrybucji OSGeoLive-14.0
Proponuję najpopularniejsze i w związku z tym dobrze sprawdzone i udokumentowane
dystrybucje. A że są coraz większe - niewiele na to możemy poradzić.

Z wielu linuxów które sprawdziłem najlepiej zachowywał się MX-21.1 - wszystko działało
zgodnie z opisami. W innych był błąd "jpegtran does not have the '-drop' feature" albo
python nie widział jpegtran, choć ten był w kartotece z której uruchamialiśmy dezoomify.py
(tu wystarcza dopisać w wywołaniu parametr -j z określeniem ścieżki do jpegtran).
Z '-drop' nie bardzo wiem o co chodzi - skrypt próbuje uruchomić jpegtran

[wariant_b]

Aha, bo nie dopowiedziałem tego dosłownie:
- w VirtualBoxie równie dobrze możesz uruchamiać wersje live bez wychodzenia
z Windowsów i bez konieczności przygotowania pendrive'a. Starcza plik ISO.

[pawel764587k]

wariant_b napisał:

> Takie odniosłem wrażenie - możesz (choć jak widać nie bez problemów) pobrać
> i poskładać pojedyncze mapy, bardziej masowe prace raczej ciężko będzie
> wykonać w sensownym czasie.

Jakie "masowe prace" masz na myśli? Mam do złożenia około 20 map, przy czym płytki do wszystkich mam już pobrane.

> Ale już wiemy, że rozwiązania wymagałby problem limitu 2 GB dla programów 32-bit.

A które programy są 32-bitowe? Pythona zainstalowałem 64-bitowego i taki mam też komputer.

> Jeśli chcesz spróbować, zrekompiluj źródłowy jpegtran z flagą /LARGEADDRESSAWARE.

A dałbyś radę to zrobić? Mi takie ogólnikowe porady nic nie dają.

> Program jpegtran ma również parametr -maxmemory N (co widać w helpie: jpegtran
> --help)
> ale nie jest on wykorzystywany w skrypcie dezoomify.py. Można spróbować dopisać
> go do dezoomify.py, ale skrypt jest zbyt skomplikowany, żebym chciał się tego p
> odjąć.

Mi jeszcze przyszło do głowy, żeby napisać skrypt, który tylko łączy płytki (bez pobierania). Pewnie byłby dużo prostszy. Mamy następujący układ płytek:

0_0
0_1
0_2
...
0_n

1_0
1_1
1_2
...
1_n

2_0
2_1
2_2
...
2_n

...

n_0
n_1
n_2
n_n

Teraz wystarczy, żeby skrypt połączył wszystkie płytki w odpowiedniej kolejności.

Ale musiałby to zrobić ktoś, kto potrafi pisać skrypty w Pythonie.

Próbowałem to robić w ImageMagick, ale wychodzą jakieś cuda - nie zachowuje kolejności płytek, zmniejsza je dwukrotnie i wstawia jakieś białe ramki na zewnątrz i pomiędzy płytkami. A przede wszystkim do mapy składającej się z 11904 płytek zużył prawie cały RAM, jaki mam w komputerze.

> Wspominałem już o specjalistycznej dystrybucji OSGeoLive-14.0

OSGeoLive-14.0 waży 4 GB. Obecnie nie jestem w stanie go pobrać.

> Z wielu linuxów które sprawdziłem najlepiej zachowywał się MX-21.1 - wszystko
> działało
> zgodnie z opisami. W innych był błąd "jpegtran does not have the '-drop' featur
> e" albo
> python nie widział jpegtran, choć ten był w kartotece z której uruchamialiśmy d
> ezoomify.py
> (tu wystarcza dopisać w wywołaniu parametr -j z określeniem ścieżki do jpegtran
> ).
> Z '-drop' nie bardzo wiem o co chodzi - skrypt próbuje uruchomić jpegtran

[wariant_b]

pawel764587k napisał:

> A które programy są 32-bitowe? Pythona zainstalowałem 64-bitowego i taki mam też komputer.

32-bitowy jest jpegtran i to on chce zbyt dużej pamięci od WIndows.

> Mi jeszcze przyszło do głowy, żeby napisać skrypt, który tylko łączy płytki
> (bez pobierania). Pewnie byłby dużo prostszy. Mamy następujący układ płytek:
> Ale musiałby to zrobić ktoś, kto potrafi pisać skrypty w Pythonie.

Przecież sam podawałeś, że robi to dezoomify z parametrem -x

> A mógłbyś napisać, które dystrybucje sprawdziłeś? W wolnym czasie poszukam
> jakichś lekkich dystrybucji i nie chciałbym dublować Twoich wyników.

Początek listy wyszukiwania distrowatch.com dla systemów typu desktop, architekturze x86-64
i rozmiarze mediów instalacyjnych poniżej 2000 MB. Te, które są wyraźnie ponad 2GB pominąłem.
Dodatkowo używane przez ciebie Xbuntu-18.04 i aktualne 22-04 i niektóre starsze jak MX-19.4
Z mniejszych dystrybucji w szczególności linux-lite i AntiX. Prawie wszędzie jakiś problem.

> Natomiast dużym problemem będzie zbyt mała ilość wolnej pamięci przy VirtualBoxie.

Nie sądzę - jpegtran może wziąć jedynie trochę ponad 3 GB, a z linuxem i pythonem nie będzie
tego więcej niż 5 GB. Poza tym VBox posłuży ci do uruchamiania linuxów live pod Windows.

[pawel764587k]

wariant_b napisał:

> Przecież sam podawałeś, że robi to dezoomify z parametrem -x

Sęk w tym, że dezoomify właśnie tego nie robi i trzeba szukać innych rozwiązań.

Mam jeszcze skrypt merge.py, który służy tylko do łączenia płytek. Tylko niestety wyświetla komunikat "Max zoom : 7" i nie działa przy tej mapie (i innych dużych). Prawdopodobnie ma jakieś ograniczenie co do wielkości mapy (maksymalnego zoom).

Miałbyś ochotę go sprawdzić? Wrzuciłem go tutaj: megawrzuta.pl/download/2bca299d76b9f08e83269ba21d614026.html

Działa na Pythonie 2 (ja mam Pythona 2.7.4) i korzysta z biblioteki PIL (u mnie wersja 1.1.7). Do katalogu z płytkami należy wrzucić plik ImageProperties.xml z następującym tekstem:

<IMAGE_PROPERTIES WIDTH="32678" HEIGHT="23560" TILESIZE="256" />

Można utworzyć go w notatniku i potem zmienić rozszerzenie z .txt na .xml.

Łączenie następuje po wpisaniu w wiersz poleceń polecenia: python merge.py nazwa_katalogu_z_płytkami. Dodanie parametru -vv wyświetli dodatkowe komunikaty (np. o błędach).

Płytki można pobrać skryptem dezoomify, trzeba tylko dodać parametr -s w poleceniu.

Może da się w jakiś prosty sposób zlikwidować to ograniczenie.

> i niektóre starsze jak MX-19.4

A na MX-19.4 działa? Myślałem, żeby pobrać którąś starszą wersję tego linuxa (ale też wtedy, gdy będę miał lepszy internet), żeby mieć pewność, że zmieści się na pendrajwie.

> > Natomiast dużym problemem będzie zbyt mała ilość wolnej pamięci przy VirtualBoxie.
>
> Nie sądzę - jpegtran może wziąć jedynie trochę ponad 3 GB...

Jak Ty to obliczyłeś? 30 tys. płytek x 256 x 256 przy trzech bajtach na piksel (RGB) daje 5,5 GB. A mam jeszcze większe mapy.

[wariant_b]

pawel764587k napisał:

> A na MX-19.4 działa?

Działa, ale że nie widział jpegtran musiałem mu dopisać parametr -j ze ścieżką.
I (ale to już prawie generalnie w linuxach) - łączę się po http zamiast https.

Z monitorowania wykorzystania pamięci wynika, że łączenie zaczyna się w trakcie
pobierania i nie jest wykonywane na całości kafli, bo ilość pamięci zajmowanej przez
jpegtran jest stale taka sama - ok. 2.2 GB i nie przyrasta. Tymczasowe pliki wynikowe
(w Windows w %TEMP%) pokazują, że obraz składany jest pionowymi pasami.

W nowszej wersji MX-21.1 nie musiałem dopisywać parametru -j.

Natomiast mam notorycznie problem z rwaniem połączenia z www.chartae-antiquae.cz
więc będę wdzięczny za namiary innych serwerów, jeśli z takowych też korzystasz.

> Jak Ty to obliczyłeś? 30 tys. płytek x 256 x 256 przy trzech bajtach na piksel (RGB) daje 5,5 GB.

Nie liczyłem - 32-bitowy program nie może dostać większej pamięci niż teoretycznie 4GB,
praktycznie jakieś 3.5 GB - vide dostępna pamięć raportowana w 32-bitowych Windowsach.
Owszem, istniały kiedyś ekstendery pamięci, ale powodowały masę problemów i odkąd
są systemy 64-bit nie stosuje się ich w systemach 32-bit (na etapie kompilacji programu!).

Resztę sprawdzę jutro.

[pawel764587k]

wariant_b napisał:

> > A na MX-19.4 działa?
>
> Działa, ale że nie widział jpegtran musiałem mu dopisać parametr -j ze ścieżką.
> I (ale to już prawie generalnie w linuxach) - łączę się po http zamiast https.

W takim razie wezmę MX-19.4. Chyba że chciałoby Ci się przetestować jeszcze starszą (i lżejszą) wersję. Tylko musi mieć Pythona w wersji 3.

> Z monitorowania wykorzystania pamięci wynika, że łączenie zaczyna się w trakcie
> pobierania i nie jest wykonywane na całości kafli, bo ilość pamięci zajmowanej
> przez
> jpegtran jest stale taka sama - ok. 2.2 GB i nie przyrasta. Tymczasowe pliki wy
> nikowe
> (w Windows w %TEMP%) pokazują, że obraz składany jest pionowymi pasami.

To, że łączenie zaczyna się w trakcie pobierania, to prawda. Co do reszty, to z tego co mi wiadomo, skrypt najpierw wczytuje całą powierzchnię mapy i potem dokleja te pasy. Stąd ta stała ilość pamięci zajmowanej przez jpegtran. 11904 x 256 x 256 x 3 daje właśnie 2,2 GB.

Mówiąc inaczej, skrypt nie zejdzie z wykorzystaniem RAM-u poniżej liczby pikseli pomnożonej przez 3. Plus jeszcze jakaś ilość RAM-u na te pasy "robocze".

> Natomiast mam notorycznie problem z rwaniem połączenia z www.chartae-antiquae.c
> z
> więc będę wdzięczny za namiary innych serwerów, jeśli z takowych też korzystasz

U mnie też rwało połączenie. Niestety, innych serwerów nie ma, ale bardzo pomaga łączenie się z serwerem przez VPN (ale też czasem trzeba powtarzać pobieranie). Nie wiem, dlaczego tak jest. Ja czasem pobierałem płytki 2-3 razy, potem porównywałem sumy kontrolne plików w folderach i kompilowałem z nich jeden zawierający wszystkie i dobrze pobrane płytki. Czytałem też (ale nie testowałem), że pomaga dodanie parametru -t 1. Wtedy pobiera jednowątkowo zamiast wielowątkowego - bez błędów, ale też wolniej.
.
> 32-bitowy program nie może dostać większej pamięci niż teoretycz
> nie 4GB,
> praktycznie jakieś 3.5 GB - vide dostępna pamięć raportowana w 32-bitowych Wind
> owsach.

Ale chyba piszemy o linuxie? Tam też występuje to ograniczenie?

[wariant_b]

pawel764587k napisał:

> To, że łączenie zaczyna się w trakcie pobierania, to prawda. Co do reszty, to z tego
> co mi wiadomo, skrypt najpierw wczytuje całą powierzchnię mapy i potem dokleja te pasy.

Nie potwierdzę i nie zaprzeczę. W trakcie prób z pythonem 3.10.4 (bo taki mam w Windowsach)
czasem zdarzało się, że jpegtran nie wylatywał, ale pracował z minimalną ilością pamięci.
Ponieważ trwało to wieczność - przegrałem kartotekę tymczasową i mam paski 256 x 23560 px
a docelowe pliki z zerową długością (albo nie zaczęte, albo aktualnie otwarte).
Zobaczę, czy da się je połączyć z kartoteki, na razie nie udało mi się trafić ze składnią polecenia.

> Ale chyba piszemy o linuxie? Tam też występuje to ograniczenie?

Tak - w Windows 10 nie możemy przekroczyć 2 GB, bo tyle może dostać 32-bitowy program.

[pawel764587k]

pawel764587k napisał:

> > Ale chyba piszemy o linuxie? Tam też występuje to ograniczenie?

wariant_b napisał:

> Tak - w Windows 10 nie możemy przekroczyć 2 GB, bo tyle może dostać 32-bitowy p
> rogram.

Nie rozumiem tej odpowiedzi. Ja pytam o linuxa, Ty odpowiadasz na temat Windowsa. Czy w linuxie też nie możemy przekroczyć 2 GB? Bo jeśli tak, to jego pobieranie mija się z celem.


Co do MX-19.4, to którego mam pobrać? Jak już pisałem, jest kilka wersji 64-bitowych. Może być plik MX-19.4_x64.iso?
sourceforge.net/projects/mx-linux/files/Old/MX-19.4/

[wariant_b]

pawel764587k napisał:

> Nie rozumiem tej odpowiedzi. Ja pytam o linuxa, Ty odpowiadasz na temat Windowsa
> Czy w linuxie też nie możemy przekroczyć 2 GB? Bo jeśli tak, to jego pobieranie mija się z celem.

Przecież przekraczamy - na twojej przykładowej stronie jpegtran korzysta z 2.2 GB pamięci
i tworzy końcowy obrazek o wymiarach 32678×23560 zajmujący prawie 130 MB.
Ile dokładnie możemy uzyskać - nie wiem - na pewno trochę ponad 3 GB.
Ograniczenie w Windows 10 do 2 GB jest sztuczne, linux daje ile tylko może.

> Co do MX-19.4, to którego mam pobrać? Jak już pisałem, jest kilka wersji 64-bitowych.
> Może być plik MX-19.4_x64.iso?

Jeśli nie masz bardziej egzotycznego sprzętu, to jak najbardziej. To podstawowa wersja 64-bit.
Wersja ahs (Advanced Hardware Support) zawiera tylko dodatkowe sterowniki urządzeń.
Jeśli nic się nie zmieniło, będziesz musiał dopisać ścieżkę do jpegtran i używać http
zamiast https albo podziałać przy certyfikatach.

W międzyczasie rozwiązały się dwa problemy - parametr "-x" działa, ale wymaga żeby istniała
kartoteka o nazwie takiej jak ma mieć tworzony obraz, czyli jeśli chcesz złożyć mapę obraz.jpg
to tam gdzie będzie ten plik musi być również kartoteka obraz z pobranymi wcześniej kaflami.

Kafle u naszych Czechów są dostępne pod adresami:
www.chartae-antiquae.cz/tiles/ntm/mapy/1440_400dpi/TileGroup4/6-x-y.jpg
więc można sobie wygenerować nazwy plików i pobrać je osobno z pomocą wget lub aria2.
Aria jest mniej zawodna przy pobieraniu od modułu urllib pythona z naszego skryptu.

I to by chyba było na tyle - powodzenia w ściąganiu map.

[pawel764587k]

wariant_b napisał:

> > Może być plik MX-19.4_x64.iso?
>
> Jeśli nie masz bardziej egzotycznego sprzętu, to jak najbardziej. To podstawowa
> wersja 64-bit.

OK, może uda mi się dzisiaj albo jutro pobrać tego linuxa i dam znać, jak to działa u mnie.

> Kafle u naszych Czechów są dostępne pod adresami:
> www.chartae-antiquae.cz/tiles/ntm/mapy/1440_400dpi/TileGroup4/6-x-y.jpg
> więc można sobie wygenerować nazwy plików i pobrać je osobno z pomocą wget lub
> aria2.
> Aria jest mniej zawodna przy pobieraniu od modułu urllib pythona z naszego skry
> ptu.

Z pobraniem kafli za pomocą wget lub aria2 nie jest tutaj tak prosto, bo zmienia się też parametr przy TileGroup. Na przykład jak za x podstawisz 5, a za y 8, to wyrzuca komunikat "Not Found. The requested URL /tiles/ntm/mapy/1440_400dpi/TileGroup4/6-5-8.jpg was not found on this server.". Trzeba w tym przypadku zmienić parametr 4 przy TileGroup na 6. Grup jest z kilkanaście, a maksymalne powiększenie nie jest 6 (jak w Twoim linku), tylko 7 albo 8. Trzeba by wiedzieć, do której grupy przynależy która partia kafli. Można oczywiście wygenerować linki tak, żeby przy każdym kaflu program do pobierania sprawdzał każdą grupę z tych kilkunastu, ale możesz sprawdzić, ile linków wtedy zostanie wygenerowanych i ile czasu zajmie pobieranie. ;)

A co ze skryptem merge.py? Próbowałeś go przeanalizować i sprawdzić, czy da się skleić nim mapę z pobranych kafli?

[wariant_b]

pawel764587k napisał:

> Windows 10 powgrywał mi na pendrajwa jakieś pliki w folderze "System Volume Information"
> i wczoraj przez kilka godzin męczyłem się, jak go usunąć)

Nie bardzo rozumiem, jak zabrnąłeś w coś takiego. Na pendrive musiałeś mieć system plikowy
NTFS, bo Windows utworzy wtedy foldery systemowe dla kosza i "System Volume Information".
Nie należy ich samodzielnie ruszać, zresztą Windows będzie przeszkadzał i utrudniał dostęp.
Ściągnięty obraz linuxa w formacie ISO (format krążka DVD) wgrywasz na pendrive'a
rufusem albo podobnym narzędziem - przy okazji sformatuje pena przypuszczalnie do FAT32.

[pawel764587k]

Po prostu podłączyłem pendrajwa i Windows sam kiedyś wgrał ten folder. Problem dość powszechny z Windows 10, jak zorientowałem się na forach. Formatowanie nic nie daje, "System Volume Information" zostaje niezależnie, czy się sformatuje w FAT32 czy NTFS. Próbowałem wymazywania dysku, usuwania przez linuxa i nic. Jeden z plików tego folderu (odpowiedzialny za indeksowanie) udało mi się w końcu usunąć przez konsolę, drugi nadal siedzi na pendrajwie, ale na szczęście już nie uniemożliwia uruchomienia linuxa.

[wariant_b]

pawel764587k napisał:

> Po prostu podłączyłem pendrajwa i Windows sam kiedyś wgrał ten folder. Problem
> dość powszechny z Windows 10, jak zorientowałem się na forach. Formatowanie nic
> nie daje, "System Volume Information" zostaje niezależnie, czy się sformatuje
> w FAT32 czy NTFS.

Jeśli będziesz linuxa nagrywał, jak sugerowałem, za pomocą rufusa i w domyślnym standardzie ISO,
to kartoteki systemowe Windows w niczym nie przeszkadzają. Mogą sobie być. Jeśli po nagraniu
pendrive'a nie będziesz sprawdzał w Windowsach, czy jest na nim System Volume Information"
to go nie będzie, bo Windows nie zdąży go dopisać. Nie przejmujesz się tym i tyle.

[pawel764587k]

Dobra, udało mi się pobrać MX-19.4, zrobiłem pena, uruchomiłem w wersji live i skleiłem pierwszą mapę.

Jest tylko jeden problem. Nie wiesz, jak wejść do partycji C: albo D: w tym linuxie (na których mam foldery z kaflami)? Za każdym razem wyświetla mi się monit o hasło. Ściągnąłem kilka podręczników do różnych wersji MX, ale podane tam rozwiązania nie działają. Na razie rozwiązuję problem, kopiując kafle na drugiego pena (do pendrajwa na szczęście da się wejść) i później do katalogu demo linuxa, jednak kopiowanie po kilka razy folderów z tysiącami małych pliczków jest bardzo czasochłonne.

[wariant_b]

pawel764587k napisał:

> Dobra, udało mi się pobrać MX-19.4, zrobiłem pena, uruchomiłem w wersji live ...
> Jest tylko jeden problem. Nie wiesz, jak wejść do partycji C: albo D: w tym linuxie

Podać hasło roota, które to hasło brzmi: root

[pawel764587k]

Dzięki! Teraz praca idzie dużo szybciej. :)

Zapytam jeszcze raz o ten skrypt merge.py. Są mapy na innej stronie, gdzie kafle są zamieszczone w trochę inny sposób i dezoomify na nich nie działa. Kafle da się pobrać (właśnie arią lub wgetem), ale potrzebny jest skrypt, który by je potem połączył. Przykład takiej mapy: glam.uni.wroc.pl/index.php?s=OZK_13677_II_B_5446&view=single&p=3&browser=seadragon

Merge.py z małymi mapami pracuje dobrze, w przypadku dużych - tak jak pisałem - ma jakieś ograniczenia co do wielkości. Da się coś z tym zrobić? Jeśli nie chcesz się bawić z tym skryptem albo nie wiesz, jak go poprawić, to napisz otwarcie. Chcę wiedzieć, na czym stoję, najwyżej będę szukał pomocy gdzie indziej.

[wariant_b]

Będziesz musiał szukać dalszej pomocy gdzie indziej. Nie siedziałem nigdy w temacie map,
więc za dużo musiałbym się douczyć. Mapy z Wrocławia są robione, jak widać z podglądu,
w innej technologii, zapewne Microsoftu, bo widzę adresy kafelków .diz.
Skrypt merge.py korzysta ze starej wersji PIL i modułu Image - nie znam ich zupełnie,
więc nawet nie wiem, jakie programy graficzne są w tle i na czym polegają ograniczenia.
Być może również na zapotrzebowaniu na pamięć.

Jakbyś nie znalazł rozwiązania, to za jakieś dwa tygodnie będę miał więcej czasu
i będę mógł wrócić do tematu.

[pawel764587k]

Rozumiem. Na razie zrobię to, co się da, skryptem dezoomify. Niestety, przy mapie składającej się z 23 tys. kafli w linuxie też dezoomify brakuje pamięci: chartae-antiquae.cz/en/maps/54554

Dziwne, skoro skrypt potrzebuje na nią 4,2 GB (czyli zostaje jeszcze ponad 3 GB wolnego RAM-u).

[allegropajew]

C# ma podobnie. Jak wczytujesz tabelę do pola typu view w formularzu, to u mnie przy 2,5 miliona rekordów czasem wczyta, ale częściej walnie outofmemory error, po którym już nie idzie się stabilnie podnieść, trzeba zamykać aplikację. A RAM-u od wuja i jeszcze kilka razy więcej wirtuala.

Gościula