Bug fix release 29-Dec-2018

Please use this forum to post bug reports, feature requests, tips, etc. for beta versions of Picture Window Pro 8

Moderator: jsachs

Post Reply
jsachs
Posts: 1623
Joined: January 22nd, 2009, 11:03 pm

Bug fix release 29-Dec-2018

Post by jsachs » December 29th, 2018, 1:04 pm

I have posted a new release (29-Dec-2018) in full installer and executable-only versions. No changes to help file.

The changes (taken from the update log) are:

Frame: fixed remaining problems with tinting gray tiles.
Jonathan Sachs
Digital Light & Color

davidh
Posts: 557
Joined: June 9th, 2009, 2:16 am

Re: Bug fix release 29-Dec-2018

Post by davidh » December 29th, 2018, 2:58 pm

I am sorry but it looks like loading saved settings ignores textures and images used as patterns in frame and mats.

1. frame an image into a simple dark gray Tripple Bead profile, click OK.
2. frame another image into a Beveled profile, but this time load a gray tile e.g. Wood Texture, tint it light, save the settings, click OK.
3. go back to the first image, reopen the Frame dialog and load the saved settings -> the frame profile and the color change all right, but the Wood Texture pattern is missing, the texture file does not load.

4. go back to the second image (step 2) and replace the Wood Texture with an image, save settings, click OK
5. repeat the step 3 and load the latest settings -> again the frame profile changes all right, but the pattern created by the image is missing, the image does not load, the frame is tinted with the light color used in the step 2 instead

This is not limited only to the frame. The mats display just their default grays.

-------

This brings up the question whether auxiliary images and textures should be part of the saved settings.
In the examples above both the wood texture and the image were already part of the workspace so I would expect them to be loaded.

But what if a saved settings was used in another workflow with no preloaded texture, as was done in the step 2? In that situation default values should probably be used, which seems to me is exactly what happens in the steps 3 and 5.

jsachs
Posts: 1623
Joined: January 22nd, 2009, 11:03 pm

Re: Bug fix release 29-Dec-2018

Post by jsachs » December 29th, 2018, 3:28 pm

The frame and mat texture images are auxiliary inputs and do not get saved in settings files.

While I suppose it might be possible to add their pathnames to the settings file if they were images that have just been opened, if the frame or mat images were operated on by a transformation, then all of that transformation's setting would also have to be saved and so on for any other images they depend on. This is exactly what script files do which is why I recommend using them if you need to save auxiliary inputs.
Jonathan Sachs
Digital Light & Color

davidh
Posts: 557
Joined: June 9th, 2009, 2:16 am

Re: Bug fix release 29-Dec-2018

Post by davidh » December 30th, 2018, 11:56 am

Only now do I realize I should have mentioned an alternative and powerfull function for the situations where an auxiliary input is already part of the workspace. It is the group of Set as, Copy or Move to Destination commands in the context menu.
It is quite funny that I forgot about those commands because I use them very often. In fact it is my preferable method.
Across workspaces, however, Save Settings As... will have to be used especially where a lot of values need to be set.

This brings be to a question again.
Would it be worth considering, in a future, to enable defining short strings of workflow which could be appended to existing workflow trees or branches?
They would be kind of semi-universal prefabricates or workflow blocks, bringing along their own auxiliary inputs.

jsachs
Posts: 1623
Joined: January 22nd, 2009, 11:03 pm

Re: Bug fix release 29-Dec-2018

Post by jsachs » December 30th, 2018, 2:04 pm

The minimum collection of images you can save and get everything back the way it was is a script (as opposed to a workspace script which saves everything). If you don't clear the workspace before loading a script, it gets merged with the existing images although I have not tested this much. In thinking about it, the case where one or more of the images is already present could be a problem. You could then use the Copy transformation to incorporate the script result into the existing workspace.

It would be nice in the future if there was something closer to a set of building blocks that snap together effortlessly, but right now I don't know how to make that work. One approach might be to have a stack of image trees something like a 3-D spreadsheet. You could drop a script onto a new layer and refer to images across layers.
Jonathan Sachs
Digital Light & Color

davidh
Posts: 557
Joined: June 9th, 2009, 2:16 am

Re: Bug fix release 29-Dec-2018

Post by davidh » January 1st, 2019, 1:06 pm

What I had in mind was something more simple (I wonder..). Those building block scripts I mentioned would be composed of a small (even limited) number of transformations and could only have auxiliary inputs like textures, etc.. no top level input images - they would not create trees, they would be just pre-fabricated parts. This would make it possible to open them and append or insert them anywhere into already existing trees.

For that the current command Set as Destinations could be used. And it would probably need to add one more command like Append to Destination, which would open a window with a list of the block scripts.

Regular or frequent finalizing or initializing tranformations might be especially good candidates to similar short blocks.

They couuld be created with any input image or a file but saved without it.

Post Reply