[Added] ColorSync: Batch "Change Color Profile" gets usability improvements

[porg]

GraphicConverter ColorSync - Batch Change Color Profile usability improvements.png (133.78 KiB) Viewed 337 times

[porg]

@users: The short term goal was achieved: Help text got improved to this:

Batch Action - Change Color Profile - Improved Help Text.png (44.86 KiB) Viewed 318 times

So good news you can practically achieve profile normalization also if your assets are both image files with and without color profile information.

But you have to do it in a multi batch process:

Batch 1) You filter for files which have no color profile embedded and also no color profile reference flag set.
- This you have to do by external means, there is no filter/condition in a batch which could do that.
- That is what the option "Interpret file w/o profile as" would achieve in the action.
- Batch processes all files with unknown profiles to the profile which is the correct one (that usually means sRGB in doubt). No pixel value manipulation takes place.

Batch 2) Then process these files which now got a profile plus potentially other files which already have a profile and now convert them all to your intended target profile. The embedded profile gets changed. And pixel value manipulation occurs with the method you choose (usually: perceptual).



@forum_adm : Do you plan to implement "Interpret file w/o profile as" into the batch action so that you can treat mixed assets in one pass?

[forum_adm]

I added to build 5679 a separate batch. This avoids breaking of any old saved batches.

Screenshot 2022-11-28 at 10.25.02.jpg (127.95 KiB) Viewed 313 times

[porg]

Change Color Profile
• I note that you extended the help text with:

Image has the same color profile:
- Nothing is done.

It's good that you are that explicit! No questions remaining to anyone. Great!

Assign Color Profile if Image has no Profile

Pro/cons for putting this into an own action:
Users who explicitly search for "assign + profile" will find it. Only few will expect that under "change + profile".
On the other side you could have simply renamed the action to "Assign or Change Color Profile"
Nevertheless for a modular system like a batch conversion engine the minimalistic approach is usually better and keeps things flexible.
On the other side a single integrated batch action would only require one help text instead of help texts per action with slight overlap. More editorial work on the long run.

Under the assumption that this remains a standalone action, please adapt the help text slightly:

Current text:

Assign the following profile if the image contains no embedded or reference flag in the metadata and no automatic assignment in the preferences:

Proposed revised text:

If the image contains no color profile information (neither embedded nor as a reference/flag) and the preferences for opening files foresee no automatic color profile assignment, then assign the following profile:

[forum_adm]

I modified the text for build 5682.

[porg]

And what's your take on the issue of "one integrated vs two separate batch actions"?

[forum_adm]

I want to avoid to brake old saved actions with the usage of change color profile. So, I just use the two actions.

[porg]

Maintaining compatibility per se is a good argument, but not a valid argument in this case:
• The default for the first option is: Interpret file w/o profile as: [ As set in preferences ▾ ]
• Which produces exactly the same outcome as the saved batch action with just the two options "Profile" and "Conversion Priority".

So a seamless upgrade path would be possible:
• Either on the app upgrade or when opening an old batch action, it gets converted to the new one, with the first key having the default value, which changes nothing in the behavior.
• And when opening the batch action the user can then change the first option to a different value, if desired.

Out of curiosity: Does GC have a general framework for running update scripts on first run of the new version or first invocation of a feature which was updated? An update script which then converts old config files or preference-options to the new appropriate ones? Given GC is out there for a long time already, I almost suspect it has such a framework, as it must have undergone many upgrade steps over time which may require this.

If you want to stick with the two separate batch actions, it's a little less clean, and potentially more maintenance effort in the long run, but quite ok as a compromise.