martin0reg:
Drucken wurde schon öfter angesprochen, aber diesbezüglich ist nichts in Planung. Es gibt ja auch eine Menge Applikationen die das ganz gut machen, z.B. der Windows-Assistent. Der Aufwand wäre überdies nicht ganz unerheblich, insbesondere wenn Farbverwaltung mit ins Spiel kommt. Dann will man auch schnell Softproof etc....
Wie druckst du denn momentan deine Bilder und was gäbe es dabei zu verbessern?
Zitat von "bertram"Es ist so, dass bisher überprüft wird, ob der Name der jif-Datei den Namen des Originals enthält.
Das heißt, mit der Art der Zeichen hat es nichts zu tun, sondern ob der Dateiname in der jif-Datei vorhanden ist. Im obigen Beispiel würde ein Bild mit dem Dateinamen 9.jpg von den Einstellungen der jif unberührt bleiben.
Es war euch also bekannt und die Spielerei hätte ich mir sparen können 
Es hat trotzdem Spaß gemacht... 
Merci trotzdem ...
Zitat von "Equinox"Beispiel: wenn ich bei dem Bild "12345678.jpg" eine Filterdatei speichere, wird die Einstellung allen Bildern, deren Name nur aus Zahlen besteht, zugewiesen, egal wie lang und wie zusammengesetzt; also auch dem 1.jpg, 538.jpg usw. usf.
Also mir war das mit den Zahlen nicht bekannt. Ich dachte bisher, dass die jif-Dateien einfach mit dem Namen des JPG beginnen müssen, was bei Zahlen aber nicht notwendig zu sein scheint. So hatte ich auch Bertram verstanden:
Zitat von "bertram"Es ist so, dass bisher überprüft wird, ob der Name der jif-Datei den Namen des Originals enthält.
Aber wie auch immer, es gibt bereits einen Bugfix, er muss nur noch die Qualitätssicherung passieren ... 
Zitat von "Equinox"die Spielerei hätte ich mir sparen können
Merci trotzdem ...
Tut mir leid. 
ZitatBeispiel: wenn ich bei dem Bild "12345678.jpg" eine Filterdatei speichere, wird die Einstellung allen Bildern, deren Name nur aus Zahlen besteht, zugewiesen, egal wie lang und wie zusammengesetzt; also auch dem 1.jpg, 538.jpg usw. usf.
Es ist so:
Beim Speichern wird nach bestimmten Regeln der Name der jif-Datei generiert. Ein Bestandteil dieses Namens ist der Name des Originals. Die jif-Datei enthält die aktuellen Einstellungen der Bearbeitung. Diese Einstellungen werden aber keiner anderen Datei zugewiesen.
Wenn man das gleiche Original wieder öffnet, dann wird der Ordner auf einfachste Art durchsucht nach jif-Dateien, deren Name den Namen des Originals enthält. Diese jif-Dateiliste wird dann zur Auswahl in einem Dialog angeboten. Das wäre jetzt noch nicht besonders schlimm, wenn nicht auch beim Umbenennen eines Originals dieselbe fehlerhafte Liste benutzt würde, weil dann eventuell jif-Dateien, die zu anderen Originalen gehören, umbenannt werden.
Wie von Franz gesagt: der Bugfix kommt in Kürze.
Zitat von "Franz"..
Wie druckst du denn momentan deine Bilder und was gäbe es dabei zu verbessern?
ich drucke mit canon ip4500 und epson r285/p50, befüllt mit guter fremdtinte (image specialists) und bin oft im druckerforum von nifty-stuff http://www.nifty-stuff.com/forum/index.php , da findet sich viel knowhow für selbstbefüller und fotodrucker.
Fotos verwalten und ausdrucken tu ich mit thumbsplus.
Mein vorschlag kommt daher, weil ich kein gutes (oder überhaupt kein) freeware programm zum drucken mit farbmanagement kenne, das ist eine echte lücke. Und Adobe monsterprogramme vermeide ich ja mit dem illuminator.
Du hast recht, interessant wärs erst mit druckvorschau als softproof und das wäre wohl ein eigenes neues modul oder zusatzprogramm zum illuminator..wäre sicher mit großem aufwand verbunden..aber es gibt da halt nix gutes kleines..
Meine Meinung zum Illuminator allgemein: Bitte bloß nicht "überverfeinern", also die ohnehin gewöhnungsbedürftige oberfläche mit funktionen versehen, die sich nur für gut eingearbeitete user "intuitiv anfühlen", für neueinsteiger aber erstmal unverständlich sein können.
Ich weiß noch wie ich vor jahren als neuinsteiger wochen brauchte, bis ich gemerkt habe, dass ein klick auch einen wert diesen zurücksetzt...
Equinox:
Die Version 4.3.11 ist online.
Wir haben das Problem der fehlerhaften Liste von jif-Dateien behoben. Es sollte jetzt nicht mehr vorkommen, dass man beim Öffnen eines Originals in der jif-Dateiliste Dateien findet, die nicht zu diesem Original gehören.
Alte Fehler werden dadurch aber nicht rückgängig gemacht. Speziell in dem Fall, dass man mit "Datei/Original umbenennen" ein Original und mit ihm die zugehörigen jif-Dateien umbenannt hat, können auch falsche jif-Dateien mit umbenannt worden sein.
Danke für das Aufdecken des Fehlers!
Hallo zusammen,
ich möchte nochmal auf den mehrfach geäußerten Wunsch nach der Vorgabe einer bestimmten Dateigröße in KB zurück kommen. Im Prinzip gibt es ein hervorragendes Freeware-Tool, das diese Funktionalität zur Verfügung stellt, den JpgCompressor. JpgCompressor legt eine temporäre Datei an, die dann iterativ überschrieben wird bis die Maximalgröße unterschritten ist. Das geht recht schnell durch geeignete Wahl der Iterationsschritte und liefert durch einstellbare Nachschärfung eine hervorragende Bildqualität. Das Problem ist aber, dass dieses Progrämmchen nicht mehr ganz zeitgemäß ist und sich insbesondere mit Windows 7 dahingehend beißt, dass es ins Programmverzeichnis schreibt und auch, dass die Temporärdatei mit manchen Virenscannern auf Kriegsfuß steht weil sie nicht den Windowskonventionen für Temporärdateien bezüglich Namensgebung und Speicherort folgt. Der Autor (Boris Nienke) ist mittlerweile auf Apple-Computer umgestiegen und kann keine Programmänderung mehr durchführen. Er ist aber prinzipiell bereit, sein Baby in vertrauensvolle Hände zu geben. Er antwortete mir auf die Anfrage, ob er seinen Code als Open-Source zur Verfügung stellen würde wie folgt:
ZitatSollte sich jemand bei mir melden, der mir vertrauenswürdig erklären kann, wie man aus JPC ein OpenSource-Projekt machen kann ohne Probleme zu erwarten, dann werde ich das ernsthaft in Betracht ziehen und mir die Mühe machen, den Quellcode noch mal hervor zu kramen
JpgCompressor könnte als eigenständiges Modul betrieben werden aber gleichzeitig über öffentliche Schnittstellen mit JpgIlluminator kommunizieren.
Somit wäre beiden Seiten geholfen.
jpg-Illuminator und Bildgrößen-Informationen.
Auf der Suche nach dem besten Weg zur Bearbeitung von Bildern direkt nach dem Einscannen bin ich auf folgendes Manko gestoßen:
Ich scanne ein Bild 150 x 100 mm mit 300 dpi in IrfanView ein. Die Bildinformation von Irfanview zeigt mir dann auch diese Daten an. Kopiere ich nun dieses Bild nach jI und wieder zurück, so fehlt in der Bildinformation die Aufösung, sodass eine falsche Bildgröße angezeigt wird.
Speichere ich das unter IrfanView eingescannte Bild ab, so ist auch nach erneutem Aufruf die ursprüngliche Bildinformation vorhanden. Rufe ich aber dieses Bild unter jI auf und kopiere es nach IrfanView, so fehlt jetzt wieder die Auflösung.
IrfanView kann ich durch PicturePublisher ersetzen - es bleibt das gleiche Ergebnis. Dieses ist um so negativer, als dass zum Drucken der eingescannten Bilder in Originalgröße die wichtige Informatin "Auflösung dpi" fehlt, wobei IrfanView 0 dpi annimmt, PicturePublisher ersatzweise 75 dpi.
Es wäre wünschenswert, wenn jpg-Illuminator den vorgegebenen Wert der Auflösung beim Kopieren über die Zwischenablage übernehmen würde.
pixelfan:
Das Problem mit der dpi-Zahl hatten wir doch vor längerer Zeit schon, und ich dachte, es sei behoben. (??) Die dpi-Zahl steht im Datei-Header und ging früher beim Speichern in ji verloren.
Weil du von "kopieren" sprichst: beim Kopieren über die Zwischenablage wird nur die Bitmap übertragen, keine Exifs oder andere Metadaten, auch nicht der Dateiheader. Kann es sein, dass hier dein Problem liegt?
Wenn du das Original-JPEG in ji öffnest, das Bild über die Zwischenablage in ein anderes Programm nimmst, kannst du anschließend in ji das Bild über die Zwischenablage mit "Einfügen, aber Metadaten erhalten" wieder zurückholen. Dann sollten Exifs, Metadaten und Header erhalten werden.
softride:
Auch wir haben uns bisher überhaupt nicht mit OpenSource befasst. Und werden das in naher Zukunft auch nicht planen. Das und eine geeignete Schnittstelle sind vermutlich viel Zeitaufwand für uns.
Zitat von "bertram"
Weil du von "kopieren" sprichst: beim Kopieren über die Zwischenablage wird nur die Bitmap übertragen, keine Exifs oder andere Metadaten, auch nicht der Dateiheader. Kann es sein, dass hier dein Problem liegt?
Ja, ich spreche vom Kopieren über die Zwischenablage und habe gerade noch einmal überprüft: In IrfanView mit 150 dpi eingescannt und über "Bearbeiten - Kopieren" nach PicturePublisher über "Bearbeiten - In neues Bild einfügen" übertragen. Die Bildeigenschften in PicturePublisher liefern nun 150 dpi. Anschließend das Gleiche mit einem 300-dpi-Scanbild: In PicturePublisher erscheint es mit 300-dpi-Auflösung. Das Gleiche in umgekehter Reihenfolge durchgeführt liefert das gleiche Ergebnis.
Dieses zeigt, dass über die Zwischenablage doch mehr als nur Pixel übertragen werden. Oder wie kommen die unterschiedlichen Werte für die Auflösung zustande?
Gute Frage. Natürlich kann jeder Programmierer entscheiden, was bei Strg-C und bei Strg-V passiert. Unsere bisherige Überlegung war: Wir benutzen die Zwischenablage für verlustlosen Austausch der Pixel. Es wird also bei Strg-C die Bitmap in die Zwischenablage kopiert, nicht die komprimierte jpg-Datei mit allen Metadaten. Bei Strg-V wird eine Bitmap aus der Zwischenablage geholt (falls vorhanden), und daraus ein neues Bild mit leeren Exifs ... erstellt. Bei Strg-Einfg wird eine Bitmap aus der Zwischenablage geholt (falls vorhanden) und den aktuellen Exifs des bisherigen Bilds zugeordnet.
Kann sein, dass der Publisher das komprimierte jpg in die Zwischenablage kopiert. (?)
Nein, denn der Vorgang funktioniert ja auch ohne dass eine gespeicherte Datei vorhanden ist, z. B. nach dem Scannen oder nach dem Kopieren über die Zwischenablage und auch wieder zurück, auch in ein neu geladenes Bild-Programm. Dieses geht sowohl bei PicturePublisher als auch IrfanView Und wie ich soeben geprüft habe, wird beim Kopieren von Microsoft Paint nach den beiden genannten Programmen ebenfalls die Auflösung übertragen. Der Übertrag bezieht sich aber offensichtlich in allen Fällen nur auf die Auflösung, nicht auf EXIF-Daten - sofern solche überhaupt vorhanden sind.
Heute Abend werde ich mich näher damit befassen.
Hallo,
mir ist auch ein kleiner Bug aufgefallen.
Ich arbeite öfters mit dem Kontrast, da aber nur bereichsweise. Ich habe letztens eine Serie Bilder bearbeitet, wo ich nur noch den Zuschnitt machen musste. Ansonsten konnte ich die Filter des letzten gespeicherten Bildes verwenden. Bei manchen Bilder habe ich aber auf Grund der unterschiedlichen hellen und dunklen Anteile im Bild den Bereich des Kontrasts etwas ändern müssen.
Die Einstellungen waren Kontrast +1, Bereich variabel, Breite 30.
Wenn ich an eins der oben genannten Bilder gekommen bin habe ich den Bereichsregler mit der Maus verschoben. Dabei wurde der Bereich (blauer Bereich) "zerrissen" - so lange wie ich die Maustaste gedrückt hielt. Habe ich aber vorher nur kurz auf die Breite geklickt, ohne diese zu verändern, konnte ich den Bereich ganz normal verschieben.
Ich hoffe, ich habe alles ausreichend geschildert und ihr könnt das Problem lösen. Wenn es noch Fragen dazu geben sollte, könnt ihr euch gern melden.
MfG aus dem frostigen, fernen Osten
Carsten
@Carsten:
Danke. Verstanden hab ich's. Mal sehen, ob ich die Ursache finde.
pixelfan:
Die Zwischenablage sperrt sich noch unseren Versuchen, die dpi-Zahl zu lesen und zu schreiben. Das analoge Problem beim Lesen und Schreiben einer bmp- bzw. jpg-Datei konnten wir vor langer Zeit schon lösen.
Die Version 4.3.12 ist online.
unscharf: den Bug in der Histogramm-Anzeige haben wir beseitigt.
softride, Gottlieb, HoSt:
Nachdem wir von euch so sanft, beharrlich und nett an das Thema herangeführt wurden, haben wir uns tatsächlich daran gemacht, das Speichern mit Begrenzung der Dateigröße zu realisieren.
ZitatBertram: Heute Abend werde ich mich näher damit befassen.
Aus dem Abend sind mehrere Abende geworden, aber wir haben es in den Griff bekommen: Die dpi-Zahl im Header geht über die Zwischenablage nicht mehr verloren.
Na, das war ja wie der Siebte Sinn: Gerade wollte ich nachfragen ob es eine Lösung geben wird, und da ist sie schon präsent.
Auch das Übertragen der Auflösung in andere Programme funktioniert, selbst wenn man unter "Bildgröße" die dpi-Werte für eine cm-Angabe ändert.
Aber leider gibt es noch ein Problem, das vielleicht dadurch aufetreten ist, dass ich in JI die Auflösung verändert habe? Nunmehr ändern sich die dpi-Werte nicht mehr, wenn ich ein Bild beliebiger Auflösung einfüge. Beim anschließenden Kopieren in ein anders Programm stimmt die Auflösung allerdings, trotz der falschen Werte in JI.
Der anschließende Test mit dem Laden eines bestehenden Bildes verlief auch negativ, da die Auflösung nicht auf ein anderes Programm übertragen wurde.
Danke fürs Testen! Ich muss gestehen: an die dpi-Eingabe beim Ändern der Bildgröße hatte ich gar nicht mehr gedacht, weil ich das selber nie benutze.
Die Auflösung sollte auch beim Laden eines Bildes übernommen werden.
Da JI damit in allen Fällen die Bildauflösung kennt, wäre vielleicht eine Umgestaltung der dpi-Anzeige angebracht:
1. Zusätzlich wird die Bidgröße in cm angezeigt. Dann kann man durch Ändern des dpi-Wertes sofort die geänderten Abmessungen ersehen.
2. Wenn im Bild bzw. der Zwischenablage kein dpi-Wert enthalten ist, wird dieser mit 72 angenommen.
