Bug fix release 13-Mar-2019

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

Moderator: jsachs

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

Bug fix release 13-Mar-2019

Post by jsachs »

I have posted a new release (13-Mar-2019) in full installer and executable-only versions. Minor changes to help file.

The changes (taken from the update log) are:

Histogram Tool: fixed several problems and added support for waveforms as an alternative to histograms. The user interface was also changed slightly – see the updated help file for more information. You will need to do a full install to get the one new bitmap for the histogram tool and the updated help file.
Jonathan Sachs
Digital Light & Color
davidh
Posts: 835
Joined: June 9th, 2009, 2:16 am

Re: Bug fix release 13-Mar-2019

Post by davidh »

I have replaced the version PWP 8-Mar-2019 with the version PWP 13-Mar-2019. After restoring the last workspace I got the error message:

"File has been modified since last File Open: C:\Users\username\Documents\Picture Window Pro\Frames and Tiles\ Gray Tiles\ Rip Rap.tif."

When I click OK in the error box, the PWP crashes. When I click Storno, the loading goes on with some Frame images ending error red.

The original Frame settings of the errored images was:
Profile: Tripple Bead
Color/Image: Rip Rap.tif
Tint icon: gray 3x 29.4, Tile,
Scale factor: 2.9

After reopening the Frame thumbnails the Frame setting is:
Profile: Tripple Bead but real Frame in preview is solid black with no profile
Color/Image: empty
Tint icon: missing,Tile
Scale factor: 1.5

1. Only the Frame transformations with a loaded Image (here Rip Rap.tif) end up in error displaying the solid black frame.
2. The Frame transformations thumbnails without any loaded Image do not error up and display the profile (Tripple Bead) correctly.
3. When the red thumbails are closed again, they got refreshed and not are showing the error any more, however their frame stays solid black - the link to the loaded image is lost.

Has there been made any unannounced changes to the Frame transformation?
I am asking before I upgrade to the last version on my main PC.
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Bug fix release 13-Mar-2019

Post by jsachs »

I have not intentionally changed Frame since Mar 8, although over time there have been a number of problems fixed that dealt with incorrect saving and restoring of settings files.

The saved script file contains a File Open command for Rip Rap.tif which includes the time and date it was last modified. It may be possible that re-installing the built-in files such as Rip Rap could be updating the modification date, so check what the date is on this file on your computer and let me know. The error check is a warning that the file may have been modified since it was last used. I will check the code that handles OK to see why it was crashing. I assume Storno is Czech for Cancel. Once I fix this, hopefully the other problems may go away.
Jonathan Sachs
Digital Light & Color
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Bug fix release 13-Mar-2019

Post by jsachs »

I found the cause of the crash on OK, which is what you click if you want to ignore the fact that the date changed. On Cancel, the File Open for Rip Rap.tif becomes a red error and any transformation such as Frame that depends on it will also yield error. I will upload a new version tomorrow and you can let me know if there are still problems.
Jonathan Sachs
Digital Light & Color
davidh
Posts: 835
Joined: June 9th, 2009, 2:16 am

Re: Bug fix release 13-Mar-2019

Post by davidh »

The Rip Rap.tif file date is 17-Jan-2013. It was unchanged after installing the latest PWP version of 14-Mar-2019

--------------

PWP version 14-Mar-2019 observations:

The warning message "File has been modified since last File Open:".....

Clicking OK to accept the modification date change preserves the File open for Rip Rap.tif and all the workflow that depends on it.
Clicking Cancel makes the Rip Rap.tif a red error including all the images that depend on it, as described in the post above.


This brings me to the following question, however.
If an built in image or texture like Rip Rap.tif was changed for some reason (e.g. its pattern) over the time, then accepting the modification would change all the images that depend on the it, making the final output a different image.
Rejecting (cancelling) the modification would disable the texture, but it would not be reloadable because it had been replaced by its changed version.

In either case the previous original version of the image or texture will be lost, unless the option Save Workspace Script with Image Copies had been used. I am right?

Another question is why inbuilt image or textures' date is tested and overwriten with each PWP8 version? I would think once they are created and built in, they should stay unchanged in their original form and any other similar images or textures should only be different versions of them.
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Bug fix release 13-Mar-2019

Post by jsachs »

17-Jan-2013 is the correct date for the original file. I'm wondering if there is a problem with daylight savings time making it look like the file time changed, although all date and time comparisons are supposed to be based on UTC.

>> In either case the previous original version of the image or texture will be lost, unless the option Save Workspace Script with Image Copies had been used. I am right?

Yes
Jonathan Sachs
Digital Light & Color
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Bug fix release 13-Mar-2019

Post by jsachs »

Can you take a look at the workspace script file -- near the top should be a line like this:

image index 4 caption ″Rip Rap.tif″ saved_as ″″ saved_on ″″ parent -1 bypass -1 same_size 0 size_specific 0 breakpoint 0 n_inputs 0 n_masks 0 command ‴file_open 0 n_files 1 current 0 show_progress 1 from_default 0 file1 ″D:\Temp\Rip Rap.tif″ time1 ″20190314 002153″‴

Just let me know what it says at the end of the line after time1.
Jonathan Sachs
Digital Light & Color
davidh
Posts: 835
Joined: June 9th, 2009, 2:16 am

Re: Bug fix release 13-Mar-2019

Post by davidh »

the last script saved before upgrading to PWP 14-Mar-2019 says:
time1 ″20130117 150330″‴

the new script saved after upgrading to PWP 14-Mar-2019 says:
time1 ″20130117 160330″‴

----------------------


>> In either case the previous original version of the image or texture will be lost, unless the option Save Workspace Script with Image Copies had been used. Am I right?

Yes <<


I wonder if there might arise a reason to change the original built-in images or textures intentionally.
Saving scripts with image copies may take a lot of space - I sometimes have more than 20 versions of one workspace script to keep the number of branches in the script as low as possible for performance reasons.

Perhaps a changed file of this kind could create automatically another version instead of overwriting the original? Reinstalling PWP would just compare the date of creation, not the time. If the date was the same, it would do nothing, othervise it would create a new version.
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Bug fix release 13-Mar-2019

Post by jsachs »

As I suspected, there is a one-hour difference, presumably due to the recent switch to daylight savings time. My guess is this is a bug in Windows as it is supposed to be converting the file time to UTC (a.k.a. GMT) which does not have daylight savings time and is one standard time zone.

I could probably make PWP ignore differences of precisely one hour to fix this.
Jonathan Sachs
Digital Light & Color
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Bug fix release 13-Mar-2019

Post by jsachs »

Is the disk you installed to formatted with NTFS or with FAT?

There seem to be issues reported with Windows being off by an hour when DST switches in, especially if you don't restart your computer every morning. There are also differences between NTFS and FAT formatted volumes - I remember seeing this same problem with files stored on CD-ROM years ago.
Jonathan Sachs
Digital Light & Color
Locked