Stapelverarbeitung in ZOOM1#

Im Rahmen der neuen Europäischen Datenschutzbestimmungen, haben auch wir unsere Datenschutzrichtlinie mit Wirkung zum 25. Mai 2018 für alle Besucher, Nutzer unserer Website aktualisiert. http://projectsforum.de/neu/index.php?datenschutzerklaerung/ Die Änderungen umfassen eine genauere Aufklärung darüber, wie wir deine Daten verwenden, einschließlich deiner Auswahl- und Kontrollmöglichkeiten und deiner Rechte. Ab dem Stichtag unterliegt deine weitere Nutzung unseres Forums der neuen Datenschutzrichtlinie. Hast du Fragen dazu? Rufe uns einfach an unter 06461/989877, oder schreibe uns eine Nachricht an stefan@stefan-runkel-online.de Herzliche Grüße! Dein Projectsforum-Team
  • Hallo Michael, da bin ich wieder und nerve den "Meister".

    Ich gehe bei der Stapelverarbeitung davon aus, dass man die Größe einer Bildreihe mit einem Rutsch verändern kann. Das finde ich aber in ZOOM1# nicht.

    Man kann zwar die Güte eines Bildes verändern, aber was ist mit der Größe?

    Auch in Deinen Tutorials über ZOOM1# habe dazu nichts gefunden oder ich habe es, wie so oft, übersehen.

    Als kurz gesagt, ich benötige wieder Hilfe.

  • Post by Huebi123 ().

    This post was deleted by the author themselves ().
  • Hallo Hartmut,


    das lässt sich relativ leicht lösen:


    Schritt 1: Du lädst eines der Bilder direkt in ZOOM #1 ein und stellst die gewünschte Größe im Zoom ein

    Schritt 2: Nun öffnest du die Stapelverarbeitung: hier werden jetzt alle Bilder mit den Einstellungen die du in Schritt 1 vorgenommen hast vergrößert/verkleinert


    Auf diese Weise kann man alle Einstellungen für die Bildgröße direkt in der Stapelverarbeitung nutzen.


    Vg Michael

  • Hallo Michael,


    ich hatte im Zoomwebinar gepostet, dass bei der Stapelverarbeitung mit größeren Mengen das Programm abstürzt. Das Problem habe ich auch mit den Projects Programmen, z.B. Sharpen 3 pro. HDR Projects 8 pro hat da aber auch bei 220 Belichtungsreihen (660 Fotos) noch nie Probleme gehabt.


    Wenn ich einen Ordner mit 100 oder mehr Dateien, bei mir 9600x4800 bmp 131 MB, einlade, kommt am Ende des langwierigen Einladevorganges eine Fehlermeldung, dass zu wenig RAM Speicher vorhanden ist oder das Programm stürzt ab. Es gibt auch den Fall, dass die RAM Meldung kommt und der Bearbeitungsvorgang startet und läuft voll durch. Man darf nur nicht bei der Fehlermeldung ok drücken.


    Bei Zoom#1 gibt es noch eine Besonderheit, die ich im Webinar meinte:


    Wenn ich Bilder stark vergrößere kommt ein Hinweis, dass der RAM nicht reicht und es sehr lange dauern kann. OK, alles funktioniert aber. Will ich dann aber sehr vergrößerte Bilder verkleinern, gibt's den Absturz. Ein Hinweis, dass es länger dauert wäre mir lieber. Eigentlich wollte ich mit Zoom#1 mal 3400x3400 jpg vervierfachen und dann auf 5000x5000 verkleinern und schauen, was die Algorithmen im Sinne Pixel sortieren und Detailverbesserung bringen.


    Z.B. bei Affinity Photo dauert der Stapelimport auch sehr lange, aber 300 meiner o.g. Dateien sind kein Problem. In Topaz werden die Bilder sehr schnell eingeladen, 300 sind auch kein Problem.


    Warum müssen die Projectsprogramme mit den Bildern beim Einladen so viel machen? Kann man nicht auf eine Vorschau etc. verzichten und es wird dann jedes Bild im Ordner nacheinander eingeladen, bearbeitet, ausgegeben?


    Hardware ist ein Notebook Legion Y720 i7 7700HQ 16GB RAM iGPU Intel HD 630 und GPU Nvidia GTX 1060. Win 10 64 Bit. Programme laufen auf einer internen SSD (lesen hat mir ein Test über 2900 MB/s angezeigt, schreiben über 1100) und die Arbeitsordner liegen auf einer externen USB 3.0 SSD mit über 400 MB/s Lese- und Schreibgeschwindigkeit.


    Auf der internen SSD mit den Programmen sind nur noch 27,5 GB frei.


    Viele Grüße


    Thomas

  • Hallo Thomas,


    ja, ich erinnere mich daran, dass du das im Vortrag erwähnt hast.

    Wenn ich einen Ordner mit 100 oder mehr Dateien, bei mir 9600x4800 bmp 131 MB, einlade, kommt am Ende des langwierigen Einladevorganges eine Fehlermeldung, dass zu wenig RAM Speicher vorhanden ist oder das Programm stürzt ab. Es gibt auch den Fall, dass die RAM Meldung kommt und der Bearbeitungsvorgang startet und läuft voll durch. Man darf nur nicht bei der Fehlermeldung ok drücken.

    Hast du von dieser RAM Speicher Meldung evtl. einen Screenshot?

    (Sollte diese Meldung von Windows direkt kommen, können wir dagegen nichts machen)


    Hast du mal geschaut, wie viel Arbeitsspeicher zu diesem Zeitpunkt noch frei ist?


    Wenn ich Bilder stark vergrößere kommt ein Hinweis, dass der RAM nicht reicht und es sehr lange dauern kann. OK, alles funktioniert aber. Will ich dann aber sehr vergrößerte Bilder verkleinern, gibt's den Absturz. Ein Hinweis, dass es länger dauert wäre mir lieber. Eigentlich wollte ich mit Zoom#1 mal 3400x3400 jpg vervierfachen und dann auf 5000x5000 verkleinern und schauen, was die Algorithmen im Sinne Pixel sortieren und Detailverbesserung bringen.

    Interessant - diese Frage nach "Vergrößern und dann wieder verkleinern" habe ich auch in den letzten 2 Wochen schon mehrfach gehört, das scheint ja wirklich ein Punkt von breitem Interesse zu sein.

    Rein mathematisch kann das Bild eigentlich nicht besser werden, aber optisch wäre das durchaus möglich.


    Bisher habe ich noch keinen Absturz bei mir reproduzieren können, was aber nicht heißt, dass dort keiner zu finden ist - ich bleibe dran:-)


    Zur Sicherheit noch einmal nachgefragt:

    Du skalierst 3400x3400 auf 400% und skalierst dann diese Ergebnisse auf 5000x5000 und dabei stürzt das Programm in der Stapelverarbeitung ab - korrekt?

    Wie viele Bilder nutzt du in einem Stapelverarbeitungstest?


    Warum müssen die Projectsprogramme mit den Bildern beim Einladen so viel machen? Kann man nicht auf eine Vorschau etc. verzichten und es wird dann jedes Bild im Ordner nacheinander eingeladen, bearbeitet, ausgegeben?

    Das ist leicht zu beantworten - weil die Vielzahl der Kunden dies so haben sollte.

    Die grafische Stapelverarbeitung wird hier von vielen vorgezogen, weil scheinbar nicht jeder weiß, was sich zum Beispiel hinter seinen RAW Dateien verbirgt.


    Aber der Einwand ist auf jeden Fall gut - vielleicht kann man so etwas wie eine "Stapelverarbeitung Light" machen (umschaltbar), die dann die ganzen kleinen Bilder weglässt.

    Das würde zumindest einiges an Zeit einsparen - ich schreibe es auf meine Liste :-)


    ...und die Arbeitsordner liegen auf einer externen USB 3.0 SSD mit über 400 MB/s Lese- und Schreibgeschwindigkeit.

    An dieser Stelle geht die meiste Zeit verloren - wenn da ein paar größere Tif oder Raw Dateien geladen werden, geht das direkt in die Sekunden.

    Die 400MB sind dabei die lineare Lese-/Schreibgeschwindigkeit, die aber bei mehr als einer Datei nur ganz selten erreicht wird.


    VG Michael

  • Hallo Thomas,


    ich habe jetzt eine ganze Weile mit den Daten gekämpft und das Problem untersucht - dabei ist mir einiges aufgefallen, was mir selbst bisher gar nicht so klar war.


    Was genau habe ich gemacht...



    Test 1: Skalierung von 100 Bildern 9600x4800 Pixel auf 400% -> 38400x19200 Pixel (ca. 737 Megapixel) in der Stapelverarbeitung

    (ich hatte noch ein stereo Bild aus einem vorherigen Fall von Dir, dass ich einfach 100x dupliziert habe)


    Dieser Test lief auf meinem Rechner sauber durch und sollte auch auf deinem System möglich sein, wenn Windows und andere Programme nicht allzu viel Speicher nebenbei verbrauchen:

    An meinem Screenshot sieht man, dass hier bereits 17.6GB Arbeitsspeicher verbraucht werden (also vom System, anderen Programmen und ZOOM #1), das sollte mit einem 16GB System in den meisten Fällen stabil funktionieren.



    Test 2: Skalierung von 100 Bildern 38400x19200 Pixel auf UHD2 (7680x3840 Pixel) in der Stapelverarbeitung

    Auch dieser Test lief auf meinem System sauber durch und hat auch eine ganze Weile gedauert (nicht erstaunlich bei 100x Skalieren einer Plakatwand von 3,25m x 1.62x bei 300dpi)


    Was hier nun auffällt ist, dass der Speicherverbrauch bei der Verkleinerung eines sehr großen Bildes erheblich höher ist (hier 48.8GB Arbeitsspeicher auf meinem 64GB System).


    Damit kommt ein 16GB System nicht mehr klar, das theoretische Maximum bei 16GB im System liegt bei etwa 40GB, dann dauert aber alles ewig - jeder Verbrauch darüber bringt Windows zum direkten Crash, also nicht die Anwendung, sondern Windows direkt.


    Und genau hier kommt die Fehlermeldung von Dir ins Spiel "Kritischer Fehler: Es steht nicht genug Arbeitsspeicher zur Verfügung" - diese Meldung haben wir eingebaut, wenn wir vom System gemeldet bekommen, dass der Speicher für das Ergebnisbild (oder einen in der Berechnung notwendigen Buffer) nicht "allokiert" (also reserviert) werden kann.

    Mit dieser Fehlermeldung verhindern wir den Systemabsturz.



    Test 3: Mit welcher Größe könnte ein 16Gb System bei deinen Bildern klarkommen?

    Im nächsten Test habe ich mich dann Schrittweise herangetastet, was auf einem 16GB System "gerade so" noch möglich sein könnte - auch das ist nicht zu 100% stabil, weil Windows immer hier und da Dienste startet, die man nicht verhindern kann und die auch Speicher verbrauchen.


    Ergebnis: 9600x4800 -> skalieren auf 19200x9600 (200%) -> skalieren auf UHD2 (7680x3840)



    Fazit:

    Die Berechnung großer Bilder, insbesondere wenn diese zur Verkleinerung eingeladen werden, benötigen eine Menge Speicher.


    Woran liegt das?

    Alle Pixel werden in ZOOM in 16-Bit pro Kanal gespeichert, damit auch hochgenaue Bilder gut skaliert werden können - Alle Berechnungen finden in mindestens 32-Bit pro Kanal statt und werden dann zu einem 16-Bit Ergebnisbild verrechnet -> maximale Genauigkeit in der Berechnung.


    Lädt man große Bilder zur Verkleinerung ein, müssen diese großen Bilder zum Beispiel geschärft oder entrauscht werden - solche Effekte benötigen zusätzlichen Speicher (bis zu 18 Byte pro Pixel). Deswegen ist der Speicherverbrauch bei Verkleinerung auch höher als bei Vergrößerungen (weil hier das Basisbild klein ist).



    Puh, das war eine lange Testreise, schlussendlich funktioniert die Software aber so gut wie es mit Windows und dem vorhandenen Speicher eben möglich ist.


    Leider kann man das auch vorher nicht exakt abprüfen, da sich der aktuell verfügbare Speicher in einem Windows System inzwischen permanent ändern, auch ohne dass man zusätzliche Programme startet.


    VG Michael



    PS: Wenn du hier ein großangelegtes Experiment machen möchtest, kann ich Dir anbieten die Stapelverarbeitungen bei mir durchlaufen zu lassen :-)

  • Hallo Michael,


    die Aufgabe der Projectsprogramme und von Zoom ist bei mir, Stapel mit 9600x4800 Bitmap 131MB pro Bild auf 7680x3840 zu reduzieren. Die Fehlermeldung kommt in Abhängigkeit der Anzahl der Bilder im Stapel. 660 Bilder hatte ich mal auf 7 Durchläufe verteilt. Genau am Ende des Einlesens des Bilderstapels kommt diese Fehlermeldung oder das Programm schließt sich, obwohl RAM gem. Taskmanager (noch) da ist. Das hat recht wenig mit der Einzelbildgröße zu tun, mehr mit der aufwendigen Importoperation.


    Mit Affinity verkleinere ich 660 dieser Bilder mit ca. 5x Parallelverarbeitung.


    Das ist ja das Problem.


    Viele Grüße


    Thomas

  • Hallo Thomas,

    die Aufgabe der Projectsprogramme und von Zoom ist bei mir, Stapel mit 9600x4800 Bitmap 131MB pro Bild auf 7680x3840 zu reduzieren. Die Fehlermeldung kommt in Abhängigkeit der Anzahl der Bilder im Stapel. 660 Bilder hatte ich mal auf 7 Durchläufe verteilt.

    Ok, wie ich sehe ist das Problem etwas anders gelagert, hat aber tatsächlich auch etwas mit dem Speicherverbrauch zu tun.


    Dieser Teil "Genau am Ende des Einlesens" ist hier der wichtige Teil :-)

    Genau am Ende des Einlesens des Bilderstapels kommt diese Fehlermeldung oder das Programm schließt sich, obwohl RAM gem. Taskmanager (noch) da ist. Das hat recht wenig mit der Einzelbildgröße zu tun, mehr mit der aufwendigen Importoperation.

    Die Anzeige im TaskManager zeigt Dir an wie viel Speicher vorhanden ist, aber nicht wie viel Speicher am Stück vorhanden ist.


    Es kann durch die vielen Bilder folgendes passieren:

    Der Speicher wird fragmentiert - also in Stücke zerlegt, so dass das angeforderte Stück Speicher nicht mehr in der Größe erfolgreich vom System bereitgestellt werden kann.

    Wir bewegen uns jetzt in die tieferen Strukturen des Speichermanagement-Systems von Windows, auf das man als Entwickler keinen Einfluss hat.


    Ich möchte das an einem stark vereinfachten Beispiel verdeutlichen:

    - du hast ein System mit 4 GB Arbeitsspeicher, dieser liegt 1GB weise so ab: [1GB] [1GB] [1GB] [1GB]

    - Windows (WIN) verbraucht gerade mit den anderen Anwendungen 2GB Arbeitsspeicher, und zwar so belegt [1GB] [WIN] [WIN] [1GB]

    - nun kommt ZOOM ins Spiel und möchte einen Speicherblock von 2GB Größe haben (wie gesagt, stark vereinfachtes Beispiel)

    - Windows meldet zurück "keine 2GB Speicher verfügbar" -> obwohl noch 2GB verfügbar sind, aber eben nicht "in einem Stück"


    Dieser Effekt nennt sich "Fragmentierung" und wird im Normalfall von der MMU (Memory Managing Unit) im PC geregelt. (So etwas hat man auch auf Festplatten)


    Schlussendlich haben wir also wahrscheinlich doch ein Speicherproblem, aber vermutlich durch Fragmentierung verursacht.



    Was können wir tun, um das auszuprobieren:

    (a) Mit Anzahl=1 Bild in der Stapelverarbeitung beginnen und schauen ob das klappt

    (b) Wenn es geklappt hat die Bild-Anzahl verdoppelt (von 1 auf 2, 2 auf 4, von 4 auf 8, etc.) und wieder zu Schritt (a) gehen, solange bis der Abbruch des Programmes durch die Speichermeldung


    Tritt dieser Effekt mit einem Wert von Anzahl > 1 auf, also bei mehr als einem Bild aber nicht bei einem Bild, dann ist es ein Speicherproblem, was durch "mehr Speicher" verschoben werden könnte.


    Mit Affinity verkleinere ich 660 dieser Bilder mit ca. 5x Parallelverarbeitung.

    Ja, Affinity Photo verkleinert auch anders (ich sage bewusst anders, weil ich die Qualität von Affinity nicht kenne) - ich vermute, dass das Verfahren in ZOOM #1 erheblich komplexer ist (inkl. integrierter Entrauschung und Unschärfebereinigung). Der Vergleich ist also schwer zu bewerten.




    Ich habe gerade den Test bei mir nachgestellt - 149 Bilder zu 9600x4800 auf 7680x3840 (UHD2) in die Stapelverarbeitung eingeladen.

    Das sieht dann so aus:


    Hmm... ich bin mir recht sicher, dass es am verfügbaren Arbeitsspeicher liegt.

    Mach doch bitte mal den Test mit 1 Bild, 2 Bildern, 4 Bildern, etc. und schau, ab wann es nicht mehr klappt.


    VG Michael


    PS: Die Stapelverarbeitung ist gerade fertiggeworden und hat alle 149 Bilder von 9600x4800 auf 7680x3840 herunterskaliert.

  • Wenn ich vom bmp auf jpg als Ausgangsformat gekommen bin, ist es kein Problem. In paar Wochen ist der neue Laptop fertig, da habe ich 32 GB RAM.


    Ich dachte, man könnte die Speicherbelastung beim Import reduzieren. Betrifft ja die ganze Projects-Familie auch. Da reduziere ich auf 64% der Pixelanzahl.

  • Hallo Michael,


    ich habe gerade mal den Test mit 400% Vergrößerung Standardeinstellung Qualität gut und leichtes Schärfen aus 9600x4800 bmp mit 10 Fotos im Stapel ausprobiert.


    Die Vergrößerung auf 38400x19200 funktioniert, wie in deinem Kommentar ausgeführt. Pro Bild ca. 1 Minute Bearbeitungszeit.


    Beim Einladen eines großen Bildes in Zoom#1 kommt zwar im Taskmanager keine Rückmeldung der Anwendung, aber es geht. Dann UHD2 mit Standard Qualität gut und leichtes Schärfen eingestellt.


    Nach dem Einladen der 10 großen Bilder in der Stapelverarbeitung kam wieder die Fehlermeldung wegen RAM, aber der Vorgang lief durch. Ca. 2 Minuten pro Bild.


    Allerdings sind die Ergebnisbilder alle schwarz ?(.


    Bis Software läuft stabil, auch wenn es theoretisch gar nicht funktionieren dürfte.


    Viele Grüße


    Thomas

  • Hallo Thomas,

    eim Einladen eines großen Bildes in Zoom#1 kommt zwar im Taskmanager keine Rückmeldung der Anwendung, aber es geht. Dann UHD2 mit Standard Qualität gut und leichtes Schärfen eingestellt.

    Nach dem Einladen der 10 großen Bilder in der Stapelverarbeitung kam wieder die Fehlermeldung wegen RAM, aber der Vorgang lief durch. Ca. 2 Minuten pro Bild.

    Ok, das ist auch interessant und zeigt uns, dass die Stapelverarbeitung zusätzlich Speicher benötigt und das in einer Höhe, die bei bestimmten Bildgrößen dann auch relevant wird.

    Große Einzelbilder funktionieren, wenige große auch in der Stapelverarbeitung und "viele" große Bilder in der Stapelverarbeitung werden dann mit der Speichermeldung abgebrochen.


    Das Alles weist immer wieder auf "das Ende des Arbeitsspeichervorrats" hin - damit lagen wir also wohl richtig.


    Wenn ich vom bmp auf jpg als Ausgangsformat gekommen bin, ist es kein Problem.

    Meinst du damit, wenn du anstatt .bmp Bilder in der Stapelverarbeitung .jpg Bilder einlädst, dann funktioniert es?

    Das würde bedeuten, dass der Speicherverbraucher in der Stapelverarbeitung im wesentlichen die Image-Library ist - das wäre für mich eine neue Information :-)


    Allerdings sind die Ergebnisbilder alle schwarz ?( .

    Die schwarzen Ergebnisbilder erhälst du, wenn ein Bildeffekt wie Entrauschen/Schärfen/etc. am Werk war und dieser für seine Zwischenspeicher nicht genug Arbeitsspeicher vom System bekam.

    Um hier Abstürze zu vermeiden, habe ich diesen Schutz eingebaut.


    Es gibt also zwei Ebenen von Speicherschutz:

    - Ebene 1: Die Fehlermeldung in eigenem Fenster, wenn für das aktuelle Ergebnisbild nicht genug Speicher vorhanden war

    - Ebene 2: Das schwarze Bild, wenn für einzelne Effekte nicht genug Speicher vorhanden war


    Die Vergrößerung auf 38400x19200 funktioniert, wie in deinem Kommentar ausgeführt. Pro Bild ca. 1 Minute Bearbeitungszeit.

    Ok, an der Bearbeitungszeit merkt man schon, dass Windows hier Arbeitsspeicher auf die Festplatte auslagert.

    Bei mir mit ausreichend Arbeitsspeicher dauert der Vorgang ca. 12 Sekunden, wobei 7 Sekunden davon nur das Speichern eines Bildes ist.


    VG Michael

  • Hallo Michael,


    ich habe jetzt die 149 Bilder zuerst in jpg umgewandelt und dann in Zoom#1 von 9600x4800 auf 7680x3840 UHD2 reduziert. Gleiches Verhalten der Anwendung, wie direkt aus den .bmp. Die Fehlermeldung kommt, der Vorgang läuft aber auch voll durch. Ich glaube in Sharpen 3 hatte ich das Problem, welches ich dann gelöst hatte, indem ich viele Bilder in einzelne Ordner von unter 100 Stück aufgeteilt hatte und dann jeden einzelnen Ordner über die Stapelverarbeitung einzeln laufen lassen habe.


    Da Thema Verkleinerung von den Zoom#1 400% Fotos 38400x19200 auf UHD2 ist mir im Stapel über Affinity mit "lanzcos nicht trennbar" gelungen. Ich musste nur die parallele Verarbeitung ausschalten, da sonst 8 Bilder parallel verarbeitet werden und es extreme Auslagerung auf das Laufwerk C gab.


    Nun muss ich noch herausfinden, ob dieser Gigaprozess gegenüber einer direkten Schärfung Vorteile bringt oder nicht. In ersten Tests war meine Feststellung so, dass (deine8o) Mathematik recht hat und es maximal durch die Schärfeprozesse eine Veränderung bringt. Aber das Hochrechnen in Zoom#1 und dann wieder Verkleinern bringt mich nicht näher an das Sensor-Shifting, was ja der Auslöser meiner Überlegungen war.


    So nun wünsche ich einen schönen Ostermontag und wetterbedingt wird die Bildbearbeitungssoftware nicht zu kurz kommen :)


    Thomas

  • Hallo Thomas,

    Nun muss ich noch herausfinden, ob dieser Gigaprozess gegenüber einer direkten Schärfung Vorteile bringt oder nicht. In ersten Tests war meine Feststellung so, dass (deine 8o ) Mathematik recht hat und es maximal durch die Schärfeprozesse eine Veränderung bringt. Aber das Hochrechnen in Zoom#1 und dann wieder Verkleinern bringt mich nicht näher an das Sensor-Shifting, was ja der Auslöser meiner Überlegungen war.

    ich bin sehr gespannt auf deine Ergebnisse, ob man damit etwas herausholen kann :-)



    Ich arbeite übrigens an einem ähnlichen Verfahren für die vermutlich "übernächste" Generation des Zoom-Programmes.


    Hier soll man dann dem DeepLearning eine virtuelle Zoom-Stufe mitgeben können, die intern das Bild auf (x2,x4,x8,etc.) rechnet und das Ergebnis dann auf die gewünschte Zielgröße zurück skaliert.

    Das nennt sich dann "Super Sampling" direkt integriert in das Skalierungsverfahren - du skaliert also zum Beispiel eine RAW Datei auf 200%, dann wird diese mit Super-Sampling x4 behandelt und intern auf 200% x 4 = 800% skaliert und das Ergebnis wird dann zurück auf 200% gebracht.


    Schlussendlich eine Automatisierung der aktuellen Experimente, allerdings mit einer direkt integrierten Konturenschärfung und Unschärfe-Reduzierung, die direkt in jeder Bildverdopplung angewandt wird.


    Anbei dazu 3 Bilder:


    (a) Original


    (b) Skalierung auf 800% mit meiner aktuellen Entwicklungsversion von ZOOM


    (c) Skalierung auf 800% mit 200% Super-Sampling


    Die Bilder in voller Auflösung vergleichen.


    VG Michael

  • Hallo Thomas,

    Ich habe heute aus der Projects-Familie Emotions pro gekauft und eine Vorlage gebastelt. Im Stapellauf mit 145 Bitmap 9600x4800 kam auch diese RAM-Fehlermeldung, aber der Durchgang lief gut durch. Vielleicht braucht es diese Fehlermeldung gar nicht :/ ? Wer draufklickt hat verloren. Also während dem Bildereinladen schon Start drücken und schnell weg ^^ .

    Ok, das ist ein interessanter Effekt - es könnte hier tatsächlich daran liegen, dass ein Notebook verwendet wird (es war doch ein Notebook oder?)

    Notebooks nutzen meist Shared-Memory, d.h. der Arbeitsspeicher teilen sich der Rechner und die Grafikkarte - reserviert nun die Grafikkarte Speicher könnte es zu dieser Meldung kommen.

    Sehr interessant... ich werde da mal ein wenig drüber nachdenken... Danke für die Info!


    Vg Michael

  • Ja, das ist eine Notebook mit iGPU und GTX 1060. Allerdings habe ich noch nie beobachtet, dass der GPU-Speicher der GTX 1060 von nur 6GB V-RAM irgendwie bei den Projects-Programmen genutzt wurde. Affinity hatte bei der Parallelverarbeitung von je 8 Stück 4-fach gezoomter Fotos massiv auf Laufwerk C ausgelagert.


    Wenn ich zu viele Fotos im Stapel habe, stürzten die Projectsprogramme nach dem Ping von vielfachen Fehlermeldungen ab, also schließen sich. Manchmal lief es auch nach vielleicht 10 RAM-Warnungen einfach durch. Vielleicht helfen diese Informationen.

  • Hallo Thomas,


    danke für die Infos! Jede Information kann dabei hilfreich sein.


    Ich muss nun einen Rechner in meiner Umgebung finden, auf dem ich das Problem reproduzieren kann - nur dann kann ich live versuchen herauszufinden, was da bei Dir passiert.

    Bisher hab ich von einem solchen Problem in vielen Jahren "projects Programme" noch nichts gehört - evtl. ist das ein Effekt der erst in Windows 10 auftritt.


    Mal schauen, ob und was ich rausfinden kann - aktueller Stand ist, dass die Fehlermeldung ausgelöst wird, durch die Reservierung des Speicherbereiches für die Post-Processing Berechnung ausgelöst wird - das "dumme" daran ist, dass das nicht passieren dürfte :-) Ich suche weiter...


    VG Michael

  • Gibt's den ein Aufzeichnungsprogramm für die ganzen Prozesse und Speicheranfragen? Da könnte ich dir ein Protokoll schreiben lassen. Für einen Virtual Reality Videoportal in Windows Mixed Reality habe ich das mal gemacht. Die hatten ein Tool. Da ging's aber um Serveranfragen etc..