Problem with overwrite filter settings via the CLI

Hello,

first of all thanks for integrating such a feature. If working properly this could become a game changer.

I) I am having trouble with the initial release:

If I override one value, let’s say enable sharpen, it seems like all the other values are gone. The image that is output will no longer have enhance,… (and is output with its original resolution).

My guess is that, instead of using the detected autopilot settings and then changing just that one parameter it will actually begin with fresh settings.

Steps to reproduce issue:

  1. Run

tpai c:\Windows\Web\4K\Wallpaper\Windows\img0_1024x768.jpg -o c:\Projects --showSettings

You will get a correctly upscaled output file with 4004x3003 resolution.

  1. Now just try to override only sharpen via

tpai c:\Windows\Web\4K\Wallpaper\Windows\img0_1024x768.jpg -o c:\Projects --showSettings --sharpen

It will output the JSON of the original settings showing enhance enabled=true, width=4004
And will output “Overwriting Sharpen enabled to true”.

But in the output file you will see, that the resolution of the file is still 1024x768, so no other filter was applied (I would guess only sharpen was applied, at least according to the override output; but at 1024x768 you can’t see any sharpening of course).

.

II) Also: As a user I would have expected the JSON output of --showSettings to already include the overrides by the command line, let’s say “–sharpen: param1=1”. But it says:

“Sharpen”: {
“auto”: true,
“compression”: 0.5520246028900146,
“deselectedByUpscaling”: false,
“enabled”: false,
“isLens”: true,
“mask”: false,
“model”: “Sharpen Standard”,
“param1”: 0.16269992291927338,

Even though I did an override for those 2 sharpen settings.
It outputs “Overriding Sharpen…” as additional text messages after the JSON output. But the advantage of outputting the final composite as a complete JSON output would be that one could actually save that in it’s entirety to a document - what was actually applied - for later use.

III) I also noticed, that If I use the following parameter it will output “Overwriting Sharpen enabled to true” twice:

tpai c:\Windows\Web\4K\Wallpaper\Windows\img0_1024x768.jpg -o c:\Projects --showSettings --sharpen: enabled=true

Thanks in advance!


Topaz Photo AI [v2.1.0] on [Windows]

1 Like

Hello @anthony.lawn - thanks for the like. I assume, you are part of the team developing that feature :wink:
I found an additional bug in this area, If I try to explicitly disable a filter, processing will fail altogether:

tpai c:\Windows\Web\4K\Wallpaper\Windows\img0_1024x768.jpg -o c:\Projects --showSettings --sharpen: enabled=false


Overwriting Sharpen enabled to true
Overwriting Sharpen enabled to false
Error | Filter initilization failed.
> Error | [CLI] Engine canceled processing

@adam.mains Question: was this addressed/fixed in 2.1.1? (I couldn’t find it in the release notes) If not, when will it be fixed? Thanks.

[addendum: I just tested in in 2.1.1 - still the same problem, once I enabling sharpen via command line the rest stops working, no upscale and so on - CLI therefore unusable again, both in 2.1.0 and 2.1.1 :frowning: ]

@adam.mains and @tim.he - will this be fixed in 2.1.2? Thanks.

Hello,

Unfortunately this is not scheduled to be in 2.1.2, and Anthony is on leave until late December. I am not sure when we’ll be able to look at it since I have a lot of other things going on at the moment, but if I have some free time I can maybe take a look.

Hello @adam.mains , late December is terrible news :sob:
I’m waiting week for week for a fix to this.

It would be great if you could have a look. It should be pretty easy to fix. It seems that the object that holds the detected autopilot values (which are still correctly displayed in the CLI) is thrown away when replacement (of one or more values) takes place; as if a fresh (blank) instance is created.

In this order it should work:

  1. detect autopilot values
  2. change the values that are overwritten (in the object that is already there from no. 1)
  3. display all current values in the CLI output (directly from the object that was created in No. 1 and was changed in No. 2)
  4. Run processing

As for the second problem with disabling a filter like

-sharpen: enabled=false

resulting in

Overwriting Sharpen enabled to true
Overwriting Sharpen enabled to false
Error | Filter initilization failed.
> Error | [CLI] Engine canceled processing

it might be enough to just disable the “implicit enabling” that automatically occurs when using “-sharpen” (or any other filter without additional arguments to overwrite values).
I think it’s OK if a user has to use -sharpen: enabled=true to explicitly activate it, without a convenience syntax.

Thanks in advance!

So I’m not 100% sure at the moment, but it seems based on the code comments that the way it is working is the intended behavior. Specifically the flow is that after AP finishes, it overrides the entirety of AP with the manual values. This means anything missing from the manual commands is disabled. In this implementation, manual overrides auto entirely, it doesn’t add onto the auto settings.

I can change this to not disable filters that aren’t specified so it becomes an auto + manual flags instead of just manual flags, but I am not certain this would stay around.

For your workflow, is it possible to add all the flags you want, or do you rely on AP to fill in the gaps? In your case, doing --sharpen --upscale gets me both correctly.

Edit: I may be able to add another flag like --override that changes it to completely override AP (current behavior) and make the default behavior auto + manual, but trying to get confirmation from Anthony if there are issues with that.

Hi,

that would be perfect. Right now the user thinks that only specific settings are overwritten, as it says in the --help command “you may specify settings to override”.
And also because the CLI first it displays the AP values when e.g. used in conjunction with --showSettings and then only outputs that some things have been changed afterwards (like “Overwriting Sharpen Enabled True”).

But in the end the AP is not used at all, as you say and one has to specify everything manually (which is next to impossible in most situations).

Such an override switch (as an alternative to specifying everything manually) would do the trick.

P.S. Did you find a solution to -sharpen: enabled=false (which would be a use case when using the suggested --override)

Thanks in advance!

I can try to add that to this release real fast.

I am not sure how to fix this in all cases. For instance, if AP only enables sharpen and you specify sharpen is disabled it seems like the correct thing to do is fail, especially if you add --override.

Cool, thank you!

Ok, I understand. So the engine error occurred because it starts from a blank template, and since I had no filters enabled (and only tried to disabled one, which was already disabled) it got the engine error - because it had nothing to do.

Then it could work. I guess only the implicit “enabling” and then “disabling” that happens when using -sharpen: enabled=false is redundant.

Thanks again!

Hello @adam.mains - thanks for the alterations to the CLI, first tests have shown it to be usable! :+1: :+1: :+1:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.