CPU zum Fotos verkleinern mit 1 Kern

linuxnutzer

Commander
Registriert
Dez. 2011
Beiträge
2.603
Es geht um eine CPU für Foto- und Videobearbeitung

Grafikkarte wird schon hier diskutiert: https://www.computerbase.de/forum/t...-grafikkarte-zb-5060ti.2240431/#post-30586856

schneup schrieb:
sinnvoller sich die RTX3060 anzuschauen

Um sich einer CPU anzunähern sind 2 Alternativen denkbar:

TDP: 65W
oder eventuell TDP 120W

Ich verwende normalerweise AMD-CPUs, aber wenn Intel in diesem vom Preis-Leistungsverhältnis besser ist, würde ich Intel nicht ausschließen.

OS ist Ubuntu Linux, dh die Frage ist auch, ob Ubuntu 24.04 die CPU unterstützt.

Budget ist nicht so genau, sage mal ca. 400€ max.

Problem ist, dass relevante Prozesse auf 1 CPU beschränkt sind und sich die anderen langweilen.

Hier sind Benchmarks vom aktuellen 5 Jahre alten System:

https://openbenchmarking.org/result/2505179-NE-SV2404GRA36
Resize: 190

https://openbenchmarking.org/result/2505173-NE-SV2404SYS50
Resize: 155

Wie vergleiche ich die angeführten Tests mit aktuellen CPUs?

Ergänzung:
Tests meines Systems zum Videos rechnen:

X264:
https://openbenchmarking.org/result/2505177-NE-SV2404X2695

X265:
https://openbenchmarking.org/result/2505171-NE-SV2404X2618

https://openbenchmarking.org/result/2505171-NE-SV2404SYS00

ffmpeg:
https://openbenchmarking.org/result/2505176-NE-SV2404FFM29
 
Zuletzt bearbeitet:
Nutze den graphics Magick test Der dort verlinkt und beschrieben ist.

Ich habe die letzten 15 Jahre sehr viele Bilder gemacht. um ca 15.000p davon immer sortiert dabei zu haben, habe ich sie alle auf 2mp verkleinert.

Dazu habe ich einen raspberry pi 3 eine Weile laufen lassen. Raw->jpg.
 
  • Gefällt mir
Reaktionen: ILoveShooter132
Verstehe nicht was du meinst, die Tests sind ja von meinem System.

madmax2010 schrieb:
Dazu habe ich einen raspberry pi 3 eine Weile laufen lassen. Raw->jpg

Ich nehme die Vorgabe ja nur als Beispiel. Es geht um viel mehr, vor allem mehrfache Größenänderung, Beschneiden, etc.. Zur Zeit brauche ich für alles bei 100 Fotos ca. 1h. Das soll schneller werden.

Es geht auch Programme wie Darktable und Handbrake unter Linux, aber die können ja mehrere Kerne nutzen.
 
madmax2010 schrieb:
Hilft dir eine hacky Lösung in bash Skript Form?

Genau so was verwende ich, ist sehr komplex, hat über 10000 Zeilen mit sehr vielen Bedingungen.

Ich will eine neue CPU und irgendwie muss ich einschränken, daher die Vorgaben.
 
Hast du mal Gnu parallel probiert? Simpel und klappt.


parallel 'convert {} -resize "$(identify -format "%[fx:100*sqrt(2000000/(w*h))]" {})%" resized_{}' ::: *.jpg

Vom 3800x zu aktuellsten CPUs bekommst du sonst auch nur ca 50% mehr single core performance..
 
  • Gefällt mir
Reaktionen: ILoveShooter132 und HerrRossi
madmax2010 schrieb:
Hast du mal Gnu parallel probiert? Simpel und klappt.

Das ist kaum machbar, weil die aktuelle Datei auf der vorhergehenden basiert. Eigentlich ist mir das zu kompliziert von der Logik und wenn ich sowieso die aktuelle und vorhergehende analysiere, dann kann ich gleich auch schreiben. Parallelisierung ist mir zu kompliziert, dazu müsstest du alle Vorgaben kennen, die an vielen Bedingungen hängen.
 
Absolut richtig. Aber du verarbeitest doch mehr als nur ein Bild, oder ?
Die kannst du doch parallel laufen lassen


Wenn du willst lasse ich die Tage mal auf einem 9700x und 7600x den test laufen
 
linuxnutzer schrieb:
Parallelisierung ist mir zu kompliziert, dazu müsstest du alle Vorgaben kennen, die an vielen Bedingungen hängen
Wenn jedes Bild für sich verarbeitet werden kann, ist die Parallelisierung völlig trivial.
 
  • Gefällt mir
Reaktionen: HITCHER_I, ILoveShooter132 und madmax2010
Backfisch schrieb:
Wenn jedes Bild für sich verarbeitet werden kann

Ja jedes Bild für sich, aber es ist nicht trivial, weil ja das Bild davor die Metadaten des nächsten bestimmt.

Erst nachdem 1 Bild berechnet wurde, kann man die Parameter für das nächste bestimmen und danach rechnen, nur so als Beispiel. Das ist weit mehr als "convert -resize". Ich habe "resize" nur als Beispiel angeführt um irgendwie eine CPU zu bestimmen. Beispiel. Serienfotos werden mehrere pro Sekunde gemacht, die werden aber umdefiniert, damit es pro Sekunde nur 1 Bild gibt und da gibt es viele solcher Spezialitäten, die über viele Jahre gewachsen sind. Die Fotos werden 3x komplett analysiert bis letztlich das resize passiert. Resize ist ein winziger Teil des Ganzen, passiert aber ziemlich oft.

madmax2010 schrieb:
Wenn du willst lasse ich die Tage mal auf einem 9700x und 7600x den test laufen

Du meinst, dass du mein Script bei dir laufen lässt? Ich schaffe es nicht mal es bei mir auf einem anderen PC laufen zu lassen. Da gibt es viel Schutz um die Original-Dateien nicht zu beschädigen, Bedingung über Bedingung, die stellt man nicht so leicht um. Es funktioniert alles wie gewüscht, aber ich weiß zum Teil nicht mehr, warum was passiert. Die ganze Logik um alten Fotos mit kaputten Metadaten plausible Metadaten zu verfüttern ist schon extrem komplex. Es gibt dann auch noch Online-Abfragen, zB Straßenname bezogen auf die GPS-Daten, da ist sowieso schwer vorherzusagen wie lange die dauern, aber für die Wahl der CPU ist das eine gegebene Situation.

Es gibt jetzt im Eingangsposting Tests zum Video-Encodieren, aber die sind auch nicht sehr aussagekräftig. FIlter in Handbrake bremsen gewaltig, speziell entrauschen, etc.

Wenn ich während des Rechnens der Benchmarks schaue, hat oft irgendein Threadripper unabhängig von der TDP die Nase vorn. Ganz allgemein, 2-3x schneller wäre theoretisch zu schaffen.

By Ryzen wäre der AMD Ryzen 9 7900 vermutlich nicht so schlecht. bei Intel kenne ich mich viel zu wenig aus. Vielleicht ein Intel Core i9-13900F, aber das sind dann eher die Ergebnisse von Videos rechnen.

Mir ist schon klar, dass man Videos über die Grafikkarte rechnen lassen kann, habe damit aber keine Erfahrung, ob mir die Qualität reicht.

Die ganzen Benchmarks von meinem System nützen nichts, wenn ich sie nicht mit den neuen Komponenten vergleichen kann
 
Zuletzt bearbeitet:
linuxnutzer schrieb:
Ja jedes Bild für sich, aber es ist nicht trivial, weil ja das Bild davor die Metadaten des nächsten bestimmt.

Erst nachdem 1 Bild berechnet wurde, kann man die Parameter für das nächste bestimmen und danach rechnen, nur so als Beispiel. Das ist weit mehr als "convert -resize". Ich habe "resize" nur als Beispiel angeführt um irgendwie eine CPU zu bestimmen. Beispiel. Serienfotos werden mehrere pro Sekunde gemacht, die werden aber umdefiniert, damit es pro Sekunde nur 1 Bild gibt und da gibt es viele solcher Spezialitäten, die über viele Jahre gewachsen sind. Die Fotos werden 3x komplett analysiert bis letztlich das resize passiert. Resize ist ein winziger Teil des Ganzen, passiert aber ziemlich oft.
und du willst nie mehr als 1 foto bearbeiten, und aus diesem Foto ergeben sich alle anderen?
Ich bin sehr interessiert was du machst
linuxnutzer schrieb:
Du meinst, dass du mein Script bei dir laufen lässt?
ne - das image magick benchmark
linuxnutzer schrieb:
Ich schaffe es nicht mal es bei mir auf einem anderen PC laufen zu lassen. Da gibt es viel Schutz um die Original-Dateien nicht zu beschädigen, B
backup? dateien vor editieren nochmal sichern?
linuxnutzer schrieb:
wahl der CPU ist das eine gegebene Situation.
wie gesagt, erwarte nicht viel mehr als 50% single core boost von einer neuen CPU

linuxnutzer schrieb:
Es gibt jetzt im Eingangsposting Tests zum Video-Encodieren, aber die sind auch nicht sehr aussagekräftig. FIlter in Handbrake bremsen gewaltig, speziell entrauschen, etc.
ja gut :) das ist ein standard benchmark bei dem du zu jeder CPU Resultate finden wirst
 
Ich würde ja als erstes mal die verwendete Software ändern, denn Ein-Kern Zeiten sind eigentlich seit 20 Jahren schon vorbei
 
  • Gefällt mir
Reaktionen: Pisaro, iSight2TheBlind, ILoveShooter132 und 2 andere
Da bin ich der gleichen Meinung wie @Aduasen . An Multi-Core-Nutzung/Parallelisierung führt kein Weg vorbei. Die Singlecore-Performance kann seit längerem nur noch in homöopathischen Dosen gesteigert werden. Grafikkarten zum Beispiel sind wahre Parallelisierungsspezialisten.

Im derzeit aktuellsten CPU-Test auf ComputerBase trennen die langsamste von der schnellsten CPU lediglich +55% im Single-Core-Betrieb.
Wohingegen bereits die Nutzung eines einzigen CPU-Kerns mehr, nahe +100% bringen würde.
Während man mehr Single-Core-Performance selbst für viel Geld und guter Worte nicht kaufen kann, bekommt man CPU-Kerne im Überfluss für vergleichsweise wenig Geld.
 
  • Gefällt mir
Reaktionen: JumpingCat, ILoveShooter132, linuxnutzer und 2 andere
linuxnutzer schrieb:
Ich nehme die Vorgabe ja nur als Beispiel. Es geht um viel mehr, vor allem mehrfache Größenänderung, Beschneiden, etc.. Zur Zeit brauche ich für alles bei 100 Fotos ca. 1h. Das soll schneller werden.

Ich schätze mal das ist ein problem von jpg
Windows hat genau das gleiche problem. Es wird nur 1 kern benutzt egal ob ich es mit Irfanview oder Photoshop mache. Da hilft nur viele MHz auf einem CPU-Kern
 
  • Gefällt mir
Reaktionen: linuxnutzer
Wenn sich dein Workflow so gar nicht parallelisieren lässt, könntest du einen 265K nehmen, der hat ausgehend von deiner CPU ca. 80% mehr ROHleistung auf einem Kern und ist preislich noch erträglich.
Ein Ryzen 7 7700 hat ca. 50% mehr Rohleistung, ist (ohne Garantie von AMD) dafür aber deutlich günstiger als der 265k, 190 vs. 309 EUR.
Kannst du die Sache denn automatisieren? Dann ist die Leistung zumindest im Hobbybereich doch eigentlich egal. Das Script am Abend oder zur Nacht hin anstoßen und den Kasten arbeiten lassen. Da das nur auf einem Kern läuft, könnte das ja auch während der normalen Nutzung des PCs laufen.
 
  • Gefällt mir
Reaktionen: linuxnutzer
Wenn es etwas aktuelles sein soll, mit hoher Effizienz, wäre der R5-8500G mit A620 Mainboard nicht verkehrt.
phoronix hat den auch mal getestet, und dann auch noch mal mit cTDP down.

Also man kann dann ja immer 6 Photos parallel umwandeln.
https://linux.die.net/man/1/parallel
 
  • Gefällt mir
Reaktionen: linuxnutzer
HITCHER_I schrieb:
Also man kann dann ja immer 6 Photos parallel umwandeln.

Mag schon sein, aber du masst ja die Variablen bereit haben, die du dazu brauchst und die kann ich nur hintereinander bestimmen.

HerrRossi schrieb:
Kannst du die Sache denn automatisieren? Dann ist die Leistung zumindest im Hobbybereich doch eigentlich egal.

Das Script macht es ja automatisiert, ist aber nicht lustig 3-4h zu warten, dann ein Problem entdeckt zu haben und nochmals zu rechnen. Ich will jetzt nicht behaupten, dass da keine Optimierungen mehr möglich sind, aber es ist getestet und funktioniert bis auf (zur Zeit) ignorierbare Fehler bei Foto-Scans. Da verliert man letztlich alle Fotos, wegen fehlerhafter bzw. nicht vorhandener Metadaten. Das muss ich irgendwann in Ruhe testen und sicher sein dass es auf die "normalen" Fotos keinen EInfluss hat. Bei den Metadaten muss man immer mit Überraschungen rechnen.

HerrRossi schrieb:
Da das nur auf einem Kern läuft

Ich habe dieses Beispiel jetzt nur genommen um bei den Überlegungen zur CPU Ideen zu bekommen. Ich brauche volle Power auch bei X265 und Handbrake. Allerdings weiß ich da wieder nicht, ob die FIlter mehrere Kerne nutzen können. Der Benchmark-Test zeigt, dass ein Video schneller als in Echtzeit gerechnet werden kann, letztlich dauert es mit meinen Einstellungen dann doch über Nacht (viele Stunden). Simit kriegt der PC einen Stresstest und rechnet 4 Filme vom Camcorder gleichzeitig. Aufpassen muss man, dass man die Feinheit des Rauschens nicht verbessert.

HerrRossi schrieb:
CPU ca. 80% mehr ROHleistung auf einem Kern

Man muss dann noch in Relation setzen zu möglichst vielen Kernen beim Video rechnen.
Aduasen schrieb:
Ich würde ja als erstes mal die verwendete Software ändern,

Welche?

Es geht primär um Exiftool und Imagemagick. Die Lösung für die Problemstellung ist nicht änderbar. Andererseits werden dann zum Videos berechnen möglichst viele Kerne gebraucht.

Dieses Programme werden über ein Bash-Scirpt abgearbeitet.

madmax2010 schrieb:
und du willst nie mehr als 1 foto bearbeiten, und aus diesem Foto ergeben sich alle anderen?
Ich bin sehr interessiert was du machst

Missverständnis. Es werden nicht aus 1 Foto mehrere gerechnet.

Es werden alle Fotos eines Ordners automatisiert umbenannt, Tags vergeben und pro Foto ca. 10 verschiedene Größen erstellt..

Das gibt es ganz viele Hürden, fängt schon bei fehlenden / kaputten Metadaten bei alten Fotos an und wird bei aktuellen Serienfotos kompliziert, wenn gleichzeitig mehrere gleiche Kameramodelle in Verwendung sind.

Es wird nicht einfach durchnummeriert, aber auch das ist schon bei mehreren Kameras mit Serienaufnahmen schwieirig. Das Original bleibt möglichst unverändert, in die bearbeitete Variante werden verschiedene Dinge geschrieben, die sich aus der Scriptlogik hintereinander ergeben.

Für die Sortierung und GPS-Datensynchronisation wird ein Foto mit der GPS-Zeit gemacht und dann die Differenz zur Kamera abgeglichen. Wird schon wieder kompliziert bei Zeitzonen-Wechsel. Fotos auf der Fähre von Spanien nach Portugal machen Freude ;-)

Nachdem es um ein paar TB Fotos in der Familie geht, überlege ich jetzt den gerade zu berechneten Ordner vorher auf was schnelleres, zB NVME umzukopieren und dann wieder zurückzukoperen.

madmax2010 schrieb:
backup? dateien vor editieren nochmal sichern?

So einfach ist das alles nicht. Stell dir vor 10000 Fotos sind problemlos und dann gibt es ein paar darunter, die haken, das merkst du nicht so leicht beim Testen des Scripts. Du müsstest also wissen, wann der Fehler passiert ist und ein inkrementelles Backup haben. Andererseits weißt du auch nicht, welche Änderungen du noch im Script vorgenommen hast. Manche Probleme entdeckt man nur zufällig. Deswegen will ich auch nichts an der Logik ändern, das ist ein riskanter Eingriff.

madmax2010 schrieb:
ja gut :) das ist ein standard benchmark bei dem du zu jeder CPU Resultate finden wirst

Na, dann bitte keinen Äpfel-Birnen-Vergleich. Bitte genau meine gemachten x225 und ffmpeg Tests zu

AMD Ryzen 9 7900 undn Intel Core i9-13900F,

MORPEUS schrieb:
Im derzeit aktuellsten CPU-Test auf ComputerBase trennen die langsamste von der schnellsten CPU lediglich +55% im Single-Core-Betrieb.

Also das als Kriterium bei der Wahl der CPU vergessen und auf maximale Kerne gehen?

Wenn die Logik so ist, dass man am besten alles hintereinander definiert, dann kann man eben nicht mehrere Kerne nutzen. Und ja, ein paar Dinge sind optimierbar, habe ich aber keine Lust bei 10000 Zeilen Code, der funktioniert, wenn man von den Spezialfällen absieht und da passiert immer was.

Ich habe gerade die Situation, dass ich ein Problem beheben muss.

Fotos mit Opencamera funktionieren tadellos bzgl. Portrait- und Querformat am Handy und PC

Fotos mit gleichem Handy von Proshot haben Probleme mit Portrait-Format und stellen es am PC um 90° gedreht dar, aber nicht am Handy.

Warum erkennt das Handy die Orientierung, der PC aber nicht? Mit der anderen App ist aber alles richtig. Sicher irgendein Problem mit den Metadaten, muss ich mir erst genauer ansehen.
 
Zuletzt bearbeitet:
linuxnutzer schrieb:
Na, dann bitte keinen Äpfel-Birnen-Vergleich. Bitte genau meine gemachten x225 und ffmpeg Tests zu
davon ausgehend dass du 264/265 meinst
https://openbenchmarking.org/test/pts/x264
https://openbenchmarking.org/test/pts/x265
bei letzterem musst du ein wenig vom x3700 hoch rechnen.

linuxnutzer schrieb:
So einfach ist das alles nicht. Stell dir vor 10000 Fotos sind problemlos und dann gibt es ein paar darunter, die haken, das merkst du nicht so leicht beim Testen des Scripts. Du müsstest also wissen, wann der Fehler passiert ist und ein inkrementelles Backup haben.
Ja gut, genau darum macht man doch inkrementelle Backups. Einfach alle paar Stunden im Hintergrund laufen lassen
linuxnutzer schrieb:
Andererseits weißt du auch nicht, welche Änderungen du noch im Script vorgenommen hast.
git hilft an der Stelle

linuxnutzer schrieb:
Missverständnis. Es werden nicht aus 1 Foto mehrere gerechnet.

Es werden alle Fotos eines Ordners automatisiert umbenannt, Tags vergeben und pro Foto ca. 10 verschiedene Größen erstellt..
Perfekte Voraussetzung um das zu parallelisieren

linuxnutzer schrieb:
Nachdem es um ein paar TB Fotos in der Familie geht, überlege ich jetzt den gerade zu berechneten Ordner vorher auf was schnelleres, zB NVME umzukopieren und dann wieder zurückzukoperen.
storage seitig sind Latenzen das was dich limitiert. nicht bandbreite. ssd reicht, hdd tut weh. Das verursacht viel IO Wait, denn zwischen SSDs und HDDs hast du ca 100xniedrigere Latenzen

linuxnutzer schrieb:
Das gibt es ganz viele Hürden, fängt schon bei fehlenden / kaputten Metadaten bei alten Fotos an und wird bei aktuellen Serienfotos kompliziert, wenn gleichzeitig mehrere gleiche Kameramodelle in Verwendung sind.
die kannst du dann noch immer zurückstellen. Du hast doch nicht ausschließlich Sonderfälle. Kategorisiere, parallelisiere und was uebrig bleibt kannst du noch immer serialisieren.

Denn
linuxnutzer schrieb:
Also das als Kriterium bei der Wahl der CPU vergessen und auf maximale Kerne gehen?
darauf wird es hinauslaufen.
 
  • Gefällt mir
Reaktionen: Backfisch und linuxnutzer
wern001 schrieb:
Windows hat genau das gleiche problem. Es wird nur 1 kern benutzt egal ob ich es mit Irfanview oder Photoshop mache.

Photoshop ist länger GPU lastig, mehrere CPU Kerne werden auch schon länger genutzt.
Irfanview läuft auch auf mehreren Kernen, wenn auch mit 20 oder 30 Jahren Verspätung.



Wie hier empfohlen: Die CPUs skalieren kaum noch einem Kern allein. Die Trend geht seit knapp 25 Jahren zu multicore. Es geht aktuell Richtung 256 CPU Kerne. Bei den GPUs sind wir schon länger über 20.000 Recheneinheiten


@linuxnutzer Bist du bereit dein Projekt in der Architektur auf einen aktuellen Stand zu bringen?
 
  • Gefällt mir
Reaktionen: linuxnutzer
JumpingCat schrieb:
Photoshop ist länger GPU lastig, mehrere CPU Kerne das auch schon länger.
Irfanview läuft auch auf mehreren Kernen, wenn auch mit 20 oder 30 Jahren Verspätung

Photoshop ist doch nicht GPU lastig. Viele funktionen laufen bei Photoshop nur auf 1-4 CPU Kernen.
Wenn man mit Irfanview oder Photoshop die batchkonvertierung mit 50% verkleinern macht sieht man im Taskmanager ganz genau das nur 1 CPU kern auf 100% läuft. Rest dümpelt bei 1-5% rum

Das Problem ist nicht die Bildbearbeitung sondern das laden/speichern der jpg. Bestes beispiel das erstellen der miniaturansichten, lastet ebenfalls nur 1 CPU-kern aus. Egal ob man die Miniaturansichen im MS-Explorer oder mit dem IrfanView Thumbnails macht.
 
  • Gefällt mir
Reaktionen: linuxnutzer
Zurück
Oben