PicturesToExe v5.00 beta #3

[alrobin]

Igor,

"Transparent for click" in beta 3 doesn't seem to be working properly. It doesn't seem to have any effect on the ability to click on an object to highlight it and pan, zoom or rotate it.

[alrobin]

Possible Bug in Ordering and Interdependence of Objects

When zooming out of a slide containing several objects, one of the objects (text picture) gets displaced to the visible screen even though it is a child of an image object and located on this object off the screen. When it zooms out far enough to become visible on the screen it instantly "pops" from the displaced location to where it is suppose to be. It appears to me that it is a problem in the dependence of objects (for awhile the text picture object seems to be on the top level, then becomes the child when it comes into view).

Steve,

I'm not able to reproduce the effect you describe. Could you please either send me a copy of your ".pte" file, or download this Test Example (only 5 kb). Or, set up your situation in my test example and email it back to me. My home address is alrobin@alrobinson.com .

Could it have something to do with the parameters you are using in "Proj Options / Screen / Aspect ratio"?

[sanewcomb]

Possible Bug in Ordering and Interdependence of Objects

Could it have something to do with the parameters you are using in "Proj Options / Screen / Aspect ratio"?

Thanks for your reply Al. It is not a result of the project parameters. In trying to reproduce it with your file I discovered what was happening.

Not all of the settings of the parent are passed/connected to the child. In this case, Opacity of the child is independent of the parent. I'm not sure if this is intended or not, but it goes against the conceptional idea of object inheritance. This can cause confusion and lead to unintended results.

Looking at the other settings:

Inherited by Child

Pan

Rotate

Zoom

Not Inherited by Child

Opacity

Center

A case could be made either way for Opacity, but it's hard to understand (for me anyway) why the Center setting shouldn't be inherited. Ideally the child should inherit the state the parent is when the child is created and have an option of overriding if desired. There are pros and cons to how it should be setup, but whatever is decided it should be spelled out in the docs/tutorials if only some settings are inherited.

Steve

[sanewcomb]

The zoom is absolutely linear. What you are experiencing is normal in that the smaller an object gets the more it "appears" to move away faster and the larger it gets the more it "appears" to be moving slowly. This is a well known psychological issue.

Lin,

I don't think it's the psychological issue in this case, but it may be a terminology issue.

I have thought about this more and think I understand what is going on. The software emulation of zooming, call it soft-zoom, appears to be the linear interpolation of the PERCENT zoomed parameter. So to go from 100% to 200%, the software goes from 100% to 125% in a quarter of the time, from 100% to 150% in half the time and so on. This does not result in a constant change in the distance between the viewer and image (or rather effective distance since it is all happening on a screen at a fixed distance).

And this is not what happens in the real world when you "zoom" something. By zoom I mean change the distance between the object and viewer. Try it with your camera, or better yet a video camera. Hook it up to a monitor and move in and away from a subject. You will see the image on the monitor does not slow down as you get closer to the subject (unless you slow down the camera as you approach).

I'm afraid the software programmers that originally started calling the linear interpolation of %zoom scale as linear zoom have confused the situation. Doing this does not result in a constant rate of change (linear) of the image size. To acheive a true constant motion of the image in software requires a non-linear interpolation of the %zoom scale mathematically, or by manipulating (possibly with a linear function) a different image or graphic engine parameter. So what they are calling linear is really non-linear motion. There is often a desire to change the speed at either end of the zoom process to add effect, usually a deceleration (for a soft landing so to speak). Adding even more acceleration (or decleration) to this soft-zoom function still results in non-linear motion, only more of it. And it leaves no term for true constant motion.

In an attempt to clear up the confusion with the term linear, I would like to suggest a different term to mean a constant rate of zoom in real terms (not percent scale). It could be "constant zoom" or "steady zoom". It would mean the effective distance from the image to the viewer would change at a constant rate and would be very useful in zooming a series of images as well as offering a real life zoom to the software package. I don't know how a rostrum camera is actually used, but I think many of the zooms you see between pictures are done with a constant speed, whereas the ones that zoom to (or from) a stop use deceleration (acceleration) to avoid abrupt stops (starts).

Steve

P.S. I think you've got the psychological effect reversed. When you are close to a subject (while it appears large) and move away at a constant speed, it appears to be moving away faster than when, at some time later and it is quite small, it appears almost motionless on the horizon, even though you are still moving away from it at a constant speed. If the same effect were in play with the soft-zoom process, the "farther" the image got from you (zooming out) the slower it would appear to move (or change size), but the opposite is observed.

[alrobin]

Possible Bug in Ordering and Interdependence of Objects

Not all of the settings of the parent are passed/connected to the child. In this case, Opacity of the child is independent of the parent. I'm not sure if this is intended or not, but it goes against the conceptional idea of object inheritance. This can cause confusion and lead to unintended results.

Steve,

You are 100% correct - this has been pointed out by someone already, and Igor will probably be making some adjustments in future releases of PTE. However, PTE is an application, not a programming language, so doesn't necessarily have to follow all the usual rules of inheritance, etc. Glad you solved the mystery of what was happening in your show.

I am sure that all of the operational features of v.5 will be thoroughly covered in various tutorials and explanations on the forum once the design is finalized, likely in a few months' time.

Lin,

I don't think it's the psychological issue in this case, but it may be a terminology issue.

I have thought about this more and think I understand what is going on. The software emulation of zooming, call it soft-zoom, appears to be the linear interpolation of the PERCENT zoomed parameter. So to go from 100% to 200%, the software goes from 100% to 125% in a quarter of the time, from 100% to 150% in half the time and so on. This does not result in a constant change in the distance between the viewer and image (or rather effective distance since it is all happening on a screen at a fixed distance).

Steve,

I have done tests with specially constructed grids to test the linearity, and I can agree with Lin that the actual 2-dimensional "velocity" of any "movement" on screen, whether due to panning, zooming, or rotating, is perfectly linear. Any 3-dimensional perceptions are therefore psychological.

[Lin Evans]

Lin,

I don't think it's the psychological issue in this case, but it may be a terminology issue.

I have thought about this more and think I understand what is going on. The software emulation of zooming, call it soft-zoom, appears to be the linear interpolation of the PERCENT zoomed parameter. So to go from 100% to 200%, the software goes from 100% to 125% in a quarter of the time, from 100% to 150% in half the time and so on. This does not result in a constant change in the distance between the viewer and image (or rather effective distance since it is all happening on a screen at a fixed distance).

And this is not what happens in the real world when you "zoom" something. By zoom I mean change the distance between the object and viewer. Try it with your camera, or better yet a video camera. Hook it up to a monitor and move in and away from a subject. You will see the image on the monitor does not slow down as you get closer to the subject (unless you slow down the camera as you approach).

I'm afraid the software programmers that originally started calling the linear interpolation of %zoom scale as linear zoom have confused the situation. Doing this does not result in a constant rate of change (linear) of the image size. To acheive a true constant motion of the image in software requires a non-linear interpolation of the %zoom scale mathematically, or by manipulating (possibly with a linear function) a different image or graphic engine parameter. So what they are calling linear is really non-linear motion. There is often a desire to change the speed at either end of the zoom process to add effect, usually a deceleration (for a soft landing so to speak). Adding even more acceleration (or decleration) to this soft-zoom function still results in non-linear motion, only more of it. And it leaves no term for true constant motion.

In an attempt to clear up the confusion with the term linear, I would like to suggest a different term to mean a constant rate of zoom in real terms (not percent scale). It could be "constant zoom" or "steady zoom". It would mean the effective distance from the image to the viewer would change at a constant rate and would be very useful in zooming a series of images as well as offering a real life zoom to the software package. I don't know how a rostrum camera is actually used, but I think many of the zooms you see between pictures are done with a constant speed, whereas the ones that zoom to (or from) a stop use deceleration (acceleration) to avoid abrupt stops (starts).

Steve

P.S. I think you've got the psychological effect reversed. When you are close to a subject (while it appears large) and move away at a constant speed, it appears to be moving away faster than when, at some time later and it is quite small, it appears almost motionless on the horizon, even though you are still moving away from it at a constant speed. If the same effect were in play with the soft-zoom process, the "farther" the image got from you (zooming out) the slower it would appear to move (or change size), but the opposite is observed.

Hi Steve,

I haven't tested beta 3, but the earlier betas tested correct in linear zooms, by Al and in my own tests. I wouldn't totally rule out any issues but Igor has also said that it's true linear zoom. Of course non of us except the developers really know precisely what is going on in the program but we can be sure that with the inclusion of non-linear zoom in the release version that we should be able to get whatever effect we really want. Of course with keypoints we can actually alter the visual effect as we see fit even now. I sometimes change the zoom percent nearing the end of a zoom out so that in the final few seconds the objects appear to slow. With non-linear zoom incorporated this should be easier to accomplish.

Best regards,

Lin

[Ken Cox]

Steve

see

http://www.picturestoexe.com/forums/index....hl=linear+zooms

http://www.picturestoexe.com/forums/index....Beta+5+Tutorial

ken

[Igor]

Steve,

Thank you for letting me know about this questions!

1) Speed.

Currently all speeds (Pan/Zoom/Rotate/Opacity) are absolutely linear. In the next betas we will add other non-linear modes (Accelerate/Decellerate, and custom values).

2) About child objects. I've carefully explorered your test project you've sent me. Yes, I see that "Az Hot Springs Hotel Canyons" text-object moves a little different that its parent object at the end of a slide.

But it happens because 2nd and 3rd keypoints of this text-object have difference Zoom sizes and Pan values. Just remove 3rd keypoints (located at 00:20:00) and this object will look as part of main map. Or adjust 3rd point with same Pan/Zoom values.

Excuse me if I didn't understand the problem rightly.

Dominique,

I apologize for the delay with my answer!

I added both your suggestions to my TODO list.

We leaved moving of all keypoints of object(s) to v5.10 and we'll try to add "Nearest resizing" option for objects. It will solve problem with masks you and Ebenist found.

Al,

"Transparent for click" in beta 3 doesn't seem to be working properly. It doesn't seem to have any effect on the ability to click on an object to highlight it and pan, zoom or rotate it.

Please explain me when it doesn't work? Try to create new project, add one slide, and insert object. Set "Transparent for Click" mode. Select main image. Now you can't visually select second object. Only via Objects list.

p.s. we almost finished music, synchronization and all related modes, but we spent more time than expected. Also today we fully finished AVI video output, with HD-1080 mode (1920x1080 and 1440x1080) and some improvements for more picture quality. We realized several "old" transition effects. And we wrote a 50% of code for second CPU based graphical engine (for old video cards). Also startup window, password dialog, help window and date/trial functions are ready.

[alrobin]

Steve,

Please explain me when it doesn't work? Try to create new project, add one slide, and insert object. Set "Transparent for Click" mode. Select main image. Now you can't visually select second object. Only via Objects list.

p.s. we almost finished music, synchronization and all related modes, but we spent more time than expected. Also today we fully finished AVI video output, with HD-1080 mode (1920x1080 and 1440x1080) and some improvements for more picture quality. We realized several "old" transition effects. And we wrote a 50% of code for second CPU based graphical engine (for old video cards). Also startup window, password dialog, help window and date/trial functions are ready.

Igor,

Sorry for the confusion - I had checked "Ignore not-selected objects" in "Tools", and that is why the other option didn't work. I had forgotten that they are supposed to work together. Everything is fine again.

Your progress is good news. PTE is a great program, and soon will be even better. Good luck in the rest of the design effort. We eagerly await testing it for you!

[Lin Evans]

For Steve

I believe I know why you see non-linear zooming. I've just tested Beta 3 and the zoom is absolutely linear, BUT keypoints which are set then moved either by sliding them or by changing the values of time for a previously set keypoint do not change zoom values. They keep their original values (zoom values associated with the actual position of the mouse cursor on the timeline whien clicked to add keypoint) when they are either moved by clicking on the "flag" and sliding the keypoint to a different time or by placing a keypoint then typing in a particular time so that the keypoint is moved.

When this happens, unless perchance the perfect time desired was selected, the movement between keypoints ceases to be linear when viewed from the perspective of the entire timeline. It's linear between keypoints, but not linear from start to finish.

Perhaps Igor might consider a switch which would allow the option of keypoints which are moved to be associated with the zoom which "should" be at a particular point were there no keypoints between the beginning and end of the timeline.

Best regards,

Lin

[dagrace]

For Steve

I believe I know why you see non-linear zooming. I've just tested Beta 3 and the zoom is absolutely linear, BUT keypoints which are set then moved either by sliding them or by changing the values of time for a previously set keypoint do not change zoom values. They keep their original values (zoom values associated with the actual position of the mouse cursor on the timeline whien clicked to add keypoint) when they are either moved by clicking on the "flag" and sliding the keypoint to a different time or by placing a keypoint then typing in a particular time so that the keypoint is moved.

When this happens, unless perchance the perfect time desired was selected, the movement between keypoints ceases to be linear when viewed from the perspective of the entire timeline. It's linear between keypoints, but not linear from start to finish.

Perhaps Igor might consider a switch which would allow the option of keypoints which are moved to be associated with the zoom which "should" be at a particular point were there no keypoints between the beginning and end of the timeline.

Best regards,

Lin

Thank you, Lin, for shedding some light on this. I thought I had noticed it too, but I never posted anything to the forum to see why.

I agree that this would be a nice change for Igor to make, so that when a keypoint is moved, the "zoom value" is updated or interpolated.

In practice I will rarely the the keypoint right the first time, so most of them will be moved, adding to the non-linear look and feel.

Thanks again for doing the research!

[Lin Evans]

Thank you, Lin, for shedding some light on this. I thought I had noticed it too, but I never posted anything to the forum to see why.

I agree that this would be a nice change for Igor to make, so that when a keypoint is moved, the "zoom value" is updated or interpolated.

In practice I will rarely the the keypoint right the first time, so most of them will be moved, adding to the non-linear look and feel.

Thanks again for doing the research!

Hi David,

We wouldn't want it to be an "only' updated situation because this would destroy some of the great flexibility offered, but it would be convenient to have a software choice so it would be easier to keep linear zoom if that's what we wanted for the individual slide. The fact that we can choose to have differential zoom on the X and Y axis lets us create interesting effects such a flipping the coin or compressing the curtains when we draw them on a stage for an opening effect. There are other things which we can do by having differential zooms which don't necessarily correspond to keypoint positions on the time lines, but a choice could be nice when we do want to maintain the linearity of a zoom while having a keypoint inserted for some other possible purpose.

Just the act of inserting a keypoint sets a zoom relationship along with it so even if we intend no particular action and accidentally have a keypoint set somewhere between the zero and timeline end, we will affect the linearity unless that keypoint is placed precisely at the time we end up selecting. Any movement or change in the time for that keypoint will necessarily require us to calculate the precise zoom (assuming there is a zoom change from the start to end point) for that slide unless we exercise great care by sliding the little arrow back and forth while observing the time before inserting the keypoint. Having an optional switch to synchronize the keypoint and zoom which "should" be there at that point to insure linearity of the zoom could be a good thing I think.

Best regards,

Lin

[jevans]

To Members of the Forum,

I like all forum members, eagerly await the next beta version and, hopefully in the near future, the final Version 5 PTE. However Igor's task appears to be a difficult and complex one judging by the time it is taking to reach a fully useable Beta version. Although I note and greatly admire the efforts and expertise of forum members in seeking out faults and suugesting improvements, I wonder whether the number of requests for additional or modified features might not be distracting Igor from the fundamental task of acheiving a fully working Beta version. As someone who was involved with software design when I was working, I know how sotware design is never finished. There is always just one more tweak that seems to be so desirable. Remember the old saying, "the camel is a horse designed by a committee".

So this is just a plea to let Igor finish his current work before considering any further "improvements or additions". There will be so much to explore when we get the next Beta version and plenty of opportunity to explore improvements. I am sure, like me, you all have projects on hold waiting for the availability of the finished Version 5.

[Lin Evans]

To Members of the Forum,

I like all forum members, eagerly await the next beta version and, hopefully in the near future, the final Version 5 PTE. However Igor's task appears to be a difficult and complex one judging by the time it is taking to reach a fully useable Beta version. Although I note and greatly admire the efforts and expertise of forum members in seeking out faults and suugesting improvements, I wonder whether the number of requests for additional or modified features might not be distracting Igor from the fundamental task of acheiving a fully working Beta version. As someone who was involved with software design when I was working, I know how sotware design is never finished. There is always just one more tweak that seems to be so desirable. Remember the old saying, "the camel is a horse designed by a committee".

So this is just a plea to let Igor finish his current work before considering any further "improvements or additions". There will be so much to explore when we get the next Beta version and plenty of opportunity to explore improvements. I am sure, like me, you all have projects on hold waiting for the availability of the finished Version 5.

Hi Jeff,

I think Igor realizes that many of the suggestions are not intended for immediate concern but rather for consideration as the software develops. We all know that software is always a work in process so the suggestions may or may not eventually be implemented.

As a former software developer myself, I fully appreciate the issues and pressures associated with development and deadlines for releases, but wringing out new software is always an iterative process of discovery and tweaks. One of the questions which keeps popping up is the issue of linearity of zoom and Igor has already told us that there will be non-linear features in either the next beta or at least by the finished product.

The discovery that insertion of keypoints then subsequent movement of these keypoints may adversely affect zoom linearity is something which we all need to be aware of and is also something which could possibly account for a number of these prior questions and some potential confusion. Whether or not it's a good idea to have a "choice" switch for synchronization of keypoint and zoom is something Igor and Alecksy will need to consider and act on or not, but the awareness of the issue is better handled earlier rather than later in the development thought process.

I agree that it's better to not overwhelm the development team with suggestions for change - but I believe its prudent to bring up issues which bear on performance and which can cause confusion if not understood.

Best regards,

Lin

[jevans]

I agree that it's better to not overwhelm the development team with suggestions for change - but I believe its prudent to bring up issues which bear on performance and which can cause confusion if not understood.

Best regards,

Lin

Hi Lin,

Yes of course I agree with you. Just wanting to try to curb too much enthusiasm for new features. I was once involved in the design of a major software suite for which there was a detailed specification prepared initially with consultatation with the intended end users We made the mistake of releasing a number of beta versions and the users bombarded us with requests for changes/new features which were in the "desirable" but "not essential" category.

Regards

Jeff

[Lin Evans]

Hi Lin,

Yes of course I agree with you. Just wanting to try to curb too much enthusiasm for new features. I was once involved in the design of a major software suite for which there was a detailed specification prepared initially with consultatation with the intended end users We made the mistake of releasing a number of beta versions and the users bombarded us with requests for changes/new features which were in the "desirable" but "not essential" category.

Regards

Jeff

LOL - that's happend to me as well. Over a period of around five years I developed a very nice inventory control package designed for the Art Gallery industry which I made the mistake of "customizing" for a few clients. The requests for changes kept coming for years and I finally had to refuse to make further changes because there is no end to individual preferences and for "it would be nice if's"...... The program had around 260,000 lines of code and each change required a complete re-test and search for all places which were affected. End users generally have no concept of what's involved and how many 80 hour weeks can be involved in debugging for what appears to them to be simple changes.

Best regards,

Lin

[JRR]

I just started playing with (er... studying ) ver 5 and slowly sorting things out. (been too busy creating other shows)

One question for now:

I have a habit of copying the images I want to use into a single folder for use in preparing the PTE show. As I work up the show I crop, edit etc the images and they get another name. But at the start there will always be another copy of each image elsewhere on my drive.

In the case in point, I copied in my images for the trial show into the new folder, I did not re-name any files. I wanted to send a .pt folder to a helpful friend with my "show" to ask some questions. But I was not allowed to create the template file as it said there was another copy of one of the images eslewhere. (Actually every image had another copy elswhere)

Do I assume that when ver 5 is implemented I will have to change my workflow so that when I set up the folder with the images for a PTE show, I should re-name all of them in the folder ? (That can be done via a PS Action of course)

I am sure I will have to change other workflow habits as well, but let's deal with them one at a time

[Igor]

Lin,

About speed of Pan/Zoom effects. You're right. It happens if move internal keypoints on the timeline of the object. This problem never occurs if object has only two keypoints.

I'll think how to help in this situation in the next version.

Thank you for your exploration of this question!

Jim,

Yes, current versions require to change this habit, sorry I'll try to do something in next versions.

[JRR]

Jim,

Yes, current versions require to change this habit, sorry I'll try to do something in next versions.

Thanks Igor.

[alrobin]

I have a habit of copying the images I want to use into a single folder for use in preparing the PTE show. As I work up the show I crop, edit etc the images and they get another name. But at the start there will always be another copy of each image elsewhere on my drive.

Jim,

Use the new "zip" option, "File / Create backup in zip" - it's much handier for preparing and sending copies than "template", and even better for saving backups for your own use, as it "zips" everything up in a neat little package. See, you can teach an old dog new tricks!

[JRR]

Jim,

Use the new "zip" option, "File / Create backup in zip" - it's much handier for preparing and sending copies than "template", and even better for saving backups for your own use, as it "zips" everything up in a neat little package. See, you can teach an old dog new tricks!

woof woof

Thx Al

[JRR]

Jim,

Yes, current versions require to change this habit, sorry I'll try to do something in next versions.

Igor:

Just to let you know, I did save another ver 5 show as a template this morning with no problem. The images were copied into a new folder just as they were with the other example that I ran into problems with yesterday.

I tried it again with yesterday's example and still could not create the template.

I tried adding one of the files that caused the problem yesterday into the new example and the TEMPLATE still created.

[Igor]

Steve,

Thanks, I've understood now the problem you've described me.

[thedom]

Dominique,

Please send me sources files of this project with this slide only.

(Delete other slides, then Main menu | File | Create backup...)

int_support@ <nospam> wnsoft.com

I think I know why this visual "problem" happens, if I understood rightly the problem. It's not a bug in this case. Just all images, including masks, show and scaled with bilinear filtering.

For example, increase or reduce size for this image (where located both layers - mask and picture) in Photoshop. You'll see same thin white edges now.

But if before resizing you will choose "Nearest Neighbor"resampling method, this problem will not occur.

So teorethically we can add special option for image objects. But I'm afraid there will be very small number of users who will use this mode.

Igor,

About thin white line problem, could you please tell me if you plan to add this special option for image objects in final release or if you finally let it down ?

Thanks.

[Igor]

Dominique,

If I remember rightly, this problem with a mask can be solved in beta 9.

We added "Low quality of resizing" ("Nearest Neighbor") resizing method to beta 9. See Common tab of a object.