Neue Testversion 19.90b4

Hier diskutieren die Betatester von PhotoLine untereinander und mit den Entwicklern
Martin Huber
Entwickler
Entwickler
Beiträge: 4159
Registriert: Di 19 Nov 2002 15:49

Re: Neue Testversion 19.90b4

Beitrag von Martin Huber »

Eurgail hat geschrieben:Im Dialog für den radialen Weichzeichner ist (seit neuestem) die Anlegung einer Arbeitsebene erlaubt!?
Das war keine Absicht. Der radiale Weichzeichner ist alleine schon wegen seiner Geschwindigkeit nicht als Arbeitsebene zu gebrauchen.

Martin
Martin Huber
Entwickler
Entwickler
Beiträge: 4159
Registriert: Di 19 Nov 2002 15:49

Re: Neue Testversion 19.90b4

Beitrag von Martin Huber »

bkh hat geschrieben:
Gerhard Huber hat geschrieben:>>Ö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 hat geschrieben: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
Eurgail
Mitglied
Beiträge: 379
Registriert: So 06 Jul 2014 23:02

Re: Neue Testversion 19.90b4

Beitrag von Eurgail »

Martin Huber hat geschrieben: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!
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: Neue Testversion 19.90b4

Beitrag von bkh »

Martin Huber hat geschrieben:
bkh hat geschrieben:
Gerhard Huber hat geschrieben:>>Ö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 hat geschrieben:
bkh hat geschrieben: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.

L.G.

Burkhard.
Martin Huber
Entwickler
Entwickler
Beiträge: 4159
Registriert: Di 19 Nov 2002 15:49

Re: Neue Testversion 19.90b4

Beitrag von Martin Huber »

bkh hat geschrieben:
Martin Huber hat geschrieben:
bkh hat geschrieben: 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 hat geschrieben: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 hat geschrieben:
Martin Huber hat geschrieben:
bkh hat geschrieben: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 hat geschrieben: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
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: Neue Testversion 19.90b4

Beitrag von bkh »

Martin Huber hat geschrieben: 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 hat geschrieben:
bkh hat geschrieben: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).

L.G.

Burkhard.
Martin Huber
Entwickler
Entwickler
Beiträge: 4159
Registriert: Di 19 Nov 2002 15:49

Re: Neue Testversion 19.90b4

Beitrag von Martin Huber »

bkh hat geschrieben: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.

Martin
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: Neue Testversion 19.90b4

Beitrag von bkh »

Martin Huber hat geschrieben:
bkh hat geschrieben: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".

L.G.

Burkhard.
Benutzeravatar
Herbert123
Mitglied
Beiträge: 2140
Registriert: Sa 12 Mai 2012 21:38

Re: Neue Testversion 19.90b4

Beitrag von Herbert123 »

Problem with saving PNG files.

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.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
Martin Huber
Entwickler
Entwickler
Beiträge: 4159
Registriert: Di 19 Nov 2002 15:49

Re: Neue Testversion 19.90b4

Beitrag von Martin Huber »

Herbert123 hat geschrieben: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 hat geschrieben: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 hat geschrieben: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
Martin Huber
Entwickler
Entwickler
Beiträge: 4159
Registriert: Di 19 Nov 2002 15:49

Re: Line pattern with offset

Beitrag von Martin Huber »

photoken hat geschrieben: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.

Martin
Benutzeravatar
Herbert123
Mitglied
Beiträge: 2140
Registriert: Sa 12 Mai 2012 21:38

Re: Neue Testversion 19.90b4

Beitrag von Herbert123 »

Martin Huber hat geschrieben:
Herbert123 hat geschrieben: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 hat geschrieben: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 hat geschrieben: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.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

Re: Line pattern with offset

Beitrag von photoken »

Martin Huber hat geschrieben: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. :D
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.