Imzip preview issue

[midora]

I'm just recovering ImZip filetype and adding new features. During tests I stumbled over a strange issue.

Assuming an image with a red Background layer and a green Layer2. All Layers are using blendmode=normal and opacity=255.

If the Background layer is set to invisible then the preview window shows just the checkerboard and not the green composite image.

The preview shows the green image if the Background layer is set to visible.

 

If I press save and load the zip later then the green composite is visible.

Because (as far as i know) the save method uses the load method to create the preview output there shouldn't be a difference between preview and what you get if you are opening the file. I dumped the layers and their attributes just before the save method returns the new document and there was no difference in the values.

 

 

I tested also with the old plugin version in the ImZip thread and this variant shows the same behavior.

Any idea if this is a plugin or a paint.net issue? Do I miss something?

 

[midora]

BTW: Since three months or so I'm fighting with the forum software. I.e. I'm clicking 'Submit reply' the software tells 'saving' but it never returns. Luckily the text is not lost and offered for the next try. Sometimes it takes an hour with several tries until the software accepts the reply. Or today I couldn't upload the image above. I always got the server error 200 (maybe a timeout?) Just now it worked.

It happens using the latest Firefox and Edge browser but only in this forum. My internet connection is fine.

[toe_head2001]

HTTP status code 200 the "OK" status, and should indicate a successful response from the server.

 

Can you post a screenshot of the response from the server when posting?

 

EDIT: here's the JSON response I got when I posted this reply:

Edited August 17, 2021 by toe_head2001

[midora]

Luckily 🥺 it's easy to reproduce in the moment. But it means that I can not post the screenshot.

The test in the dialog is

Sorry, an unknown server error occurred when uploading this file.

(Error code: -200)

 

[otuncelli]

It happens with other layer supported filetype plugins too. I've just checked Photoshop plugin. It looks like a Paint.NET issue. It also might be intended for memory-usage concerns.

Edited August 17, 2021 by otuncelli

[midora]

@otuncelli  I guess you replied to the wrong topic.

[otuncelli]

5 hours ago, midora said:

@otuncelli  I guess you replied to the wrong topic.

 

No  Here is the screenshot with Photoshop plugin. It's not a plugin issue.

 

 

 

[midora]

Sorry @otuncelli. I misinterpreted your text for some unknown reason. 😉

Thanks that you added the ps plugin example.

[midora]

Just to say. There is no issue with my ImXCF plugin (Layered GIMP files) if the background layer is invisible. That's strange.

[otuncelli]

59 minutes ago, midora said:

Just to say. There is no issue with my ImXCF plugin (Layered GIMP files) if the background layer is invisible. That's strange.

 

Probably because it overrides IsReflexive => true. Because it's a lossless filetype plugin. AFAIK Paint.NET doesn't call OnLoad method to generate preview in this case. 

 

1 hour ago, midora said:

Sorry @otuncelli. I misinterpreted your text for some unknown reason. 😉

Thanks that you added the ps plugin example.

 

No problem. I'm kinda new  

Edited August 18, 2021 by otuncelli
fix typo

[midora]

@otuncelliYou are right. ImXCF used the IsReflexive => true override. I totally forgot about this flag (I had a 5 year break in the developing of paint.net plugins). Returning false shows the same issue as the ZIP and PS plugins. I assume I used IsReflexive => true in the first version of the plugin because there was no load of xcf implemented and never changed it because the preview always looked fine. Maybe I'm updating ImXCF now.

 

There is now a strong hint that the issue is located in the paint.net application.

 

[Rick Brewster]

IsReflexive should probably just be ignored for plugins ... it's meant to be an optimization, but it's easy to get it wrong

[midora]

@Rick BrewsterAre you filing a bug? It's not quite important to fix the issue because it just happens in the rare case that the background layer is hidden. And it just impacts the preview. Open works fine. But it should be remembered.

[Rick Brewster]

As of 4.3, IsReflexive is no longer honored for plugins, and is marked [Obsolete].

[midora]

50 minutes ago, Rick Brewster said:

As of 4.3, IsReflexive is no longer honored for plugins, and is marked [Obsolete].

 

What happens if the filletype just supports save but not open?

A no preview message in the preview area and the file size is still displayed?

[otuncelli]

What happens if the plugin both supports load and save with custom loading UI? (which I'll probably release soon.)

 

I'm already using IsReflexive => false though using a stopwatch to catch chained OnSaveT=>OnLoad calls. Instead, I'm showing a message to user that informs about preview generation is not supported by the plugin.

 

protected override Document OnLoad(Stream input)
{
	return stopwatch != null && stopwatch.ElapsedMilliseconds < 100
		? GetPreviewNotSupportedDocument()
		: new MyFileTypeImporter().Import(input); // <-- this opens loading interface
}

protected override void OnSaveT(Document input, Stream output, PropertyBasedSaveConfigToken token, Surface scratchSurface, ProgressEventHandler progressCallback)
{
	// First call is always for preview generation :)
	if (stopwatch == null)
	{
		stopwatch = Stopwatch.StartNew();
		return;
	}

	// DoSomething 
	stopwatch = Stopwatch.StartNew();
}

 

 

But I can't prevent OnSaveT running after first call. Stream type checking or using reflection (StackFrame to check caller method's name which contains 'Preview' if its for preview generation) break the rules. I can't use these.

 

I think the decision of preview generation should be given to the developer. Not all formats are save/load fast or resource-friendly.

[Rick Brewster]

Stopwatch? That's a really hacky way to support this. You know, I really wish y'all would stop implementing all these hacks. It can really make things difficult for me to support backwards compatibility when e.g. migrating to newer versions of the runtime, or even just refactoring and fixing other things. If I see your plugin break, and you're doing all these hacks, I will not even bother trying to make your plugin work and I will just block it in the app. Same goes for using internal types, or SystemLayer stuff, anything breaking the rules, etc.

 

You could've just told me you needed this and asked me for some mechanism to support it so I could look into it. Ultimately it's the users of your plugins that suffer, and me (due to confused users e-mailing me bug/error/crash reports, and then having to figure out a solution), not you, so be sure to keep that in mind. Folks like @null54 ask me for things all the time and I often accommodate.

 

Save-only plugins aren't handled gracefully at this time. Never have been. Probably just shows an error. I can look into it though. In general you shouldn't have a save-only file type plugin though. Load-only sure, but save-only can't be a good experience because things like File -> Open Recent will also be broken for the user.

 

Overriding OnLoad if you haven't specified any savable extensions will just cause Load() to throw NotSupportedException. Your OnLoad() won't even be called.

 

btw many of these types of questions can be answered by using ILSpy to look at PDN's binaries.