Neue Testversion 19.40b11

[beiti]

Das heißt, es werden 2 Rendering Intents bei der Bildschirmausgabe verwendet.

Das erstaunt mich etwas, weil ich dachte, mit einem einfachen Matrixprofil (wie es z. B. mein Monitorprofil ist) als Ziel könne man von vornherein nur farbmetrisch konvertieren und nicht perzeptiv. Wenn ich manuell ein Bild z. B. nach sRGB konvertiere, macht es ja auch keinen Unterschied, ob ich "perzeptiv" oder "relativ farbmetrisch" wähle; die Konvertierung erfolgt in jedem Fall "relativ farbmetrisch".

[bkh]

My point is that your method increases the number of keystrokes and/or mouse actions: we would have to activate the layers panel first to work in it, and then again activate the main view window before we could continue to work in the main view. And we already have established that the use of the mouse to activate the main view is at the very least quite awkward (with risks of losing the selection and inconvenient exact clicking on specific window areas). And what about users who do not wish to use shortcut keys at all? You force them to use the mouse to somehow activate the main window.

You're addressing the problems in the new approach (keyboard focus on layer panel), but what about the inconsistencies in the old (e.g., navigating in invisible layers while "Find Layers" is active, not being able to use a shortcut key for "Find", see http://www.pl32.com/forum3/posting.php? ... 98#pr37289)? I guess that it's easily possible to find workflows for which either approach uses fewer keystrokes.

Btw, I think that it's worth considering how the new approach could be improved to make existing workflows just as painless. After all, this is what a beta version is for. Imo, it makes no sense to insist on being able to use it as a production version, all the time.

• think about keystrokes (Alt-Arrow keys?) to move layers, independently of the chosen tool (even now, you could use macros for that, but only with absolute movement, 1px, for example, independently of the zoom level – that might even be an advantage for precise positioning).

• also, certain actions could/should move the focus back to the main window, such as (re-)selecting a tool in the toolbar, maybe duplicating a layer, etc.

There's probably a lot more, imo we should take the time to explore things a bit more deeply.

Cheers

Burkhard.

[bkh]

Das heißt, es werden 2 Rendering Intents bei der Bildschirmausgabe verwendet.

Das erstaunt mich etwas, weil ich dachte, mit einem einfachen Matrixprofil (wie es z. B. mein Monitorprofil ist) als Ziel könne man von vornherein nur farbmetrisch konvertieren und nicht perzeptiv. Wenn ich manuell ein Bild z. B. nach sRGB konvertiere, macht es ja auch keinen Unterschied, ob ich "perzeptiv" oder "relativ farbmetrisch" wähle; die Konvertierung erfolgt in jedem Fall "relativ farbmetrisch".

Bei der Konvertierung sind immer zwei Farbprofile beteiligt. Es wird zuerst vom Ausgangsfarbraum in einen Zwischenfarbraum (PCS) konvertiert, normalerweise XYZ oder Lab, und von dort ins Zielprofil. Es ist also bei allen Konvertierungen auch das CMYK-Profil beteiligt, und das unterstützt alle Intents. Selbst wenn du ein normales sRGB-Bild auf dem Bildschirm betrachtest, kann der Intent einen Unterschied machen, wenn das Display-Profil verschiedene Intents anbietet.

L.G.

Burkhard.

[beiti]

Selbst wenn du ein normales sRGB-Bild auf dem Bildschirm betrachtest, kann der Intent einen Unterschied machen, wenn das Display-Profil verschiedene Intents anbietet.

Das tut mein Display-Profil aber nicht. Deshalb wundere ich mich.
Beim ersten Teil der Konvertierung - sRGB nach ISO-CMYK - wird der Rendering Intent natürlich beachtet, weil das CMYK-Profil es unterstützt. Soweit okay.
Aber von ISO-CMYK ins Monitorprofil dürfte man eigentlich keinen Unterschied sehen, wenn das Monitorprofil den perzeptiven Intent nicht unterstützt.

[bkh]

Aber von ISO-CMYK ins Monitorprofil dürfte man eigentlich keinen Unterschied sehen, wenn das Monitorprofil den perzeptiven Intent nicht unterstützt.

Doch, denn beim ersten Schritt CMYK -> PCS hat der Intent eine Auswirkung (das CMYK-Profil hat tatsächlich verschiedene Einträge für A2B0, A2B1, A2B2), bei der zweiten Umwandlung PCS-> Display bei deinem Display-Profil passiert natürlich immer das gleiche, wenn das Display-Profil keine verschiedenen Intents hat.

L.G.

Burkhard.

[Hoogo]

Ich dachte immer, der Farbraum in der Mitte (Lab) wäre groß genug für alles und sowieso die Referenz, die für alle anderen Farbräume die absoluten Koordinaten aufspannt? Wieso gibt es Intents, wenn man in den reinkonvertieren will?

[beiti]

Ich dachte immer, der Farbraum in der Mitte (Lab) wäre groß genug für alles und sowieso die Referenz, die für alle anderen Farbräume die absoluten Koordinaten aufspannt?

Das ist auch mein Wissensstand. Ich wüsste nicht, wozu man bei 'Quellfarbraum > PCS' einen Rendering Intent bräuchte.

[Martin Huber]

Ich dachte immer, der Farbraum in der Mitte (Lab) wäre groß genug für alles und sowieso die Referenz, die für alle anderen Farbräume die absoluten Koordinaten aufspannt?

Das ist auch mein Wissensstand. Ich wüsste nicht, wozu man bei 'Quellfarbraum > PCS' einen Rendering Intent bräuchte.

Warum man dazu ein Rendering Intent braucht, weiß ich auch nicht (dazu bin ich zu sehr reiner Anwender des Color Managements). Fakt ist aber, dass CMYK-Profile (wie Burkhard schon geschrieben hat) im Normalfall für die Konvertierung in den PCS für die verschiedenen Rendering Intents jeweils eigene Tabellen haben.

Martin

[photoken]

Btw, I think that it's worth considering how the new approach could be improved to make existing workflows just as painless. After all, this is what a beta version is for. Imo, it makes no sense to insist on being able to use it as a production version, all the time.

I agree.

Hopefully, the next beta will implement the new behaviour along with a couple of enhancements discussed here so we can test it to see how well it works.

Only by testing the new behaviour can we compare the benefits it provides with what the old behaviour has to offer.

[chrischa]

- Beschneidenwerkzeug: Das Rechteck kann jetzt mit der Tastatur auch über die Dokumentränder geschoben werden

Danke

[Eurgail]

Hopefully, the next beta will implement the new behaviour along with a couple of enhancements discussed here so we can test it to see how well it works.

Sorry, but i have to disagree once more. I still don't see any real advantage in that behavior. It is logical, but that's all. Personally, i found it annoying to use and generally, it's not the way one can find in any other design software.
Is there any reason for scrolling the layers with the arrow keys? I can't imagine...

If i want to shift a layer, that is hard to select in the document window, i want to be able to select it in the layers panel and reposition it directly with the arrow keys and without any special shortcuts.

[photoken]

Hopefully, the next beta will implement the new behaviour along with a couple of enhancements discussed here so we can test it to see how well it works.

Sorry, but i have to disagree once more.

Tsk, tsk. You're saying that you don't even want to allow others to test the new behaviour and see how well it works? I thought that was one of the purposes of beta testing.

it's not the way one can find in any other design software.

Like I said before, CorelDraw uses the arrow keys to scroll through the layer list. I've since looked at Krita and the Greenfish Icon Editor and they too use the arrow keys for scrolling through the layers. The important point is not to generate a roster of which programs do it and which don't, but to find a good implementation for PhotoLine.

Is there any reason for scrolling the layers with the arrow keys? I can't imagine...

Welllllll, as I've been saying, it's convenient, consistent with the behaviour in the other lists in PhotoLine and useful.

If i want to shift a layer, that is hard to select in the document window, i want to be able to select it in the layers panel and reposition it directly with the arrow keys and without any special shortcuts.

The problem with the old, incorrect behaviour that forces that behaviour on the user is that it places limits on the use of the Layers panel for no particular reason, as I've been explaining. And if you want to select a layer within a group you can't do it without using the mouse.

What I don't understand is what's so sacred about moving the contents of a layer that that should exclusively determine how the Layers panel behaves. There are many reasons for selecting a layer, and moving its contents is only one of them. Much better to behave as other lists and programs do and give the user the option of what to do once the layer has been selected....

[photoken]

That is the real world usage scenario: I move content, and then I probably want to select and move the next layer content. This requires two additional key strokes in your scenario.

And with the old incorrect behaviour you need to either use the mouse to scroll and select the next layer or use "Ctrl+Shift+PgUp" and "Ctrl+Shift+PgDn" to almost be able to select layers. (You can't get into groups to select their layers.) That's six key presses, by my count.

And yes, your suggested workflow does require extra mouse-clicks and mouse actions!

No. You just said (correctly) that my proposal suggests using the "<" and ">" keys to switch the focus. Now you ignore what you've just written and claim that my proposal requires mouse clicks (which it does not). Sorry, but you can't have it both ways....

There is just no need to activate the layer panel first for additional actions

Of course there is. You need to tell the program that you're finished moving layer content and now wish to navigate through the Layers panel.

No, I again disagree - your point would only be valid if there would be a benefit to creating a separate focus between the main view and the layer panel.

Exactly right. I see, at a minimum, a benefit to using the arrow keys to scroll through the Layers list. I also consider it a benefit to open up the possibility of adding additional navigation and manipulation enhancements.

Ken, if you can demonstrate that your workflow is more efficient than the current one, i.e.: less clicks, mouse actions, and key presses, then I will let myself be wholeheartedly convinced that your suggested workflow is the better one.

Yes, well, I'm satisfied that I've made the points I intended to and successfully defended them. I also think I've pretty well demolished the rationalizations for keeping the old behaviour which forces everyone, at all times, to use the Layers panel exclusively for moving layer content.

I'll leave the discussion with my original question still unanswered:
Why can't I have the same convenience in the Layers list that I have in the Color list and the Blend Mode list?

[Eurgail]

Tsk, tsk. You're saying that you don't even want to allow others to test the new behaviour and see how well it works? I thought that was one of the purposes of beta testing.

No, i say: We had it in Beta 10 and since then, we had protest on the one side and nothing else than false compromises on the other side,
(<, > (where the difference is the shift key), to switch the panels is just circumstantial, then it would be more usefull to use W, A, S, D as one have it in games as a direct replacement )
so i don't see any reason to try it once more for now.
The first reason of the developers (shortcut for the new search) is solved in Beta 11 another way.

I used CorelDraw the last time for ten years ago and i don't remember, i only watched Ps, Ai and Xara, and there you can find the "incorrect" behavior.

You are talking about limitations with the old behavior all the time. But where are they? Of course you can create artificial situations. But did you ever think in the last month "hmm, it would be cool, if they change the behaviour of the layers panel." while working? Seriously?

[...] And if you want to select a layer within a group you can't do it without using the mouse.

And you can't draw a stroke without using the mouse...

I also think I've pretty well demolished the rationalizations for keeping the old behaviour which forces everyone, at all times, to use the Layers panel exclusively for moving layer content.

Sorry, not for me. Your arguments work for me only on a strong logical base with all the work flow arguments faded out and creations of artificial situations, where it could be usefull to...

I'll leave the discussion with my original question still unanswered:
Why can't I have the same convenience in the Layers list that I have in the Color list and the Blend Mode list?

Because you can't select a layer in the layers panel and instantly move (or stretch) it with a few key strokes, then. It's just that simple.

[Herbert123]

Ken, if you can demonstrate that your workflow is more efficient than the current one, i.e.: less clicks, mouse actions, and key presses, then I will let myself be wholeheartedly convinced that your suggested workflow is the better one.

Yes, well, I'm satisfied that I've made the points I intended to and successfully defended them. I also think I've pretty well demolished the rationalizations for keeping the old behaviour which forces everyone, at all times, to use the Layers panel exclusively for moving layer content.

I'll leave the discussion with my original question still unanswered:
Why can't I have the same convenience in the Layers list that I have in the Color list and the Blend Mode list?

At this point, for me it is simple: if we can navigate the layers in the layer panel up and down with two keys (including jumping in and out of groups) without having to put the focus specifically on either the main window or the layer panel, then 1) it costs less clicks and key presses, and 2) everyone can select any layer with the keyboard with that method (by pressing down <shift> we can then also select a bunch of layers).

You argument fails to include workflow efficiency, and you have not demonstrated yet that your suggested method is the faster and/or more efficient one. You keep stating that your approach is a more logical one - but GUI logic should be subservient to usability and workflow speed.

Before implementing any new workflow, why not describe exactly in steps how your method would be faster to move layer content and select layers? I have already described how even the current implementation is faster (and with jumping in and out of groups equally fast) to work with as your suggested workflow. If you can come up with a workflow version that is equally fast or faster than the current one, then, and only then, I think warrants it further thought.

Oh, and you have just pointed out one of the most irritating quirks of Krita: moving layers. You cannot even move layers in Krita with the cursor keys - it is a terrible approach.