Gerhard Huber wrote:>>Öffnen als Platzhalter, für Rawbilder mit allen schrecklichen Konsequenzen (im Attributedialog)Es sind dabei zumindest diverse Probleme aufgetreten, z.B. dass man eine 16-Bit-Vorschau braucht. Dazu gibt es jetzt diverse Einstellungen im Attributedialog, ob man die alle braucht, weiß ich nicht, es gibt intern noch mehr davon.
Oder evtl. eine 8-Bit-Vorschau mit nichtlinearer Tonwertkurve?
Das verstehe ich nicht.
bkh wrote:Wenn man die Bittiefe der Vorschau von 16 auf 8 bit zurückschaltet, wird die Dateigröße nicht kleiner.
Solange die Vorschau nicht gespeichert wird (und bei Raw wird sie nicht gespeichert, weil sonst der Größenvorteil wieder dahin wäre), hat das Umschalten der Bittiefe keinen Einfluss auf die Dateigröße.
Martin Huber wrote:Das war keine Absicht. Der radiale Weichzeichner ist alleine schon wegen seiner Geschwindigkeit nicht als Arbeitsebene zu gebrauchen.
Das stimmt leider. So sehr mir das nicht-destruktive Arbeiten damit auch gefallen würde...
Danke für die Klarstellung!
Gerhard Huber wrote:>>Öffnen als Platzhalter, für Rawbilder mit allen schrecklichen Konsequenzen (im Attributedialog)Es sind dabei zumindest diverse Probleme aufgetreten, z.B. dass man eine 16-Bit-Vorschau braucht. Dazu gibt es jetzt diverse Einstellungen im Attributedialog, ob man die alle braucht, weiß ich nicht, es gibt intern noch mehr davon.
Oder evtl. eine 8-Bit-Vorschau mit nichtlinearer Tonwertkurve?
Das verstehe ich nicht.
Also z. B. beim Vorschaubild vor dem Speichern z. B. die sRGB-Tonwertkurve anwenden (oder irgendeine andere Wandlung, z. B. in 8 bit-floats) und anschließend wieder zurückwandeln. Oder sollen die Vorschaubilder immer verlustfrei komprimiert sein?
Martin Huber wrote:
bkh wrote:Wenn man die Bittiefe der Vorschau von 16 auf 8 bit zurückschaltet, wird die Dateigröße nicht kleiner.
Solange die Vorschau nicht gespeichert wird (und bei Raw wird sie nicht gespeichert, weil sonst der Größenvorteil wieder dahin wäre), hat das Umschalten der Bittiefe keinen Einfluss auf die Dateigröße.
Wenn ich das Vorschaubild einschalte, werden bei mir sowohl bei Raws als auch bei 16 bit TIFFs immer 16 bit-Vorschaubilder gespeichert (zumindest wird beim Umschalten auf 8 bit die PLD nicht kleiner).
Wenn ich übrigens eine 16 bit-Platzhalterebene per Attribute-Dialog nach RGB wandle, ist die Bittiefe plötzlich nur 8 bit.
bkh wrote:
Oder evtl. eine 8-Bit-Vorschau mit nichtlinearer Tonwertkurve?
Das verstehe ich nicht.
Also z. B. beim Vorschaubild vor dem Speichern z. B. die sRGB-Tonwertkurve anwenden (oder irgendeine andere Wandlung, z. B. in 8 bit-floats) und anschließend wieder zurückwandeln.
Ich versteh 's immer noch nicht. Warum sollte ich das machen? Um bei Platzhalter-16-Bit-Bildern die 8-Bit des Vorschaubildes besser auszunützen? Aber wenn ich bei einem 16-Bit-Platzhalter wirklich im Dokument die 16-Bit sehen muss, dann sollte ich auch ein 16-bittiges Vorschaubild haben. Und wenn ich sie nicht sehen muss, dann reicht auch das "normale" 8-Bit-Vorschaubild.
bkh wrote:Oder sollen die Vorschaubilder immer verlustfrei komprimiert sein?
Die Einstellung in den Ebenenattributen ist momentan nicht ganz richtig beschriftetet. Da sollte eigentlich statt 8-/16-Bit sowas wie "Vorschau mit niedriger Qualität" (in dem Fall wird immer ein 8-Bit-Vorschaubild erzeugt, das ggf. JPEG-komprimiert wird) und "Vorschau mit hoher Qualität" (in dem Fall wird ein Vorschaubild in der Bittiefe der platzierten Datei erzeugt, das verlustfrei komprimiert wird) stehen.
bkh wrote:
Martin Huber wrote:
bkh wrote:Wenn man die Bittiefe der Vorschau von 16 auf 8 bit zurückschaltet, wird die Dateigröße nicht kleiner.
Solange die Vorschau nicht gespeichert wird (und bei Raw wird sie nicht gespeichert, weil sonst der Größenvorteil wieder dahin wäre), hat das Umschalten der Bittiefe keinen Einfluss auf die Dateigröße.
Wenn ich das Vorschaubild einschalte, werden bei mir sowohl bei Raws als auch bei 16 bit TIFFs immer 16 bit-Vorschaubilder gespeichert (zumindest wird beim Umschalten auf 8 bit die PLD nicht kleiner).
Ja, da wird momentan beim Umschalten auf 8-Bit-Vorschau das Vorschaubild nicht mit umgerechnet. Ich sehe mir das an.
bkh wrote:Wenn ich übrigens eine 16 bit-Platzhalterebene per Attribute-Dialog nach RGB wandle, ist die Bittiefe plötzlich nur 8 bit.
Das ist eine Eigenschaft des Ebenenattribute-Dialogs. Nicht-Bilder werden bei der Konvertierung in Bilder über die Ebenenattribute immer zu 8-Bit-Ebenen.
Martin Huber wrote:
Ich versteh 's immer noch nicht. Warum sollte ich das machen? Um bei Platzhalter-16-Bit-Bildern die 8-Bit des Vorschaubildes besser auszunützen? Aber wenn ich bei einem 16-Bit-Platzhalter wirklich im Dokument die 16-Bit sehen muss, dann sollte ich auch ein 16-bittiges Vorschaubild haben. Und wenn ich sie nicht sehen muss, dann reicht auch das "normale" 8-Bit-Vorschaubild.
Zumindest bei den linear codierten Raws braucht man die volle Auflösung nur bei den niedrigsten Tonwerten – weiter oben ist das Rauschen viel stärker als die Schritte im Raw. Auch die sichtbaren Unterschiede von Stufe zu Stufe werden von dunkel nach hell geringer. Nikon und Sony speichern bei der verlustbehafteten Komprimierung der Raws auch nicht alle Schritte, sondern dünnen im oberen Bereich stark aus (wenn auch nicht auf 256 Werte). Und letztlich ist das ja auch der Grund, warum man bei 8 bit nicht linear codiert.
Martin Huber wrote:
bkh wrote:Wenn ich übrigens eine 16 bit-Platzhalterebene per Attribute-Dialog nach RGB wandle, ist die Bittiefe plötzlich nur 8 bit.
Das ist eine Eigenschaft des Ebenenattribute-Dialogs. Nicht-Bilder werden bei der Konvertierung in Bilder über die Ebenenattribute immer zu 8-Bit-Ebenen.
Wäre es nicht sinnvoller, die Bittiefe des Arbeitsfarbraums zu nehmen?
Habe eben mal stattdessen "Convert Layer Type …" probiert (mit Nikon NEF) – damit (wie auch über den Attribute-Dialog) bekomme ich erstaunlicherweise ein entwickeltes Raw-Bild (obwohl die Entwicklungs-Arbeitsebenen noch da sind).
bkh wrote:Habe eben mal stattdessen "Convert Layer Type …" probiert (mit Nikon NEF) – damit (wie auch über den Attribute-Dialog) bekomme ich erstaunlicherweise ein entwickeltes Raw-Bild (obwohl die Entwicklungs-Arbeitsebenen noch da sind).
Das kann ich hier bei mir nicht nachvollziehen. Hast du eine der beiden neuen Einstellungen (Vorschau speichern, Vorschau 16-Bit) geändert? Wenn ja, dann ist das eine der Optionen, die Gerhard erwähnte, die wir evtl. noch brauchen.
Raw-Bilder sind als Platzhalter momentan nicht eindeutig: Wenn du eine Raw-Datei in ein Dokument ziehst, wird die Raw-Datei "voll entwickelt" dargestellt (der Platzhalter enthält die Arbeitsebenen). Öffnest du die Raw-Datei als Platzhalter mit dem neuen Menüpunkt, wird die Raw-Datei nicht "voll entwickelt" dargestellt, sondern die Arbeitsebenen sind in dem Dokument (außerhalb des Platzhalters). Die Umschaltung zwischen den beiden Verhaltensweisen erfolgt momentan implizit über die beiden neuen Optionen.
bkh wrote:Habe eben mal stattdessen "Convert Layer Type …" probiert (mit Nikon NEF) – damit (wie auch über den Attribute-Dialog) bekomme ich erstaunlicherweise ein entwickeltes Raw-Bild (obwohl die Entwicklungs-Arbeitsebenen noch da sind).
Das kann ich hier bei mir nicht nachvollziehen. Hast du eine der beiden neuen Einstellungen (Vorschau speichern, Vorschau 16-Bit) geändert? Wenn ja, dann ist das eine der Optionen, die Gerhard erwähnte, die wir evtl. noch brauchen.
Sorry, der Effekt tritt wohl nur auf, wenn ich statt einer externen Datei "embedded" aktiviere. An der Vorschau scheint's nicht zu liegen.
Ist es eigentlich Absicht, dass die Kind-Arbeitsebene beim Umwandeln von Platzhalter zu normaler Ebene mit eingerechnet werden und dann verschwinden (nicht nur bei Raw)? Mir würde es besser gefallen, wenn die Kindebenen erhalten blieben wie z. B. Beim Unwandeln von RGB zu Lab. Für das Verrechnen gibt es ja "Auf eine Ebene reduzieren".
When I create a couple of simple vector shapes without anti-aliasing, and try to export to a 24bit PNG file the result is ALWAYS an indexed 8bit file, even though I unchecked "reduce colors".
I tried to save a full colour PNG through the Save As command, but it results again in an 8bit indexed PNG file. I require these files to be saved as full 24bit colour PNG files, otherwise the application I am importing these into will not read them correctly.
Currently I resolve this by importing the exported PNG files into Krita, and resaving them as full 24bit.
In short: when we save a PNG without colour reduction, it should be saved as a full 24bit colour PNG - no matter if only three or four colours are used. This should be a user decision.
Herbert123 wrote:When I create a couple of simple vector shapes without anti-aliasing, and try to export to a 24bit PNG file the result is ALWAYS an indexed 8bit file, even though I unchecked "reduce colors".
If there are <= 256 colors in a document, PhotoLine will create an RGB-PNG with a palette.
Herbert123 wrote:I require these files to be saved as full 24bit colour PNG files, otherwise the application I am importing these into will not read them correctly.
You should definitely write a bug report to the creators of that application.
Herbert123 wrote:In short: when we save a PNG without colour reduction, it should be saved as a full 24bit colour PNG - no matter if only three or four colours are used. This should be a user decision.
IMO this would be a major step backward. Nowadays, most users don't understand the concept of files with a color palette, so most users will get unnecessarily large files.
photoken wrote:The "Offset" value for a line pattern cannot quite achieve perfect (or even very good) corners for any given rectangle:
The "Offset" is - well - just an offset. It is just a first, small step to aligning line patterns.
The larger step is scaling the pattern between two corners, so that it fits exactly. This should work in the next beta, but you will habe to turn it on in the line pattern editor.
Herbert123 wrote:When I create a couple of simple vector shapes without anti-aliasing, and try to export to a 24bit PNG file the result is ALWAYS an indexed 8bit file, even though I unchecked "reduce colors".
If there are <= 256 colors in a document, PhotoLine will create an RGB-PNG with a palette.
Herbert123 wrote:I require these files to be saved as full 24bit colour PNG files, otherwise the application I am importing these into will not read them correctly.
You should definitely write a bug report to the creators of that application.
Herbert123 wrote:In short: when we save a PNG without colour reduction, it should be saved as a full 24bit colour PNG - no matter if only three or four colours are used. This should be a user decision.
IMO this would be a major step backward. Nowadays, most users don't understand the concept of files with a color palette, so most users will get unnecessarily large files.
Martin
While I understand that the web export would behave like that (which is truly useful!), I think the File-->Save As [png] option ought to at least have an option to enforce a full 24bit colour png. I mean, I am able to achieve this in any other image editor - it is a bit odd that Photoline would the the only one not allowing for this. Situations exist in which indexed PNG files are just not useful: for example, in broadcasting and 3d work. PNG is not only used as a format for the web.
And yes, I have informed the developers of the other software about this issue.
Martin Huber wrote:The "Offset" is - well - just an offset. It is just a first, small step to aligning line patterns.
The larger step is scaling the pattern between two corners, so that it fits exactly. This should work in the next beta, but you will habe to turn it on in the line pattern editor.
Sounds good. I look forward to testing that.
Ken Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.