Import RAW-Dateien passend zu vorhandenen JPEGs

[kdww]

Werbung (verschwindet nach Registrierung)

vor 12 Minuten schrieb tgutgu:

Die Gefahr, dass auf der Festplatte irgendwann mal ein Wust von JPEGs liegen bleibt, sehe ich weitaus größer, als wenn ich meine Veröffentlichungen mit den Plugins verwalte.

Kein Problem, wenn man einen einzigen LR Export Ordner nimmt. 

Und eine Diashow ohne JPG auf der Festplatte geht halt nicht. 

Du exportiert JPG nach Smugmug, auch wenn du es als Veröffentlichung bezeichnest. 

Und bevor ich Bilder einzeln aus der Galerie über LR nehme, dann lösche lieber in meinem Tempordner die dort veröffentlichten Bilder in einem Rutsch, ohne mir Gedanken machen zu müssen, welches Bild ich da jetzt aus der Galerie nehmen muss. 

Du exportierst deine Bilder aus Smugmug für irgendwas, ich veröffentliche meine JPG aus LR in einen Ordner für irgendwas. 

Ist halt eine Philosophiefrage. 

Ich brauche kein Netz um da ein JPG zu erstellen, an die Galerie kommst du ohne Netz nicht ran, wenn du mal ein kleines JPG brauchst. Zudem gibst du vermutlich die Kontrolle über die Skalierung an Smugmug ab. 

Ich sehe da für mich keine Vorteile in dem Vorgehen. Aber vielleicht habe ich ja das Killerkriterium nicht erkannt. 

[tgutgu]

vor 14 Stunden schrieb kdww:

Ich brauche kein Netz um da ein JPG zu erstellen, an die Galerie kommst du ohne Netz nicht ran, wenn du mal ein kleines JPG brauchst. Zudem gibst du vermutlich die Kontrolle über die Skalierung an Smugmug ab.

Ich habe noch nie „kleine“ JPEGs benötigt. Ich sehe dafür für mich keine Erfordernis. In der Tat übernimmt SmugMug die Skalierung, wenn ich über einen Link die Größe beschränke. Wer aber in meine Online Galerie geht, kann die Bilder immer in voller Auflösung genießen. (Ich selbst natürlich auch).

Lightroom selbst hat eine Diaschau Funktion, die keine JPEG benötigt.

Allerdings bau ich meine Shows mit Wings X und muss hierfür in der Tat für die ausgewählten Bilder lokal JPEGs erstellen, aber auch nur für diese. Ich schrieb ja, wenn es für einen  Arbeitsablauf unabdingbar ist.

Aber wir haben vermutlich eines gemeinsam: Wir sehen JPEG nicht als Bildformat an, das ich a priori für jedes Bild vorhalte, sondern das nur im Bedarfsfalle und idealerweise auch nur temporär.

Jedenfalls keine Arbeitsweise wie sie der Threaderöffner im Sinn hat.

bearbeitet 7. Juni 2023 von tgutgu

[wasabi65]

vor 9 Stunden schrieb kdww:

Ist halt eine Philosophiefrage. 

Deswegen bringt es wenig hier scheinbar rationelle Argumente aneinanderzureihen (gilt auch für mich).

😇

[kdww]

vor 8 Stunden schrieb tgutgu:

Jedenfalls keine Arbeitsweise wie sie der Threaderöffner im Sinn hat.

Ja, so ist es.

vor 8 Stunden schrieb tgutgu:

Aber wir haben vermutlich eines gemeinsam: Wir sehen JPEG nicht als Bildformat an, das ich a priori für jeden Bild vorhalte, sondern das nur im Bedarfsfalle und idealerweise auch nur temporär.

Nur sind unsere Wege verschieden. Kommt aber am Ende auf das gleíche raus

[RoDo]

Am 1.6.2023 um 22:07 schrieb DSLRUser:

Das ist nicht ganz richtig.

Für Windows 10/11 gibt es Extension, die sich LibRAW bedient.

Und als Viewer - Fast RAW Viewer ist einer der RAW anzeigt und nicht das JPEG daraus.  Und dazu superschnell.

Hatte vor Jahren mich mal über LibRaw informiert und einen Download vorgenommen. Habe das erneuert und es hat sich nichts geändert. Es ist eine Programmbibliothek, die man beim Schreiben eigener Programme in c++ benutzen kann, um RAW-Files zu lesen. Sehe aber (bisher) vom Schreiben eigener Programme ab.

Extensions für den Windows-Explorer sehe ich durch LibRaw nicht. Gehe ich also mit dem Explorer in Verzeichnisse mit RAW-Dateien und schalte die Kacheldarstellung ein, dann werden mir die embedded JPGs angezeigt. Das gilt auch für Viewer-Applikationen wie z. B. Irfanview  mit der T-Option. Das Auslösen der JPGs aus den RAW-Files wird von einem Windows-Codec vorgenommen, der z. B. früher keine RW2-Files verarbeiten konnte. Erst als ich mal aus welchem Grund auch immer mit Windows Fotos mal einen aufmachen wollte, wurde mir gesagt, dass ein Codec nachgeladen werden muss. Das habe ich zugelassen und seit dem werden die Inhalte aus den embedded JPGs angezeigt.

Die Fast Viewer Webseite habe ich mal angeguckt und sehe in der Verwendung keinen Vorteil. Denn auch dieser wird in der Übersicht die embedded JPGs anzeigen, erlaubt mir aber, einzelne Files zu öffnen, wobei dann wahrscheinlich ein echtes Demosaicing abläuft und irgendwelche Steuerwerte dabei ansetzt, die ein normales Bild erzeugen und anzeigen. Als BMP. Das mag ja schneller gehen als beim Öffnen der Datei in einem RAW-Bearbeitungsprogramm. Aber was sehe ich mehr im vom Fast Viewer angezeigten Bild als im embedded JPG, in dem z. B. die Objektiv-Verzeichnungen schon neutralisiert sind?

Anders ist das in den Dateiverwaltungen der RAW-Verabeitungsprogramme. Vom ausgearbeiteten Bild wird on the fly eine kleine Kachelansicht erzeugt, die irgendwo abgelegt wird und in der Dateiverwaltung an Stelle des embedded JPGs angezeigt wird. Da kann man dann den Stand des ausgearbeiteten Bild sehen.

Und selbst bei JPGs kann man beim Abspeichern angeben, ob eine kleine Preview-Version mit abgelegt wird, auf die sich dann Explorer und Co. stürzen können, um Zeit zu gewinnen.

[DSLRUser]

ist zwar in vielen Punkten meiner Meinung nach anders, aber ich möchte es nicht weiter diskutieren.