Announcement

Collapse
No announcement yet.

Out of memory bei mehrmaliger Feinrotation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Out of memory bei mehrmaliger Feinrotation

    Hallo,
    ich bekomme nach Scan eines Bildmaterials in 1200dpi nach mehrmaliger Feinrotation (meistens 0.25 bis 1 Grad) mit Sicherheit meistens einen Out-Of-Memory-Fehler.

    Ist alles auf 4.25 inkl. Plugins. 2 GB DDR-RAM sind installiert.

    Ebenfalls auf anderem Rechner mit 4 GB (3.5 GB werden genutzt) probiert und selbes Problem bekommen.

    Fakt ist, IrfanView nimmt sich pro Rotation um so mehr Speicher und irgendwann geht nix mehr...

    Ist das Ein IrfanView-Bug oder hängt's eher am Algorithmus oder frisst das bei einem derart großen Bild in A4-Größe einfach naturgemäß soviel Speicher?

    Nachdem die Meldung angezeigt wird, meinte ich, dass er mir manchmal das vorhandene Bild nicht mehr speichern wollte ("[...] nicht verarbeiten").
    Attached Files
    Last edited by furziger; 01.12.2009, 02:39 PM.

    #2
    Wieviel Pixel haben die Bilder so und welche Farbtiefe?
    Wenn Windows die Antwort ist, wie blöd war dann die Frage?
    Windows ist nicht die Antwort, sondern die Frage!
    Und Nein lautet die Antwort!

    Comment


      #3
      9058 X 13636 x 1 BPP = OCR (schwarz/weiß)

      Comment


        #4
        Originally posted by furziger View Post
        9058 X 13636 x 1 BPP = OCR (schwarz/weiß)
        Dann wundert mich nichts! Jedes Bild allein in sw bereits 15 mb und wenn das dann auch noch angezeigt werden muß, braucht eine bitmap vermutlich 480 mb im Speicher (bei 32 bit) bei einmaligem Vorhandensein. Bei rotation muss es eigentlich zweimal im Speicher sein!

        Das ist ohnehin alles recht eng, denke ich! Schilder das halt mal dem Programmierer, wenn Du willst!
        Wenn Windows die Antwort ist, wie blöd war dann die Frage?
        Windows ist nicht die Antwort, sondern die Frage!
        Und Nein lautet die Antwort!

        Comment


          #5
          Naja, IV hat aber keine Undo-History, sprich man kann nur den letzten Schritt rückgängig machen, daher sollten nicht für jeden Schritt neue Bilddaten im Speicher abgelegt werden.

          Allerdings hat die Feinrotation ihre Tücken: beim Drehen wird das Bild größer. Dabei wird beim wiederholten Drehen aber auch der neu hinzugefügte Bereich jedesmal erweitert. Wenn man jetzt ein Bild mit 100x100 Pixel 10 mal um 1 Grad dreht, bekommt es bei mir die Abmessungen 125x123 Pixel. Dreht man es gleich um 10 Grad, dann wird es lediglich auf 118x117 Pixel vergrößert.

          Weiterhin verliert en Bbild beim wiederholten Drehen deutlich an Schärfe! Ein Tipp wäre, sich mit Drehen und Rückgängig an den Winkel heranzutasten. Und Dazu kann man auch mit einer Kopie des Bildes arbeiten und zuerst Verkleinern oder einen Ausschnitt nehmen. Bei großen Dateien geht's dann schneller.

          Ich habe das jetzt mal mit einer Datei getestet (11 mal gedreht, einmal Rückgängig, dmait der Undo-Puffer geleert wird), dieses dann gespeichert und in einer neuen Instanz geöffnet. Im Task-Manager sehe ich bei der geladenen Datei (TIF-Format) 45.608kb, bei der gedrehten 48.904kb. Es könnte hierbei ein Memory-Leak auftreten, aber mit Gewissheit kann ich das nicht sagen.

          Comment


            #6
            Originally posted by derniwi View Post
            Naja, IV hat aber keine Undo-History, sprich man kann nur den letzten Schritt rückgängig machen, daher sollten nicht für jeden Schritt neue Bilddaten im Speicher abgelegt werden.
            Wenn man bereits einen Undo-Schritt hat, braucht man eben den Speicher schon zweimal und selbst wenn kein Undo-Schritt existieren würde, bräuchte man bei Operationen, die im Laufe des Verarbeitens u. U. mehr Bytes schreiben müssen, als sie bereits gelesen haben (das ist beim drehen so), automatisch einen zweiten Schreibbereich, da der Lesebereich sonst überschrieben werden würde.

            Daß bei jedem Drehen Schärfe verloren geht, ist logisch. Es ist immer besser, ein Bild erst ein paar mal um wenige Grad zu drehen, die Gradzahlen addieren und dann bei zufriedenstellendem Ergebnis mit dem Original einmal mit dem Komplettwinkel zu drehen. Beispiel: nach 12 mal drehen um 2 Grad hast Du es geschafft. Dann drehst Du das Original einmal um 24 Grad.

            Speicherlecks sind ein altes Thema, aber bei solchen Mem-hungrigen Bildern erst recht. Mancher User nutzt IView für zig-tausende von Minibildern und andere wiederum nur wenige Bilder, diese aber sind Riesenmonster! Jeder hat andere Ansprüche an ein solches Programm und jedes mal kann eine andere Strategie die richtige sein, diese programmtechnisch zu erfüllen!
            Last edited by WeBu; 03.12.2009, 09:14 PM.
            Wenn Windows die Antwort ist, wie blöd war dann die Frage?
            Windows ist nicht die Antwort, sondern die Frage!
            Und Nein lautet die Antwort!

            Comment


              #7
              Originally posted by derniwi View Post
              Weiterhin verliert en Bbild beim wiederholten Drehen deutlich an Schärfe! Ein Tipp wäre, sich mit Drehen und Rückgängig an den Winkel heranzutasten.
              Habe ich meistens auch so gemacht. Nur manchmal war ich einfach zu faul, den Undo-Schritt abzuwarten und habe es dann weitergedreht, das generelle mit der (Un)Schärfe weiß ich zwar aber das war mir in dem Fall nicht so wichtig.

              Comment


                #8
                Originally posted by furziger View Post
                Nur manchmal war ich einfach zu faul, den Undo-Schritt abzuwarten und habe es dann weitergedreht
                Du tastest Dich mit der Eingabe immer andere Winkeleingaben an Dein Erbebnis heran. Ich nicht, daher hast Du meine Vorgehensweise falsch verstanden, denn diese hat mit Undo nix zu tun.

                1. Original nehmen
                2. Strg-U (Feinrotationsdialog) mit einem kleinen Winkelschritt bestätigen und diese Bestätigung mit 1 beginnend mitzuzählen

                3. Ergebnis im Hauptfenster besehen und ggf. ...
                4. Strg-U (Feinrotationsdialog) erneut bestätigen und weiterzählen

                3. und 4. sooft wiederholen, bis das (immer unschärfer werdende) Ergebnis die richtige Position hat! Jetzt die Zählung mit dem (immer gleichen Winkelschritt) miltiplizieren und dann einmal mit diesem errechneten Winkel eine Rotation an einem "frischen" Original (Strg-R = Neuladen) durchführen! Das meinte ich.

                Im Ergebnis heißt vielleicht 12 x hintereinander die Tastenkomination Strg-U und ENTER (bei. z. B. 2 Grad), was nur wenige Sekunden kostet und dann einmal mit den herausgefundenen 24 Grad rotieren.

                Probier das mal, das geht erheblich schneller, zumindest bei kleinen Bildern!
                Wenn Windows die Antwort ist, wie blöd war dann die Frage?
                Windows ist nicht die Antwort, sondern die Frage!
                Und Nein lautet die Antwort!

                Comment


                  #9
                  Originally posted by WeBu View Post
                  3. und 4. sooft wiederholen, bis das (immer unschärfer werdende) Ergebnis die richtige Position hat!
                  [...]
                  Probier das mal, das geht erheblich schneller, zumindest bei kleinen Bildern!
                  So hatte ich das Anfangs auch gemacht, bei kleinen Bildern geht das Herantasten sehr gut und auch schnell. Aber nimm mal eins in meiner angegeben Größe.

                  Das ist nämlich gerade das Problem! Ich kann nur, sagen wir mal, maximal 2x per Strg+U Feinrotieren, danach geht nix mehr, Speicherleck. Jede Rotation, selbst bei nur 1 Bit pro Pixel dauert bei so einem großen Bild mehrere Minuten.

                  Also ich rotiere 2x und danach gibt's die Out-Of-Memory Message, und meistens kann man danach das Bild noch nicht mal mehr speichern, ich nehme an, dass der Speicher von Irfanview dann so groß ist, dass kein Platz mehr für weitere Operationen ist.

                  Beispiel:
                  Bild (ungefähre Größe wie oben angegeben) laden, in meinem Fall ist es ein TIF mit CCITT-4-Komprimierung.
                  OS: Win XP Prof, 2 GB RAM, 2000 Mhz AMD X2 3800+ EE SFF mit 2x 512 KB Cache.

                  1. IrfanView starten, RAM-Verbrauch: 4.668 KiB
                  2. Bild geladen, RAM: 21.796 KiB
                  3. Nach STRG+U um 1 Grad in Uhrzeigerrichtung, RAM steigt auf über 600.000 KiB an und fällt dann nach kurzer IDLE-Phase auf 253.725 KiB
                  4. Schritt 3 wiederholen, RAM steigt auf über 1.3 GiB an und fällt bleibt nach kurzer IDLE auf 709.180 KiB stehen und wird auch nicht mehr weniger.
                  5. Bumm.... "Zu wenig RAM Speicher für Bild(er) vorhanden !"

                  Schritt 4 wird also nicht sauber ausgeführt. In manchen Fällen wollte ich das Bild dann speichern, damit ich die erste Rotation wenigstens nicht nochmal machen muss. Da IrfanView allerdings zu viel Speicher allokiert hat, klappt dann selbst das Speichern nicht immer und schlägt fehlt. Neustart einzige Chance.

                  Das selbe habe ich mal mit einem bereits eingescannten Dia versucht (als JPG abgelegt), welches nur so groß wie ein Ausschnitt des "großen" Bildes darstellt. Dort gibt's dieses Speicherleck auch, allerdings kann man zig-mal Rotiere, da bei jedem Vorgang "nur" 2-3 MiB mehr allokiert werden. Zu Fehlern bei 2 GB RAM (wo das OS standardmäßig nur die Hälfte nutzen sollte) kommt es da erst bei über 1000 Rotationen, also unkritisch.

                  Comment


                    #10
                    Hallo,

                    das Problem liegt schlicht und einfach daran, daß ein 32Bit-Programm ohne Klimmzüge erst einmal nur 2GB Ram verwenden darf. Und du sprengst durch den Undo-Puffer diesen Rahmen.

                    Ich habe gerade mal ein großes Bild im Bereich deiner Abemssungen erzeugt und getestet. Dabei bekam ich genau das von dir beschriebene Problem. Ich habe zwar ein 64Bit-Windows und 4GB Ram, aber IV ist eben nur als 32Bit-Anwendung kompiliert, so daß auch 64GB Ram nichts helfen würden. Ansonsten würde auch das System auslagern, wenn dafür genug Speicher vorhanden ist, aber wie gesagt, du sprengst einfach die 2GB-Grenze.

                    Versuche doch erst einmal, daß Bild zu verkleinern, so daß du dich beim Drehen schneller an den notwendigen Winkel herantasten kannst (das Drehen geht bei kleinen Bildern natürlich auch schneller). Im Endeffekt könntest du damit vielleicht sogar Zeit sparen. Das Drehen des großen Bildes (16000 x 10664 x 1BPP) um vier Grad dauerte bei mir ca. 90 Sekunden (im Hintergrund ist die Kiste noch andersweitig beschäfftigt).

                    Gruß, Nils.

                    Comment


                      #11
                      Ich war früher immer im Glauben, dass die Auslagerungsdatei benutzt wird, wenn mehr RAM als verfügbar gebraucht wird. Der IV-Prozess hat bisher für eine sehr kurze Zeit "nur" 1.3 GiB RAM beansprucht und trotzdem sagt er mir dann, dass nicht genügend RAM da wäre. Theoretisch hätte der doch noch 700 MiB mehr RAM nutzen können... ?

                      [EDIT]
                      Da hast du mich auf eine Idee gebracht. Ich habe den Undo-Puffer ("Rückgängig-Funktion benutzen (braucht mehr RAM)") mal abgeschaltet. Jetzt kann ich zwar evtl. eine Rotation mehr machen, die Kiste verrennt sich spätestens nach der 3. Rotation aber doch wieder. Nur mal oberflächlich drüber nachgedacht, lade ich ein Bild initial in den Speicher. Jetzt drehe ich das Bild was zusätzlich RAM braucht. OK, jetzt hab ich das gedreht Bild, gebe den Speicher für das initial geladene Bild wieder frei und benutze nur das gedrehte Bild als Original-Quelle. In dem Fall ohne Undo-Buffer dürfte doch kein Out-Of-Memory kommen wenn genug Speicher in der Kiste steckt?
                      [/EDIT]
                      Last edited by furziger; 05.12.2009, 02:56 PM.

                      Comment


                        #12
                        Naja, er braucht ja das Original-Bild, dann wird das neue Bild aus dem Original berechnet, was dazu führt, daß ja kurzzeitig zwei Bilder im Speicher liegen.

                        Comment


                          #13
                          Hallo,
                          ja das meinte ich. Aber wie du erwähnst, nur kurzzeitig. Das wäre ja auch ok und würde den Speicher nicht vollkommen. Nur braucht er pro Rotation jedes mal etwas mehr Speicher. Da wird irgendwie nicht exakt der Speicher freigegeben, der angefordert wurde, wenn man das äußerlich betrachtet. Beim GIMP konnte ich genau dieses Verhalten auch feststellen, allerdings schafft der GIMP es irgendwie, keine Fehlermeldung für den Benutzer zu erzeugen :-)

                          Was natürlich nicht heißen soll, dass ich das Ding für benutzen will, wenn ich Bilder drehe. Dafür sind so große Bilder mit IV einfach viel schneller geladen.
                          Ich hasse es kurz gesagt einfach, wenn Bildbearbeitungsprogramme eine Ewigkeit brauchen, bis die Oberfläche da ist. Wie schnell hat man das Hauptprogrammfenster dann doch wieder zugemacht und muss es erneut starten. Oder die Bildbearbeiter öffnen mir einfach zu viele kleine Fensterchen ohne MDI-Oberfläche, da werd ich beinahe wahnsinnig von...

                          Comment


                            #14
                            Wirf bitte nicht zwei Dinge durcheinander: Du drehst ein Bild. Dadurch erzeugt IV ein von den Abmessungen her größeres Bild. Währenddessen brauchst er aber noch das komplette Originalbild, da ja die Originaldaten aus verschiedenen Zeilen und Spalten für mehrere neue Pixel verwendet werden (Ausnahme sind nat. Drehungen umd 90, 180 oder 270 Grad). Das aber nach dem Drehen eines Bildes von 100x100x1 umd ein paar Grad ein Bild mit vielleicht 130x130x1 herauskommt, sollte schon klar sein. Die neu dazugekommenen Pixel brauchen halt auch ihren Platz. Bei größeren Dateien spürt man das eher.

                            Wenn jetzt IV ein Bild mit 10.000x10.000x1 in ein Bild mit 12.000x12.000x1 umrechnet, dann kommen eben 4.000 Pixel neu hinzu. Dieses Verhalten sollten auch andere Programme zeigen. So wie es aussieht, bist du halt mit deiner Datei gerade im Grenzbereich, so daß nach einmaligem Drehen daß Bild so groß wird, daß weitere Operationen den 2GB-Rahmen für 32Bit-Programm sprengen. Somit hast du eben ca. 11,92MB für das Original und ca. 17,17MB für die gedrehte Variante (nach den oben genannten theoretischen Abemssungen). So kann nach der dritten Operation aber nur der Speicher vom ersten Bild, also 11,92MB freigegeben werden, was so aussieht, als ob ca. 5MB verloren gehen.

                            Ob Irfan das Drehen optimieren könnte, weiß ich nicht. Andere Programme erstellen hierfür eine Art eigener Auslagerungsdatei, dabei müssen sie aber das Memorymanagement selbst entwickeln, um eben die 32Bit-Grenze zu umgehen. Dadurch wird aber vieles langsamer.

                            Für eine ältere Version von GIMP gab es ein Plugin, welches eine Photoshop-ähnliche Oberfläche anbot, so daß man dort ein Hauptfenster hat und die anderen Fenster darin integriert waren (eben auch PS-ähnlich). Für die nächste GIMP-Version ist die Ein-Fenster-Option direkt integriert (laut Ankündigung).

                            Comment


                              #15
                              Hallo,
                              das neue (nun) integrierte MDI-Feature von GIMP sollte ich mir wirklich mal anschauen :-)
                              Ich kenne das, wie du es auch erwähnt hast, nur von einer alten GIMP-Version bzw. Modifikation her, dass alles in einem Fenster ist, die Version war aber ziemlich alt.

                              EDIT:
                              Habe mir das mit dem Drehen nochmal angeschaut, das Ding wird ja tatsächlich größer. Habe von den letzten Beiträgen im Forum eher im Hinterkopf behalten, dass das Bild nur "intern" im Speicher temporär größer wird.

                              Eine Option in den Einstellungen, dieses Größerwerden abzuschalten, wäre wirklich cool. Danach wird zwar am Rand (an den Ecken) des Bildes etwas fehlen, aber das wäre mir in vielen Fällen sogar egal gewesen bei meinen Bildbearbeitungen per IV.
                              Last edited by furziger; 07.12.2009, 06:17 PM.

                              Comment

                              Working...
                              X