Jump to content
WnSoft Forums

Recommended Posts

Posted

It is an unnecessary complication if we have to introduce an artificial object, the transparent frame, simply to get the top-left corner of one object positioned at a precise horizontal and vertical offset from the top-left corner of it's parent object when the Position coordinates are supposed to do that very thing without the need for the additional frame.

I repeat: there is either a bug in the code or a flaw in the design. We should not have to program our way around this problem. It needs fixing!

regards,

Peter

Edited 30 Oct 2008: See this post http://www.picturestoexe.com/forums/index....ost&p=58292 for the resolution of this problem.

  • Replies 189
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Posted

On a lighter note, here's a demo which is called SNOOKER.

The TABLE is the VIRTUAL FRAME, the RED BALL is a child of the table and the WHITE BALL is the child of the RED BALL.

The table is a 1920x1200 JPEG and the RED BALL and WHITE BALL are both 1920x1200 PNG files with the balls at their starting positions.

At every keyframe the position of every element is determinable with absolute accuracy with respect to its parent.

I have tried it on both my 1920x1200 monitor and my laptop's 1280x1024 monitor and the result is identical albeit smaller.

Enjoy,

DaveG

http://www.mediafire.com/?sharekey=411ad3b...d8b33b5aa27078d

Posted

Xaver,

A while ago you said:

A major difference in my eyes seems to be that 5.5 with original mode places objects pixel oriented, while 5.6 internally seems to be completely percentage oriented. The size/position window only seems to be a tool for avoiding calculations (from pixels to percentages). I had a look at a project file created with 5.6: It did not contain the pixel coordinates which I typed into that window, but only the corresponding percentage information. The images all have position mode "percent", I think that position mode "absolute" does no longer exist.

It occured to me that absolute pixel relationships between objects would be only be possible on monitors of the same resolution/aspect ratio. In order to preserve relationships between objects across a variety of different resolution/aspect ratio monitors the distance between them MUST be expressed as a percentage.

Two objects xxxx pixels apart on my 1920x1200 monitor would appear to be further apart when viewed on a 1400x1050 monitor if an absolute pixels relationship were maintained. Hence the need to change to a percentage based relationship.

DaveG

Posted
Hence the need to change to a percentage based relationship.

How does Photoshop, PaintshopPro, Pixbulder and others programs with there layers to work on all screen definition ? There must be a solution, I am working on it.

Posted

Interesting point JP,

In PS at "Actual Pixels" the relationship between the layers appears to be on an "absolute pixels" basis but when you apply a zoom factor the "percentage" relationship comes into play between layers.

Perhaps they have two "systems"? One for "Actual Pixels" and another for all other zoom percentages?

DaveG

Posted
Xaver,

A while ago you said:

A major difference in my eyes seems to be that 5.5 with original mode places objects pixel oriented, while 5.6 internally seems to be completely percentage oriented. ...

Hello Dave,

what I wanted to say is that 5.5 really had different representations (for "original mode" oin one side, and for the other modes) inside the project (pte) file, indicated by the values "absolute" and "percent" for a particular attribute. So it seems to reasonable that both modi were treated differently inside the software, maybe (I can only try to guess) in the way how child objects were embedded into their parents.

In 5.6 you can program this embedding via the user interface (size/position window), and of course you do it in absolute terms (pixel coordinates). But your absolute inputs will not be stored in the pte-file. They will be translated into percent values for scaling and positioning.

If the difference between original mode and the other modes were only a matter of the user interface the whole discussion here would not have taken place.

Best regards,

Xaver

Posted

I think I have find a little process to add which permit to keep the actual 3 mode with using only one algorithm like in V5.6.

The idea consist to translate original mode in one of the 2 others mode and give to actual algoriithm the mode to use instead of Original mode and the zoom values to use.

I hope it will be possible to solve this very big problem, the proposal I did is still available.

Description of the process can be download here

Posted

As nobody seems have Excel to understand and have an opinion about the proposal above, I'll prepare more explanations with draws to morrow.

It's really a best solution, I think, than the Size/position box that I am always enable to use for complex slideshows and which can't be really used without mistakes when the screen definition isn't the same as nominal picture size.

Posted

JP,

To convince me / everyone, can you produce a short sequence showing where these inaccuracies happen?

An EXE along with a backup in zip would be great.

My screen sizes are 1920x1200 and 1280x1024 so it would have to be in one of those resolutions for me to be able to comment.

Many thanks,

DaveG

Posted
JP,

To convince me / everyone, can you produce a short sequence showing where these inaccuracies happen?

An EXE along with a backup in zip would be great.

My screen sizes are 1920x1200 and 1280x1024 so it would have to be in one of those resolutions for me to be able to comment.

Many thanks,

DaveG

On a very little example 2 things would be corrected with my proposal

1 - there wouldn't the red line (the background) on a 1024 x 768 screen when viewing a 1800 x 1200 slideshow (one of your screen for photo format). It's a reason for which values give by Size/position box are sometimes wrong.

2 - Second slide of the test would be resize when using something like "% of the slide to show main image" (see my proposal), it's impossible in the test file because there are 2 keypoints (zoom = 100%)

The test is here (made with V5.6 beta 6). I don't try to do impossible things, it's why I don't try to explain you why it's better to work with original mode (for a nominal format give to PTE), you'll always work with Fit to slide mode.

Nobody see that there are 2 old options which have been kill in 5.6 :

1 - Possibility to put Pan in pixels (I don't want to use Size/position box which doesn't work as PTE do : Pan is between 2 centers)

2 - Disable scaling of main images (Not recommended for the same reasons as % of the slide...)

With my proposal, they both would work without problems, is it enough ?

Posted

Hi JP,

Many thanks for that.

On point - I don't understand - If I change to Fullscreen 3:2 - Red Line Gone.

Why use Windowed Mode??

I am making my examples show the same on ALL resolution/aspect ratio monitors.

I thought that you wanted that too?

Please wait for my example - in the next 24 hours.

It has images - not rectangles - it has Pan, Zoom and Rotate of multiple objects - it shows the same aspect ratio on all monitors - there will be a version for computer and a version with TV Safe Zone for DVD (Globally changed) - ALL with no Visual problems.

Best wishes,

DaveG

Posted

Hello Dave,

I changed the davegee project to Fullscreen, and ratio 15:10. I ran the show on my old system with a 1024x768 screen. The red line appeared! PTE seems to resample the image of size 1800x1200 to 1024x683 (as Photoshop and IrfanView do), but seems to generate a screen of 1024x684 in which the resampled image is shown.

Regards,

Xaver

Posted

Xaver,

I tried it again, just to be absolutely certain.

Change to Fullscreen 15:10

No red line on my 1280x1024

No red line on my 1920x1200

On different computers.

It is a Windowed Mode 1.497076:1 project with a 3:2 image!

I would expect problems!

Best wishes,

DaveG

Posted

Xaver,

I tried it again, just to be absolutely certain.

Change to Fullscreen 15:10

No red line on my 1280x1024

No red line on my 1920x1200

On different computers.

It is a Windowed Mode 1.497076:1 project with a 3:2 image!

I would expect problems!

Best wishes,

DaveG

Posted
It is a Windowed Mode 1.497076:1 project with a 3:2 image!

No, fullscreen 15:10!

The result: No red line on 1280x1024 LCD, red line on 1024x768 CRT.

Regards,

Xaver

Posted
Why use Windowed Mode??

I thought that you wanted that too?

I put the example in windowed mode in order you see what happen on a 1024 x768 fullscreen , try the example in fullscreen on a 1024 x 768, you will have the same result.

Posted
Xaver,

JP's original is a 1.497076:1 project with a 3:2 image

Are you seeing the red line in the Mini-Player or when you run Preview?

DaveG

It was a 1.5 on a 1152 x 864 screen, that's never the same thing, it depend of the screen definition, it's one of the reason for which I made my proposal. Have a look on this picture I did sometimes ago to explain on Diapositif :

Calculs_Format_1.5.jpg

On a 1280 width screen, there are no problems as you can see above. I tested all this screen definition.

edit : sorry for 1280, it depend of it's height.

Posted

i think the more important problem is that when you chooose 90% in the options screen the main image dont follows if there are several keypoints on the main image...this simple exemple shows that you can't do a dvd without extra solutions like a rectangle as parent even if you only zoom on a single picture !!!

Posted
i think the more important problem is that when you chooose 90% in the options screen the main image dont follows if there are several keypoints on the main image...this simple exemple shows that you can't do a dvd without extra solutions like a rectangle as parent even if you only zoom on a single picture !!!

That's right and there is another problem I haven't put here : it's not the format which is resized but the main image (not always and not necessary of 90% if it is not at 100% when built), so that if you have for instance a pan on a second level picture (if first level, as there are 2 keypoints it wouldn't be resized), the 10% on each size wil not be hidden, it's another reason for which I made suggestion, I ask for that 2 years ago about.

With the Cale method, no problem to resize, always the problem I explained above, of course I have a solution for it, but it would be easier for everybody, using Fit to slide, Cover or Original mode if the problem was solved by PTE itself as I suggested..

Posted
... JP's original is a 1.497076:1 project with a 3:2 image

Are you seeing the red line in the Mini-Player or when you run Preview...

Hi Dave,

I think that Jean-Pierre just presented a simulation of what will happen if you will run a show with images of size 1800x1200 on a 1024x768 screen with ratio 1.5. I generated an exe-file with v.5.6beta5 on my new machine and played it on my old computer with the small monitor. The red line was to be seen; I would have expected the same on 1280x1024, but there it did on occur.

Regards,

Xaver

Posted
Maurice,

Is that not the way that the "Cale" works - there must be a Cale on all images as Parent?

DaveG

yes but it is not normal to have to do some operation...elsewhere it is an anomaly from PTE, not to be able to obtain realy x% when you choose this value in the srceen option !!!

Posted

Jean-Pierre,

I have posted the results of my tests here:

http://www.mediafire.com/?sharekey=411ad3b...3a805876665040c

May I say that tables of mathematical data did not convince me that there was a problem – I needed to see the problem with my own eyes with actual images. Manufactured demonstrations using rectangles are also unconvincing. So I set about constructing a test using actual images at “Actual Pixels” (equivalent to Original Mode) to see for myself what the problems are (if any).

TRACTOR 1

The project is FULLSCREEN 16:10 and all images (assembled images) used are 1920x1200 (actual pixels on my screen).

WARNING - Please be warned that the result is VERY memory hungry and works at the limits of my system - 3Gb of RAM and a graphics card with 512 Mb of RAM.

The first slide shows an image which has been split into 10 strips being put back together using panning. The result is a pixel-perfect black and white image made up of 10 strips which seamlessly join together appearing to be a single image. This reverts to the original colour image in steps.

The second slide shows the same 10 strips being joined using a combination of pan and rotate. Once again the 10 strips join together seamlessly as though they were one single image.

The third slide shows the original image, split into 25 rectangles each of which can be rotated and returned to the original state to form a seamless montage. The centre image also zooms – I have used this on just one image to avoid overtaxing my graphics memory which is already stretched to the limit in this test.

On the basis of this test I could not fault the programme. It did all I asked of it with no visual imperfections. The resulting EXE file runs perfectly on three computers with differing resolutions/aspect ratios, albeit with some jumping and stuttering due to the size of the project.

At this stage I began to notice minor problems at the extreme edges of the frame during transitions. I brought this to Igor’s attention and he said that he had failed to duplicate the problem suggesting that I update my video drivers. I was not convinced by this and have not done this so far.

TRACTOR 2 - TV SAFE ZONE

I now tried to create a version with a TV Safe Zone built in. I used the “% of the slide to show main image” feature to achieve this. As Maurice pointed out this can only be used if the “Level 1 Parent” has no keyframes and with this one proviso it seems to do what is required.

A problem is immediately obvious in that children appear within the TV Safe Zone. There are ways of overcoming this and it probably would not be a huge problem because when the DVD is made and the TV Safe Zone percentage is chosen accurately the children would not be seen anyway.

However, things now begin to fall apart and thin lines appear between the various strips and rectangles on a random basis.

This led me to go back to the TRACTOR 1 project and try zooming the parent image while the assembly of the strips was taking place. Sure enough, the random lines began to appear. They also appear in the third slide where the 25 rectangles are zoomed and rotated.

CONCLUSION

On the basis of this test and the evidence of my own eyesight, Jean-Pierre, I agree with you and concede that 5.6 is flawed.

Thanks to JP for his persistence. I hope that a solution is possible.

Meanwhile, I will abandon testing 5.6 and continue to use 5.5 until a solution is found.

DaveG

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...