Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
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.
Das Laden und Speichern darf nur auf der CPU stattfinden wo die eigentliche Arbeit läuft? Das ist doch Quatsch. So funktioniert Batch-Verarbeitung nicht.
In der Praxis macht man das so: Kern 1 lädt und dekomprimiert Bilder. Kern 2 komprimiert und speichert Bilder. Die Kerne ab 3 machen dann die Arbeitsjobs auf den Bildern im RAM. Ersetzte RAM gerne auch mit RAM-Disk.
Und sollte man noch auf einem langsamen Storage wie einer Festplatte, etc unterwegs sein, so kann mit einem Dummy-Job das nächste Bild in den Cache vorladen. Als simples Beispiel sei hier ein md5sum genannt was man auf das nächste Bild im Hintergrund parallel absetzt während man das aktuelle Bild lädt.
Imagemagick soll Multithread und auch OpenCL können, wird das genutzt ?
Das bringt auch was bei Einzelbildern, die werden zerlegt und auf mehreren Kernen wird gleichzeitig an einem Bild gerechnet.
Das habe ich aber nur aus deren Forum, welche Aufrufparameter das bewirken weiß ich nicht.
Damit es kein Missverständnis gibt, ich habe eingangs 2 x265-Tests gepostet und 1 x264. Diese möchte ich vergleichen und zwar nicht mit irgendwelchen x265-Tests, sondern mit den vor mir genannten.
https://www.chip.de/test/Intel-Core-i9-13900K-im-Test_184479429.html
Das klingt nach einer Menge, muss aber auch im Detail betrachtet werden: In der Hälfte der Tests ist der Unterschied einstellig, teilweise hat hier der Ryzen sogar die Nase vorn (zum Beispiel in Handbrake oder Bildbearbeitung in UL Procyon). Allerdings zieht Intels CPU in einigen Benchmarks mit durchgedrücktem Gaspedal vollkommen davon, so etwa in Render- und Verschlüsselungsaufgaben oder Matrizenberechnung.
Das ist ein simples Bash-Script, das sich von ein paar Zeilen über die Jahre auf 10000 Zeilen erweitert hat, also kein Konzept von Anfang an, sondern einfach dazu kodiert, was gewünscht wurde.
Es gibt bei den Metadaten extreme Tücken, die zu Datenverlust führen können, die man nicht gleich merken kann. Insofern verändere ich da so wenig als möglich.
Aber paralleles Speichern von verschiedenen Auflösung klingt schon interessant.
Gute Frage. Einerseits geht es um Videoberechnung mit mehreren Kernen bei der Wahl der CPU, da kann man einfach sagen, je mehr Kerne desto besser.
Andererseits geht es um Single-Core-Berechnungen. Ich wusste nicht, dass da die Unterschied relativ gering sind, also es ziemlich egal ist, was man nimmt.
Ich habe in die Diskussion einfach die Dinge eingebracht, die ich als Flaschenhals sehe. Natürlich will man mit einem PC verschiedenste Dinge machen, für vieles ist es ziemlich egal welche Hardware man hat.
Letztlich geht es um alle Dinge, die du zitiert hast. Wenn ich auf was warten muss, dann ist das anders zu bewerten als wenn es egal ist, wenn es über Nacht rechnet. Diese Single-Core-Fotoberechnungen will ich meistens schnell habe. Ein Video darf durchaus länger brauchen, mit diversen Filtern kann das durchaus 10h dauern.
Vergleiche selbst ob es Sinn macht. Ich habe mal folgendes spontan auf einem 7800x3D & 4080 Super sowie Ryzen 7 8845HS & Radeon 780M ausgeführt:
Code:
wget https://upload.wikimedia.org/wikipedia/commons/7/7d/%22_The_Calutron_Girls%22_Y-12_Oak_Ridge_1944_Large_Format_%2832093954911%29_%282%29.jpg -O in.jpg
export WIDTHS="900 1000 1100 1200 1400 1600 1800 2000 2200 2400"
export PAR=$(cat /proc/cpuinfo | grep processor | wc -l)
time parallel -j ${PAR} "darktable-cli in.jpg out_{}.jpg --width {}" ::: ${WIDTHS}
time for i in ${WIDTHS}; do darktable-cli in.jpg out_${i}.jpg --width ${i} ; done
Der erste Befehl schwankt zwischen 5s bis 6.5s. Der zweite hat real 1min und sys 1m25s. Die Werte sind bei beiden Systemen ähnlich. Parameter wie --disable-opencl funktionieren wohl alle in der aktuellen Version nicht.
Das ist mein Ergebnis, aber das ist eine ganz andere Baustelle.
Code:
$ darktable-cli setubal.orf setubal.orf.xmp setubal.jpg --core --disable-opencl -d perf
darktable 5.0.1
Copyright (C) 2012-2025 Johannes Hanika and other contributors.
Compile options:
Bit depth -> 64 bit
Debug -> DISABLED
SSE2 optimizations -> ENABLED
OpenMP -> ENABLED
OpenCL -> ENABLED
Lua -> ENABLED - API version 9.4.0
Colord -> ENABLED
gPhoto2 -> ENABLED
GMIC -> ENABLED - Compressed LUTs are supported
GraphicsMagick -> ENABLED
ImageMagick -> DISABLED
libavif -> DISABLED
libheif -> ENABLED
libjxl -> ENABLED
LibRaw -> ENABLED - Version 0.22.0-Devel202403
OpenJPEG -> ENABLED
OpenEXR -> ENABLED
WebP -> ENABLED
See https://www.darktable.org/resources/ for detailed documentation.
See https://github.com/darktable-org/darktable/issues/new/choose to report bugs.
1.9745 [dt_dev_load_raw] loading the image. took 0.668 secs (0.597 CPU)
2.0201 [export] creating pixelpipe took 0.042 secs (0.345 CPU)
2.0204 [dev_pixelpipe] took 0.000 secs (0.000 CPU) initing base buffer [export]
2.0351 [dev_pixelpipe] took 0.015 secs (0.104 CPU) [export] processed `rawprepare' on CPU, blended on CPU
2.0546 [dev_pixelpipe] took 0.019 secs (0.135 CPU) [export] processed `temperature' on CPU, blended on CPU
2.0938 [dev_pixelpipe] took 0.039 secs (0.489 CPU) [export] processed `highlights' on CPU, blended on CPU
2.1175 [dev_pixelpipe] took 0.024 secs (0.245 CPU) [export] processed `hotpixels' on CPU, blended on CPU
2.3223 [dev_pixelpipe] took 0.205 secs (2.681 CPU) [export] processed `demosaic' on CPU, blended on CPU
6.3658 [dev_pixelpipe] took 4.043 secs (48.543 CPU) [export] processed `denoiseprofile' on CPU, blended on CPU
7.3811 [dev_pixelpipe] took 1.015 secs (9.622 CPU) [export] processed `lens' on CPU, blended on CPU
7.5791 [dev_pixelpipe] took 0.198 secs (3.035 CPU) [export] processed `ashift' on CPU, blended on CPU
7.6412 [dev_pixelpipe] took 0.062 secs (0.852 CPU) [export] processed `exposure' on CPU, blended on CPU
7.6914 [dev_pixelpipe] took 0.049 secs (0.700 CPU) [export] processed `colorin' on CPU, blended on CPU
7.7374 [dt_ioppr_transform_image_colorspace] IOP_CS_LAB-->IOP_CS_RGB took 0.046 secs (0.649 CPU) [channelmixerrgb]
8.0459 [dev_pixelpipe] took 0.354 secs (5.167 CPU) [export] processed `channelmixerrgb' on CPU, blended on CPU
8.0932 [dt_ioppr_transform_image_colorspace] IOP_CS_RGB-->IOP_CS_LAB took 0.047 secs (0.673 CPU) [atrous]
10.6683 [dev_pixelpipe] took 2.622 secs (37.758 CPU) [export] processed `atrous' on CPU, blended on CPU
10.7127 [dt_ioppr_transform_image_colorspace] IOP_CS_LAB-->IOP_CS_RGB took 0.044 secs (0.633 CPU) [colorbalancergb]
11.9557 [dev_pixelpipe] took 1.287 secs (19.341 CPU) [export] processed `colorbalancergb' on CPU, blended on CPU
11.9994 [dev_pixelpipe] took 0.044 secs (0.600 CPU) [export] processed `rgblevels' on CPU, blended on CPU
12.4158 [dev_pixelpipe] took 0.416 secs (6.296 CPU) [export] processed `sigmoid' on CPU, blended on CPU
12.4646 [dt_ioppr_transform_image_colorspace] IOP_CS_RGB-->IOP_CS_LAB took 0.049 secs (0.712 CPU) [bilat]
13.9216 [dev_pixelpipe] took 1.506 secs (11.698 CPU) [export] processed `bilat' on CPU, blended on CPU
14.0145 [dev_pixelpipe] took 0.093 secs (1.308 CPU) [export] processed `colorout' on CPU, blended on CPU
14.0766 [resample_plain] took 0.062 secs (0.852 CPU) 1:1 copy/crop of 8065x6046 pixels
14.0767 [dev_pixelpipe] took 0.062 secs (0.853 CPU) [export] processed `finalscale' on CPU, blended on CPU
14.0767 [dev_process_export] pixel pipeline processing took 12.057 secs (149.438 CPU)
14.9090 [export_job] exported to `setubal.jpg'
Könntest du bitte dein Beispiel für convert anpassen?
Damit es kein Missverständnis gibt, ich habe eingangs 2 x265-Tests gepostet und 1 x264. Diese möchte ich vergleichen und zwar nicht mit irgendwelchen x265-Tests, sondern mit den vor mir genannten.
?!
ich auch wenn die ffmpeg Implementierung von x265 ohnehin ei gleicher ffmpeg version diegleicheist, habe ich dir doch den gleichen test wie von dir durchgefuehrt verlinkt?!
Ich habe aber auch noch "phoronix-test-suite benchmark system/x265" durchgeführt. Der Unterschied ist mir noch nicht klar. Wenn ich was zum Vergleichen habe, dann versuche ich den Unterschied zu verstehen.
Für mich wirkt das Problem hier wie eine fiese Mischung aus XY-Problem und dem Wunsch am Workflow absolut nichts zu ändern, außer per brute force mehr Leistung reinzuballern.
Man muss sich aus etlichen Posts stückchenweise zusammenreimen was genau der TE mit den Bildern eigentlich macht, die Frage warum das gemacht wird bleibt, soweit ich das sehe, weiterhin offen und damit ist ein Ansatz für eine moderne Lösung mit parallelisierter Verarbeitung der Bilder im Keim erstickt. Außer "Ja dann nimm halt die CPU mit dem höchsten Singlecore-Takt/IPC" ist hier eigentlich kein Rat möglich...
Das verstehst du falsch, wenn ich eine neue CPU kaufe und es würde da große Unterschiede bei SIngle-Core geben, dann würde ich die bessere nehmen, dem ist aber nicht so, also ist das kein Entscheidungskriterium mehr.
iSight2TheBlind schrieb:
Lösung mit parallelisierter Verarbeitung der Bilder
Ich verschließe mich ja nicht völlig, siehe oben beim Beispiel mit dem Export von 1 Datei in mehreren Auflösungen. Ich würde das gerne testen. Einschränkung sind aber die 6 gleiczeitigen Berechnungen, ich brauche mehr und die CPU hätte auch mehr Kerne.
Mehrere unterschiedliche Bilder gleichzeitig parallel rechnen wird scheitern, aber das zu erklären wird zu kompliziert. Der Haken liegt im Detail. Stichwort: mehrere gleiche Kameramodelle zur gleichen Uhrzeit mit Serienfotos eindeutig umbenennen, kommt selten vor, aber es muss immer passen. Die gleiche Datei hintereinander mehrmals nur "abzufragen" macht es sicher nicht schneller, müsste man aber, ich habe schon mehrmals erklärt, dass die folgende Datei bei den Variablen abhängig ist von der vorhergehenden. Also erst wenn "Zustand" A definiert ist, kann B berechnet werden und damit ist parallel ein Problem.
GraphicsMagick has been significantly updated to use multiple CPU cores to speed up the image processing, and work continues to thread the few remaining algorithms, or remove inefficiencies in algorithms which don't see as much speed-up as they should.
Ein Bild nach avif umzuwandeln kann auch viele Kerne auslasten, das Bild wird dazu in Zeilen (und Spalten) partitioniert. Das ist aber auch nötig, denn das dauert bei bester Qualität schon ziemlich lange. https://github.com/link-u/cavif
--threads
--enable-row-mt
Dieser Geschwindigkeitsvorteil klingt interessant.
Aber es gibt mehrere Leute, die haben mit Ryzen 9 7900X und RTX 3600(TI) schlechtere Werte als mein System.
Ryzen 7 3700X (meiner)
11.9 secs
4.7
Ryzen 9 7900
10.4 sec
5.1 sec
also ohne opencl / GPU bin ich 1,5sec pro Testfoto langsamer, mit opencl habe ich mit meinem alten PC um 0.4 sec. die Nase vorn.
GIbt es fast nicht, vielleicht ist der Unterschied Windows zu Linux? Einer der Teste meinte, dass er Win 11 verwendet.
1.4 vs 4.7 ist sicher interessant, aber 0.4sec Unterschied lohnt keinen neuen PC.
Berücksichtige ich, dass das ein aufwendiges Testfoto ist, dann dürfte ein normales Foto in 1sec zu rendern sein, das ist durchaus akzeptabel. Mein Script braucht da länger pro Foto, aber das war schon immer so.
