11beta4 - erste testergebnisse unter osx

[krahni]

hallo betatester und hubers,

hier mal meine ersten testergebnisse/anregungen unter osx 10.3.5, beschränken sich im augenblick aus zeitmangel auf bildübersicht und bildanzeige ...

bildübersicht:
- umschalten zwischen ordnern dauert zu lange (ca. pro 100 bilder 2 sek. bei 200px vorschaubildern)
- button zum minimieren des fensters wäre schön, neuöffnen dauert nämlich auch lange, je nach zuletzt verwendetem ordner
- textgrösse im ordnerbaum (zu gross) und in dateiinfo (zu klein) sollte einstellbar sein
- blättern und top-bottom sprung im rechten fenster ermöglichen
- schliessen des festplattenbaum's dauert ewig

bildanzeige:
- zoom funktioniert nicht
- wozu speichern button, wird sofort gespeichert, undo-button zwingend erfolderlich für vorher-nachher-vergleich
- aktionen z.b. digi photo verbesserung wird ausgeführt - ergebnis aber merkwürdig (ebenenfehler?)

tastatursteuerung habt ihr ja in der 11beta4 bereits eingebaut, das ist toll!


das war's erstmal für heute ...

andreas krahn

--
teste auf:
g5/1.8 dual/2 gb ram/2x250 gb hd/nvidia 5200 fx/superdrive/osx 10.3.5

[Martin Huber]

bildübersicht:
- umschalten zwischen ordnern dauert zu lange (ca. pro 100 bilder 2 sek. bei 200px vorschaubildern)

Ab der Version 11 sollte das Laden von vorhandenen Bildübersichten deutlich schneller gehen. Kannst du mal testweise in einem "langsamen" Verzeichnis die Browse.plb löschen und neu erzeugen? Geht danach der Wechsel in diese Verzeichnis schneller?

- button zum minimieren des fensters wäre schön, neuöffnen dauert nämlich auch lange, je nach zuletzt verwendetem ordner

Der Fenstertyp, den wir momentan verwenden, unterstützt unt OS X keinen Minimieren-Knopf. Ich hatte mal testweise einen anderen Fenstertyp verwendet, aber das gab Probleme, wobei ich nicht mehr weiß, welche.Ich sehe es mir aber nochmal an.

- textgrösse im ordnerbaum (zu gross) und in dateiinfo (zu klein) sollte einstellbar sein

Das ist aber eher Mac OS-unüblich, oder? Ich habe jetzt mal eingebaut, dass im Ordnerbaum die gleiche Größe wie im Finder verwendet wird. Und für die kleine Schrift verwende ich nun die Labelunterschriften. Schau 's dir bitte mal inder nächsten Beta an und gib einen Kommentar dazu ab.

- blättern und top-bottom sprung im rechten fenster ermöglichen

Werde ich einbauen.

- schliessen des festplattenbaum's dauert ewig

Kann es sein, dass das der gleiche Punkt wie "umschalten zwischen ordnern dauert zu lange" ist, da beim Schließen des Festplattenbaums das aktive Verzeichnis wechselt?

bildanzeige:
- zoom funktioniert nicht

Bei mir geht der Zoom (wobei ich das aber mit meiner etwas neueren Version ausprobiert habe). Wie ist das
bei anderen?

- wozu speichern button, wird sofort gespeichert,

Das sollen mal "Kopiere in Verzeichnis" und "Verschiebe in Verzeichnis" werden und soll dem Sortieren von Bildern dienen.

undo-button zwingend erfolderlich für vorher-nachher-vergleich

Wo ist ein Undo erforderlich?

- aktionen z.b. digi photo verbesserung wird ausgeführt - ergebnis aber merkwürdig (ebenenfehler?)

Das werde ich mir ansehen.

Martin

[krahni]

hallo martin,

die browse.plb habe ich nun mal entfernt und neu aufgebaut - 9 sek. bei 787 bildern, vorher waren es 14 sek.
die bilder sind übrigens zwischen 500 kb und 1.5 mb gross, die thumbnails 200px, die alte browse.plb wurde mit 11beta3 erzeugt.

bei den zoom-funktionen schein ein fehler in der dialog-steuerung zu sein, manchmal geht es nachdem ich einmal das info-fenster geöffnet und wieder geschlossen habe. über dem "-"-button erscheint auch manchmal ein kontext mit der aufschrift "auto" - sieht aus wie auto-drehen ...

eine undo-funktion wäre wohl sinnvoll beim drehen (oder ist das absolut verlustfrei?) und natürlich bei den aktionen! das geht nicht, dass die aktionen entgültig sind!

andreas krahn

--
teste auf:
g5/1.8 dual/2 gb ram/2x250 gb hd/nvidia 5200 fx/superdrive/osx 10.3.5

kann es sein, dass bei diesem forum die signaturen nicht funktionieren?

[Martin Huber]

die browse.plb habe ich nun mal entfernt und neu aufgebaut - 9 sek. bei 787 bildern, vorher waren es 14 sek.
die bilder sind übrigens zwischen 500 kb und 1.5 mb gross, die thumbnails 200px, die alte browse.plb wurde mit 11beta3 erzeugt.

Wir verstehen uns da schon richtig: du hast das Verzeichnis einmal komplett gebrowst und danach dauert der Wechsel auf dieses Verzeichnis 9 Sek.
Dann kann ich diese Zeiten nicht nachvollziehen, aber das kann auch daran liegen, dass ich in den letzten Tagen die Bildübersicht an ein paar Stellen optimiert habe (hoffe ich zumindest).
Ich habe auf meinem G4/867 dual ein Testverzeichnis mit 700 Bildern angelegt und da dauert der Wechsel unter 2 Sekunden. Schau dir das mal in der nächsten Beta nochmal an, ob bei dir das Verhalten dann besser ist.

bei den zoom-funktionen schein ein fehler in der dialog-steuerung zu sein, manchmal geht es nachdem ich einmal das info-fenster geöffnet und wieder geschlossen habe. über dem "-"-button erscheint auch manchmal ein kontext mit der aufschrift "auto" - sieht aus wie auto-drehen ...

Da ist in der aktuellen Beta ein Fehler im Dialog. Da überlappt sich die Symbolleiste mit einem Textfeld. Eventuell kommen daher die Probleme.

eine undo-funktion wäre wohl sinnvoll beim drehen (oder ist das absolut verlustfrei?)

Das Drehen von JPEG-Dateien um Vielfache von 90 Grad ist verlustfrei mit einer Einschränkung: die Bildgröße wird auf ein Vielfaches der JPEG-Kachelgröße (üblicherweise 16x16) reduziert. In der Praxis ist das mit Digitalfots kein Problem, da diese erstens sehr groß sind und ein paar Pixel am Rand nicht auffallen und zweitens Digitalfotos im Regelfall eh eine passende Größe haben.

und natürlich bei den aktionen! das geht nicht,
dass die aktionen entgültig sind!

Wo soll das mit dem Undo anfangen und wo aufhören? Die Aktionen in der Bildanzeige arbeiten ebenso wie in der Bildübersicht und beim Batchkonvertieren direkt mit der Bilddatei. Will man Aktionen an Bildern testen, ist die Bildanzeige nicht die richtige Funktion. In diesem Fall sollte man die Datei öffnen und interaktiv bearbeiten. Dann hat man ein Undo.

Martin

[krahni]

die browse.plb habe ich nun mal entfernt und neu aufgebaut - 9 sek. bei 787 bildern, vorher waren es 14 sek.
die bilder sind übrigens zwischen 500 kb und 1.5 mb gross, die thumbnails 200px, die alte browse.plb wurde mit 11beta3 erzeugt.

Wir verstehen uns da schon richtig: du hast das Verzeichnis einmal komplett gebrowst und danach dauert der Wechsel auf dieses Verzeichnis 9 Sek.
Dann kann ich diese Zeiten nicht nachvollziehen, aber das kann auch daran liegen, dass ich in den letzten Tagen die Bildübersicht an ein paar Stellen optimiert habe (hoffe ich zumindest).
Ich habe auf meinem G4/867 dual ein Testverzeichnis mit 700 Bildern angelegt und da dauert der Wechsel unter 2 Sekunden. Schau dir das mal in der nächsten Beta nochmal an, ob bei dir das Verhalten dann besser ist.

jo - genau so habe ich es gemacht, eine beschleunigung von ca. 30% gab's ja schon im vergleich zur 11beta3 ...

eine undo-funktion wäre wohl sinnvoll beim drehen (oder ist das absolut verlustfrei?)

Das Drehen von JPEG-Dateien um Vielfache von 90 Grad ist verlustfrei mit einer Einschränkung: die Bildgröße wird auf ein Vielfaches der JPEG-Kachelgröße (üblicherweise 16x16) reduziert. In der Praxis ist das mit Digitalfots kein Problem, da diese erstens sehr groß sind und ein paar Pixel am Rand nicht auffallen und zweitens Digitalfotos im Regelfall eh eine passende Größe haben.

o.k., wenn die randpixel dann eben fehlen, es darf aber kein rand "hinzugezaubert" werden!

und natürlich bei den aktionen! das geht nicht, dass die aktionen entgültig sind!

Wo soll das mit dem Undo anfangen und wo aufhören? Die Aktionen in der B
ildanzeige arbeiten ebenso wie in der Bildübersicht und beim Batchkonvertieren direkt mit der Bilddatei. Will man Aktionen an Bildern testen, ist die Bildanzeige nicht die richtige Funktion. In diesem Fall sollte man die Datei öffnen und interaktiv bearbeiten. Dann hat man ein Undo.

ist das so schwierig einzubauen?
ich moechte ueberhaupt keine endgueltige funktion!
gerade bei filtern wo das ergebnis immer ein bisschen vom inhalt abhaengt ...
... zumindest muesste evtl. eine abfrage zum speichern kommen wenn man zum naechsten bild schaltet!

[Martin Huber]

Wo soll das mit dem Undo anfangen und wo aufhören? Die Aktionen in der Bildanzeige arbeiten ebenso wie in der Bildübersicht und beim Batchkonvertieren direkt mit der Bilddatei. Will man Aktionen an Bildern testen, ist die Bildanzeige nicht die richtige Funktion. In diesem Fall sollte man die Datei öffnen und interaktiv bearbeiten. Dann hat man ein Undo.

ist das so schwierig einzubauen?

Es ist sicherlich ein gewisser Aufwand. Aber der Punkt ist mehr, dass das nicht der Sinn dieser Funktion ist, testweise Aktionen anzuwenden. Der Sinn liegt eher darin, Bilder an-/durchzusehen, erste und grundlegende Arbeiten durchzuführen (wie das Drehen) und die Bilder ggf. zu sortieren.

ich moechte ueberhaupt keine endgueltige funktion!
gerade bei filtern wo das ergebnis immer ein bisschen vom inhalt abhaengt ...
... zumindest muesste evtl. eine abfrage zum speichern kommen wenn man zum naechsten bild schaltet!

Und genau dafür kann man das Bild öffnen, um es nachzubearbeiten. Dann wird auch nachgefragt.
Dir schwebt im Prinzip eine kleine Bildbearbeitung in der Bildbearbeitung vor.
Evtl. sollte man die Aktionen-Funktion aus der Bildanzeige entfernen? Dann kommt es nicht mehr zu solchen Missverständnissen.

Martin

[krahni]

Wo soll das mit dem Undo anfangen und wo aufhören? Die Aktionen in der Bildanzeige arbeiten ebenso wie in der Bildübersicht und beim Batchkonvertieren direkt mit der Bilddatei. Will man Aktionen an Bildern testen, ist die Bildanzeige nicht die richtige Funktion. In diesem Fall sollte man die Datei öffnen und interaktiv bearbeiten. Dann hat man ein Undo.

ist das so schwierig einzubauen?

Es ist sicherlich ein gewisser Aufwand. Aber der Punkt ist mehr, dass das nicht der Sinn dieser Funktion ist, testweise Aktionen anzuwenden. Der Sinn liegt eher darin, Bilder an-/durchzusehen, erste und grundlegende Arbeiten durchzuführen (wie das Drehen) und die Bilder ggf. zu sortieren.

ich moechte ueberhaupt keine endgueltige funktion!
gerade bei filtern wo das ergebnis immer ein bisschen vom inhalt abhaengt ...
... zumindest muesste evtl. eine abfrage zum speichern kommen wenn man zum naechsten bild schaltet!

Und genau dafür kann man das Bild öffnen, um es nachzubearbeiten. Dann wird auch nachgefragt.
Dir schwebt im Prinzip eine kleine Bildbearbeitung in der Bildbearbeitung vor.
Evtl. sollte man die Aktionen-Funktion aus der Bildanzeige entfernen? Dann kommt es nicht mehr zu solchen Missverständnissen.

Martin

ja - dann solltet ihr die aktionen wohl entfernen, wie soll man denn das sonst benutzen ohne undo?
vielleicht solltet ihr mal ueberlegen ob ihr nicht aus eurem programm 2 macht - eines in der art wie photoshop elements.
nur bestehend aus der bilduebersicht und der bildanzeige und natuerlich grundlegenden bearbeitungsfunktionen und aktionen.
den ganzen schrift- und satz-part koenntet ihr weglassen.

dann waere das ein geniales tool fuer digitalfotografen ...

n... eine eierlegendewollmilchsau scheiterte bisher immer irgendwann an der geschwindigkeit

[Harry]

ja - dann solltet ihr die aktionen wohl entfernen, wie soll man denn das sonst benutzen ohne undo?
vielleicht solltet ihr mal ueberlegen ob ihr nicht aus eurem programm 2 macht - eines in der art wie photoshop elements.
nur bestehend aus der bilduebersicht und der bildanzeige und natuerlich grundlegenden bearbeitungsfunktionen und aktionen.
den ganzen schrift- und satz-part koenntet ihr weglassen.

dann waere das ein geniales tool fuer digitalfotografen ...
... eine eierlegendewollmilchsau scheiterte bisher immer irgendwann an der geschwindigkeit

Interessante Idee.
Vielleicht sollten wir das in einem eigenen Thread diskutieren.
Wobei natürlich zuerst die Frage steht, ob das überhaupt leistbar ist.
Denn zwei Programme (auch wenn die Codebasis nahezu identisch ist) machen immer mehr Aufwand als eins.

Harry

[Martin Huber]

vielleicht solltet ihr mal ueberlegen ob ihr nicht aus eurem programm 2 macht - eines in der art wie photoshop elements.
nur bestehend aus der bilduebersicht und der bildanzeige und natuerlich grundlegenden bearbeitungsfunktionen und aktionen.
den ganzen schrift- und satz-part koenntet ihr weglassen.

dann waere das ein geniales tool fuer digitalfotografen ...

Ich denke nicht, dass wir als kleine Firma so ein Programm verkaufen könnten. Der Unterschied zu kostenlosen Programmen wie IrfanView und iPhoto wäre für den normalen Anwender nicht mehr erkennbar. Große Firmen können das mit einem entsprechenden Werbeetat ausgleichen.

... eine eierlegendewollmilchsau scheiterte bisher immer irgendwann an der geschwindigkeit

Meiner Ansicht nach scheitern eierlegende Wollmilchsäue nicht an der Geschwindigkeit (die ist für mich mehr ein Symptom) sondern eher an der Menge der beteiligten Entwicklern. Und dass wir zuviele Entwickler sind, darüber können wir uns nicht beschweren

Interessante Idee.
Vielleicht sollten wir das in einem eigenen Thread diskutieren.
Wobei natürlich zuerst die Frage steht, ob das überhaupt leistbar ist.
Denn zwei Programme (auch wenn die Codebasis nahezu identisch ist) machen immer mehr Aufwand als eins.

Das ist für mich genau der Knackpunkt. Momentan haben wir 2 Versionen (Mac OS und Windows). Diese 2 Versionen vernünftig zu testen und die Dokumentation zu aktualisieren, ist sehr schwierig und aufwendig. Dann ist noch immer Linux im Gespräch. Und das ganze dann noch in 2 Sprachversionen.
Wenn wir dann auch noch ein zweites Programm haben, kämen wir kaum noch zum Entwickeln.

Martin

[gmhofmann]

Das halte ich für eine absolute Schnapsidee, PL32 in zwei Programme aufzusplitten.
Ich erinnere an den Unfug, den Adobe immer noch mit Photoshop und ImageReady veranstaltet...

[krahni]

Das halte ich für eine absolute Schnapsidee, PL32 in zwei Programme aufzusplitten.
Ich erinnere an den Unfug, den Adobe immer noch mit Photoshop und ImageReady veranstaltet...

das ist ein ganz anderes programm, imageready hat seinen eigenen einsatzzweck und würde, wenn in photoshop integriert sicherlich das programm sprengen.

dann müsste man den vergleich eher mit photoshop-photoshop elements anstellen. d.h. sozusagen ein extrakt aus pl32 ...

... wir bauen hier in der firma auch richtig fette applikationen und haben durch compiler-direktiven teile daraus als einzelmodule extrahiert.
wenn man das geschickt anstellt behält man eine codebasis.

[Harry]

... wir bauen hier in der firma auch richtig fette applikationen und haben durch compiler-direktiven teile daraus als einzelmodule extrahiert.
wenn man das geschickt anstellt behält man eine codebasis.

Aber mit compilieren alleine ist es doch nicht getan.
Zuerst muss überlegt werden, wie es aussehen soll, was rein soll...
Das ist Aufwand.
Dazu kommt Vermarktung, Support usw usf

Und dass ich aus einem Programm mit GUI durch ein "paar" #defines ein anderes mit GUI zaubere kann ich mir nicht so richtig vorstellen.
Klar, der meiste Code ist zweifach zu verwenden, aber eben nur der meiste.

Harry

[krahni]

es soll ja garnicht anders aussehen, man kann doch einfach was weglassen ...
... und über das "wie" brauchen die betatester sich nicht den kopf zerbrechen, entscheidend ist ob die entwickler gewillt sind sowas zu machen.

und eine "light" oder "digiphoto" - version von pl32 zusätzlich zu "vermarkten" kann ja wohl nicht solch ein grosser zusätzlicher aufwand sein ...

mir persönlich ist das programm mit seinem riesigen funktionsumfang zu fett.
ich hätte für eine lückenlösung (digitalfotografie) lieber ein kleines, feines, schnelles und übersichtliches programm ohne diese vielen paletten ...

[Gerhard Huber]

es soll ja garnicht anders aussehen, man kann doch einfach was weglassen ...
... und über das "wie" brauchen die betatester sich nicht den kopf zerbrechen, entscheidend ist ob die entwickler gewillt sind sowas zu machen.
und eine "light" oder "digiphoto" - version von pl32 zusätzlich zu "vermarkten" kann ja wohl nicht solch ein grosser zusätzlicher aufwand sein ...
mir persönlich ist das programm mit seinem riesigen funktionsumfang zu fett.
ich hätte für eine lückenlösung (digitalfotografie) lieber ein kleines, feines, schnelles und übersichtliches programm ohne diese vielen paletten ...

Ich will hier jetzt nicht rumjammern, aber es ist uns mit der momentanen Besetzung nicht möglich ein weiteres Produkt zu vermarkten, egal ob wir das aus PL32 ausgliedern oder irgendwo anders herbekommen.
Für einen aussenstehenden mag das vielleicht nicht ganz verständlich sein, aber jedes Produkt zieht einen riesigen Aufwand nach sich, sei es die Anpassung der Internetseiten, die Bestellformulare, die CD-Hüllen, die Verpackungen, ...
Auch der Support wird deutlich schwieriger, weil jedesmal geklärt werden muss, welches Produkt die Anfrage betrifft.
Also Argument 1, das gegen zwei Versionen spricht.
Argument 2 ist zugegeben sehr subjektiv, aber ich hasse es, für jeden Arbeitsschritt ein eigenes Programm zu brauchen. Musterbeispiele dafür sind PS mit ImageR oder Corel mit Draw und PhotoPaint. Solche Produkte sind nie "rund" zu bedienen und es ist immer lästig, wenn man zwischen den Programmen wechseln muss.
Das Argument mit den vielen Paletten höre ich zwar öfters mal, argumentiere aber dagegen, dass man auch bei anderen Programmen tausende von Paletten öffnen kann, aber, wie in PL32, nicht muss.
Wenn man sich in PL32 einigermaßen auskennt, kann man schnell eine Bildschirmanordnung finden, die das "optimale" Arbeiten zulässt.
Das einz
ige Gegenargument, dass ich gelten lasse ist, dass ein Anfänger von den vielen Funktionen durchaus überfordert werden kann.

Gerhard

[Michael Roek-Ramirez]

Hallo Gemeinde:

ich bin vollkommen mit Gerhard und Martin einverstanden:

- Low-End-Bildbearbeitung gibt es auch Freeware ausreichend
- Jeder, der selbstständig ist oder mal war, weiss, dass es eben nicht mit
"mal schnell ein Programm schreiben" getan ist und das "Drumherum"
mehr Verwaltungsarbeit ist als der eigentliche produktive Aufwand
- Photoline 32 ist ein Programm, dass einen gewissen Einarbeitungs-
aufwand voraussetzt und vom Einsteiger NICHT intuitiv bedienbar ist,
das trifft aber beispielsweise für PS noch viel mehr zu!
- PhotoLine 32 ist ausreichend konfigurierbar um es ¨für einen reduzierten
Einsatzbereich leicht "abzuspecken"

Natürlich fände ich es toll, wenn ich PL32 auch als CAD einsetzen könte, eine tolle Karikaturfunktion hätte (=Kai's Power Goo....), das Morphen besser ginge, das Erzeugen von figürlichen Animationen wie z.B. mit MOHO möglich wäre..... aber ich weiss, was das für das Huber-Power-Team bedeutet..... und bin froh, mit dem was PhotoLine 32 kann!

Ich bin - und wie ich aus einigen Meinungen im Forum erkenne nich nur ich - kein Freund der Monster-Monopol-Software und denke dass es wichtiger ist, Energie in die Verbreitung von PL32 zu stecken, da nur die eine weitere Entwicklung und Erweiterung von PL32 gewährleistet und nicht umgekehrt: Das Programm verkauft sich nicht 1% besser, wenn es mit 10% Zusatzfunktionen erweitert wird!

Gruss

Michael