Beiträge von pixelfan

So wird es sein. Bei ji wird bei 100% Kompressionsqualität offensichtlich stärken komprimiert als bei Picture Publisher mit Komprimierungsfaktor 1, bei dem die geschilderten Effekte nicht auffällig waren. Hier hat die vierte Reihe lediglich für den RGB-Wert 0/0/1.

Ich habe bei einem schwarzen Bild von 3000 x 1688 Pixeln einen inneren Rahmen mit 0,1% = 3 Pixeln gelegt und in Kompressionsqualität 100% gespeichert. Alle folgenden Eingabezeilen stehen auf 0%.

Wenn ich mir nun dieses neue Bild in einem anderen Bildprogramm ansehe, dann hat der Rahmen eine Breite von 4 Pixeln:
2 äußere Reihen im ausgewählten Farbton R255/G134/B67
1 innere Reihe mit R208/G149/115
1 weitere innere Reihe mit R48/G0/B0.

Ist das so gewollt oder ist das ein Bug?

Zitat von "Franz"

Vielleicht schärft der Bildschirm zuerst nach und verkleinert das Bild dann anschließend. Oder die Darstellung ist gar nicht genau 1:1. Du könntest mal eine feine dünne Linie um das skalierte Bild machen und schauen, ob diese an allen Seiten sichtbar ist.

Ich habe das Bild in ji mit dem schmalsten inneren Rahmen versehen und dann auf 1920 x 1080 Pixel verkleinert. Dann hat es einen 2 Pixel breiten Rahmen. Der TV (Samsung UE46C8790) stellt es pixelgenau dar, aber in der Qaualität eben schlechter als das unskalierete Original. Es ist offensichtlich eindeutig besser, das Skalieren dem Ausgabegerät, in diesem Fall dem TV, zu überlassen. Es entfällt zumindest der JPG-Komprimierungsvorgang beim Speichern von ji.

2 Fragen zum Rahmen:

1. Kann man auch eine Eingabe in Pixeln machen?
2. Was bedeutet "als Vorgabe"?

Für die Antwort schon einmal danke.

Zitat von "RitterRunkel"

Ich hab lange Zeit immer passend für das jeweilige Format dann die Pixelmaße meiner Photos angepaßt, also meist verkleinert auf das perfekte (?) Maß. Und zumindest für diese Maschinen hatte ich den Eindruck, das wäre passender und es sähe ein My weniger gut aus, wenn man die Bilder größer (so groß wie sie vorliegen) hinschickt und die Maschinen dann auf das Format@400dpi verkleinern läßt ... Aber das war eher so ne Einschätzung, nichts Exaktes.

Ich habe das mal formatrichtige Skalieren für den LCD-TV ausprobiert. Ein Bild mit 3456 x 1944 Pixeln (16:9) skaliert auf 1920 x 1080. Auf dem TV sah das Originalbild (wegen der Chancengleichheit mit ji noch einmal gespeichert) wesentlich besser aus als das skalierte, egal ob mit ji oder IrfanView bei 100% Qualität gespeichert. Bei den skalierten Bildern zeigten sich an den Kanten von starken Kontrastsprüngen helle Säume. Der TV kann also besser (herunter)skalieren. Vielleicht hängt das damit zusammen, dass beim TV die JPG-Komprimierung entfällt. Das gilt dann natürlich für jede Art von Ausgabegerät.

Zitat von "bertram"

Nach einiger Recherche muss ich meine sehr grundsätzlichen Aussagen von oben relativieren: ...

... Und damit wären wir wieder bei meinem Vorschlag: Wenn cm-Skalierung, dann in einer DPI-Auflösung, die die ursprünglichen Pixelwerte beibehält. Dann liefert ein Ausgabeprogramm, das den Header ausliest, die in ji vorgegebene Bildgröße, so wie ich es schon erwähnte. Sollte der Header nicht ausgelesen werden, dann geht es eben nur wie bisher.

Übrigens: Mit IrvanView lassen sich derartig erstellte Dateien im Stapelmodus in der in ji vorgegebenen Bildgröße ausdrucken!

Zitat von "bertram"

Hallo Pixelfan,
danke für deine Mühe!
Natürlich können wir den Wertebereich des dpi-Eingabefelds erweitern. Aber ausgrauen? Das bedeutet normalerweise, dass keine Eingabe vorgenommen werden kann.

Das soll ja nur für den Fall gelten, dass eine cm-Eingabe erfolgen und durch ji das Errechnen der DPI ohne Veränderung der Pixelgröße vorgenommen werden soll.

Zitat

Ich bin aber nicht ganz sicher, ob dein Ansatzpunkt sachgerecht ist, und zwar aus folgender Überlegung:
Ich kenne kein Ausgabegerät, das ein Bild mit 675dpi ausgeben kann und erst recht nicht mit 675,25dpi (oder weiß ich da zu wenig?). Das würde bedeuten, dass der Treiber stattdessen vielleicht 600dpi benutzt und das Bild entsprechend skaliert, damit es die richtige Ausgabegröße bekommt. Aber das genau wolltest du ja vermeiden.

Die 675 dpi, die im Header einer Bilddatei stehen müssten, sind nur eine rechnerische Größe. Teilt man die Pixelgröße des Bildes durch diesen Wert, erhält man die dazu gehörende Ausgabegröße. Das Bildprogramm liest diesen DPI-Wert aus und errechnet aus ihm und der Pixelzahl des Bildes die Abmessungen des Druckes, im Beispiel zu 13 x 7,31 cm.
Würde das originale Kamerabild im Bildprogramm geöffnet, so würde nichts anderes geschehen, nur stände im Header 72 dpi. Dieses ergäbe eine Ausgabegröße von 121,92 x 68,58 cm. Da das nicht die gewünschte Größe ist, muss man im Drucken-Dialog eine entsprechende Änderung vornehmen, bei der ji-Datei stünde bereits ohne manuellen Eingriff die gewünschte Ausgabegröße. In beiden Fällen ist das Pixelpaket gleich groß, nämlich 3456 x 1944!), und die Vorgabe des Druckbereichs mit 13 x 7,31 cm ebenso. Damit hat der Drucker in beiden Fällen das Gleiche zu verarbeiten.

Zitat

Deswegen würde ich so vorgehen: man informiert sich zuerst darüber, mit welcher Auflösung in dpi das Ausgabegerät arbeiten kann, stellt diese dpi-Zahl ein, wählt die gewünschte Bildgröße in cm und skaliert das Bild auf die dafür nötige Pixelzahl. Dann kann man es nach Wunsch schärfen und dem Ausgabegerät übergeben. So hat man die Schärfe unter Kontrolle.

Bei einem Laserdrucker mag man die Auflösung ja noch kennen, aber bei einem Tintenstrahldrucker mit seinen verschiedenen Druckqualitäten und Papiersorten weiss man das nicht. Auch wäre das Verfahren sehr umständlich. Einfacher wäre es, wenn es in ji auch eine Druckausgabe geben würde.

Egal, ob ich in ji 4.3.3.2 mit 600 dpi für 13 cm oder 300 dpi für 13 cm skaliere, IrfanView oder auch Corel Paintshop Pro X zeigen mir als Größe nicht 13 cm, sondern 108,3 bzw. 54,2 cm an. Und zwar allein aus der Tatsache, dass in den Exif-Daten beider Dateien für die Auflösung 72 dpi steht und nur die Pixelgröße unterschiedlich ist. Es fehlt eben der DPI-Headereintrag für eine korrekte Größenangabe

Mit welchem Programm würdest du drucken?

Hallo RitterRunkel,
da ji nunmal eine Bildgrößenänderung auf cm-Basis ermöglicht, aber weder in ji selbst noch in dem zur Druckausgabe benutzten Bildprogramm die Ausgabegröße weder ersichtlich ist noch sich auswirkt, habe ich mich gefragt, wozu diese Möglichkeit dienen soll. Imgrunde wird nichts anderes getan, als die Pixelzahlen heruntergerechnet, was auf 2 andere Weisen ebenso möglich ist. Darum sollte ji den bei der Größenänderung benutzten DPI-Wert in den Header schreiben. Dann hat man bei der Druckausgabe bei 100% Maßstab/Skalierung die in ji gewählte cm-Größe.

Nach meinem Vorschlag ist eine Umrechnung der Pixelzahlen sogar vermeidbar, indem ji bei der Bildgrößenänderung einen DPI-Wert wählt, der eine Pixelgrößenveränderung vermeidet. Dann ist die Datei in der Quallität nicht reduziert, sodass man bei der Druckausgabe ggfs.auch eine Druckgröße wählen kann, wie sie mit der Originaldatei möglich wäre. Das eigentliche Umrechnen macht in jedem Fall der Druckertreiber.

Zitat von "RitterRunkel"

Äh, wie kommst Du immer auf "Pixel"?

Hallo RitterRunkel, nur nicht so aufgeregt! Natürlich ergibt Pixel geteilt durch Zoll als Ergebnis Pixel/Zoll. Das wars dann aber schon. Aber danke für den Hinweis.

Alle weitern Zusammenhänge kannst du in IrfanView schön in den Dialogen "Größe ändern" und "Drucken" erkennen.

Zitat von "Franz"

Da finde ich unsere Lösung aber übersichtlicher.

Ich weiß nicht genau, was du damit meinst. Aber ich habe mal darüber nachgedacht.

Wenn ich die Bildqualität der Datei nicht verschlechtern will, dann muss ich dafür sorgen, dass die Pixelanzahl beim Verändern der Bildgröße erhalten bleibt. Würde sich die Pixelanzahl verändern, würden die Informationen der einzelnen Pixel auf andere mehr oder weniger stark verteilt und bei Pixelverringerung die Schärfe verringert. Das bedeutet, je kleiner das Bild sein soll, um so größer muss der Pixelwert werden.

Ein Beispiel:
Kamerabild 3456 x 1944 Pixel, x/y-Auflösung 72 dpi. Das ergibt eine Bildgröße von 48 x 27 Zoll = 121,92 x 68,58 cm.

Soll die längste Seite 13 cm werden und die Pixelanzahl erhalten bleiben, so wird die x/y-Auflösung = (3456/130) * 25,4 = 675,25 Pixel/Zoll. Dieser Wert muss gerundet werden, in diesem Fall also auf 675 Pixel/Zoll, was eine geringfügige Anderung des Seitenlänge 13 cm bedeuten würde. Den Wert 675 als dpi kann man z.Zt. in ji leider nicht einstellen, es wäre also eine Bereichserweiterung erforderlich. Wenn dieses der Fall wäre, bräuchte am Bild nichts herumgerechnet werden, sondern nur im Header der DPI-Eintrag auf 675 gesetzt werden.

Und woher kommt man eigentlich ohne zu rechenen oder probieren auf den Wert 675? Ganz einfach: ji errechnet ihn selbst, wenn man eine cm-Größe wählt! Und falls man selbst die Entscheidung treffen will, dann kann man diese ji-Aktivität deaktivieren (und natürlich auch wieder aktivieren). Auch hier wieder: Bei Aktivieren der automatischen Pixeleinstellung Ausgrauen des Pixelfeldes. Wäre das keine Lösung?

Zitat von "bertram"

Wenn wir also den Header-Eintrag überschreiben, ergeben sich einige Fragen:
Soll der Eintrag generell überschrieben werden oder nur, wenn das Bild skaliert wurde?

Den Eintrag generell zu überschreiben, erscheint mir nicht sinnvoll, denn wer soll sagen, welcher Wert besser ist als der der Kamera oder, bei fehlendem Vorgabwert, der des jeweiligen Bildprogramms? Wenn jedoch der Anwender eine bestimmte Bildgröße festgelegt hat, dann muss ein vorhandener Wert überschrieben werden.

Zitat von "bertram"

Wenn generell: mit welchem Vorgabewert?
Soll beim Skalieren eine Wahlmöglichkeit gegeben sein, ob der dpi-Eintrag erfolgt?

Wenn der Anwender sich für eine Bildgröße in cm entschieden hat, dann ist diese ja für den Einsatz in einer externen Verwendung gedacht. Wenn er dieses nicht braucht, dann wählt er keine cm-Größe - Damit nutzt der Anwender schon die Wahlmöglichkeit. Eine weitere ist also nicht erforderlich.

Zitat von "bertram"

Soll das gewünschte Verhalten bei den Optionen einstellbar sein?

Auch hier gilt ebenfalls das zuvor Geschriebene. Darum gibt es keine Notwendigkeit für eine einstellbare Option. Im übrigen kann der übertragene Header-Wert jederzeit im externen Programm abgewandelt werden, so wie es ja auch bei originalen Kamerabildern möglich und sogar notwendig ist.

Hallo Franz und Bertram, vielen Dank für eure Antworten.

Zitat von "Franz"

IrfanView scheint die im JPG-Header eingebettete DPI-Zahl zu nehmen (diese kann von den Exif-Daten abweichen ). Falls die DPI-Angabe nicht vorhanden ist, verwendet IrfanView anscheinend die Windows-Standard-Bildschirmauflösung 96 dpi.

IrfanView verwendet im Falle eines fehlenden Header-Eintrages 72 dpi, ebenso wie Corel Paint Shop Pro. 96 dpi sind es bei Windows Photoanzeige und Paint, 75 dpi bei Picture Publisher. Sind bei Corel Paint Shop Pro keine Exif-Daten vorhanden, dann sind es jedoch 200 dpi.

Zitat von "bertram"

Dass ein anderes Programm in cm eine andere Länge angibt, liegt vermutlich daran, dass es nicht weiß, dass du 300dpi haben wolltest. Im Dateiheader wird von den Kameras eine dpi-Zahl eingetragen, die aber in der Regel nicht von Belang ist. Vielleicht orientiert sich IrfanView daran?

Der dpi-Eintrag ist aber insofern von Belang, als dass er die Größe des Bildes beim Ausdruck bestimmt. Hätte im Header 300 pdi gestanden, dann hätte in der Dateiinfo von Irfanview in den Feldern "Auflösung" 300 dpi gestanden und als Druckgöße 13 cm. Da die Felder jedoch leer blieben, wurde für die Druckgröße 54,2 cm angegeben.

Im vorliegenden Fall handelte es sich um die Kopie eines Bildes aus einem Video, dass ich nach Beschnitt für die Druckausgabe in IrfanView(ji kann so etwas leider noch nicht) gleich auf die Druckgröße einstellen wollte.

Zitat von "bertram"

Vielleicht sollten wir die dpi-Zahl im Header eintragen, wenn eine cm-Eingabe erfolgt, damit niemand unnötig verwirrt wird?

Das ist sogar notwendig, damit sich die Bildgröße auch in andern Programmen (siehe z.B. IrfanView oder auch Corel Paint Shop Pro) auswirkt. Auch wenn es bereits, wie bei den Kamerabildern, einen Eintrag gibt, muss dieser übschrieben werden.

Vewirrend war für mich die Zeile "(für cm-Eingabe) dpi 300".
Offensichtlich ist sie nur bei cm-Eingabe aktiv. Daher wäre es besser, wenn das Eingbefenster in allen anderen Fällen ausgegraut wäre.

Un falls ihr etwas ändern solltet: Vor "(für cm-Eingabe)..." sollte eine Leerzeile sein, damit es nicht so aussieht, als sei "(für cm-Eingabe)..." die Fortsetzung der darüberliegenden Zeile.

ji 4.3.3.2

Mit "Bild verkleinern oder vergrößern" habe ich Probleme.

Hier steht "(für cm-Eingabe) dpi 300".

Was bedeutet dieses?

Im konkreten Fall steht "lange Seite 460". Ist das cm, mm , dpi?

Ich möchte 130 mm Seitenlänge und habe aus dem Menü 13cm ausgewählt. Das Ergebnis ist laut IrfanView 1535 x 1535 Pixel / 54,2 x 54,2 cm. Diese Wete kann ich in keiner Weise nachvollziehen.

Was ist/mache ich falsch?

Zitat von "bertram"

Bei Verwendung der Zwischenablage können keine Exifs übergeben werden. Frage an Pixelfan: klappt das mit deiner Methode über das Mail-Programm?

Es ist der gleiche Drag&Drop-Vorgang wie beim Erhalt eines eMails: Im Bild sind alle Exifdaten enthalten.

Zitat

Erstaunlich, dass du noch alle hast!
Um die Version 4.1 haben wir uns von dem Zusatzprogramm Exiftool verabschiedet...

Ältere Versionen zu haben hilft oft bei der Fehlersuche. Ich habe sie ab 3.9.0.0 mit ein paar Lücken.
Um die Version 4.3 herum muss es aber auch ein Ereignis gegeben haben, denn seitdem stürzt JI ab. Das ist der eigentlich tragische Umbruch, denn mit der davor nicht erforderlichen Warnung konnte man gut leben.

Zitat von "bertram"

Dieser Vorschlag ist natürlich leicht umzusetzen.

Danke!

Zitat von "bertram"

Hm, da bin ich zunächst mal ratlos. Für diesen Zweck wurde in ji nie etwas programmiert. Ich selber benutze dafür die Zwischenablage und in ji "Bild > einfügen". Kann es sein, dass das Problem auf Seiten des eMail-Klient liegt? Denn mit meinem kann ich auf die geschilderte Art auch in IrfanView kein Bild einfügen und in ji ergibt sich gar keine Reaktion.

Ich wusste doch, dass ich noch etwas vergessen hatte: Ich benutze Windows Live Mail. Bildanhänge kann ich damit nur speichern oder drucken oder (mit IrfanView) öffnen.

Mit der von mir genannten Methode kann ich die Bilder in diverse Programme ziehen, wie IrfanView, Corel PaintShop Pro, Paint, Word, WordPad.

Dass es nunmehr mit JI nicht mehr geht, kann nicht am eMail-Klient liegen, denn unter denselben Rahmenbedingungen laufen die Versionen bis v4.1.4.1 problemlos ( ja, ich habe sie noch alle). Wenn also nichts umprogrammiert wurde, dann müsste das wohl beim Erstellen der EXE passieren.

Ein Bild verkleinern kann man mittels 'Bild verkleinern oder vergrößern auf:', indem man den Wert für die lange Seite aus einer Liste auswählt. Will man dann den Wert durch Anklicken der im Menü weit unten stehenden Schaltfläche 'Größe ändern' bestätigen, stellt man fest, dass es direkt über dieser Schaltfläche eine aktivierte Checkbox 'Seitenverhältnis beibehalten' gibt.

Aber oh je, das wollte man doch gar nicht! Also Haken raus!

Aber oh je, die kurze Seite ist ja auch verändert! Wie war noch der Ausgangswert?

Dumm, weiss man nicht genau. Also auf 'abbrechen' klicken und das Ganze von neuem, jetzt aber zuerst nach unten ans Ende des Menüs und den Haken herausnehmen und dann im Menü nach oben und den Wert für die lange Seite einstellen. Dann wieder zurück nach unten und 'Größe ändern' anklicken.

Würde die Checkbox direkt über dem Eingabefeld 'lange Seite' stehen, so würde man mit einem Blick sofort erkennen, dass es 3 Einstellmöglichkeiten gibt - wobei die 1. die entscheidende für die korrekte Größenkorrektur ist. Dadurch wäre vermieden, dass man immer wieder in die jetzt bestehende Falle tappt.

Wenn man Bilder aus dem Internet herunterladen möchte, diese aber zunächst nicht speichern will, so bietet sich folgende Möglichkeit an:

Mittels 'Bild senden...' aus dem Kontextmenü auf das betreffende Bild wird dieses in ein leeres eMail eingefügt. Mittels Drag&Drop kann man dann das Bild auf ein Bildanzeige-Fenster, z.B. IrfanView ziehen, wodurch dieses kommentarlos angezeigt wird.

Bis mindestens v4.1.4.1 ging das mit JI ebenso problemlos. Danach, bis mindestens v4.2.7.8, kam dann immer eine längere Warnung, die man jedoch ignorieren konnte, das das Bild trotzdem geladen wurde. Seit mindestens v4.3.0.1 stürzt JI unter Anzeige einer Fehlermeldung ab:

'Anwendungsfehler: Exception EInvalidPointer in Modul jpgIlluminator.exe bei 000040DD. Ungültige Zeigeroperation.'.

Was ist da in 2 Stufen anders geworden und lässt sich das Rad wieder zurückdrehen?

Windows 7 64 Bit