Lin Evans

Amen - and I'll drink to that! Happy New Year to all at the Wnsoft Forums and have a safe and wonderful day tomorrow! Best regards, Lin & Sherry

There really is no way to copy protect CD's or DVD's which can't be easily broken with commonly available software. Copy protection only prevents copying by those who have no real interest in copying anyway so probably not even worth worrying about. We don't even want copy protection or country codes on our commercial slideshow CD's or DVD's because we know it will happen and want maximum flexibility for our customers. Best regards, Lin

Not having seen the competition, it's difficult to judge, but I didn't find that the dream sequences were objectionable in terms of exposure, etc., actually very nicely done. My only suggestion would have been to alter the timbre of the narration so that there was a bit more bass and a bit less "bite" in the voice. Also I would have diminished the volume of the rain a tad in the last sequence vis a vis the background music and perhaps used an audio fade a little stronger in the last five seconds. All in all I found it to be an excellent job. Best regards, Lin

I notice there seems to be a bug in the slideshow (add all) feature in the new version - at least with my Windows XP home edition. It sometimes adds all images, sometimes it's selective for no good reason and sometimes it doesn't add any - I've emailed Irfan and wished him a Merry Christmas, suggested he take a break and check it out after he recovers from the holidays - HA! Lin

Beautiful and traquil with wonderful old European charm - very nice presentation of a lovely place. Great job, Patrick! Best regards and best wishes for the season and the coming year, Lin & Sherry

Just a simple slideshow with Christmas music - mostly Colorado and New Mexico nature and wildlife with some Jon Anderson Fimo Polymer clay art - all taken with my Sigma SD10..... Broadband necessary for download - about 80 megabytes. It's actually an executable file renamed to a zip extension so after download please rename to sigma05.exe to play. http://www.lin-evans.net/sigma05/sigma05.zip Lin

And best wishes to you too Hank and to your friends and family from ours... Lin & Sherry

Thanks Al - the Key file was actually truncated for some reason in the transmission - 10 bytes were left out including the ending quotation. Support has already emailed my friend a new zipped unlock key and all is well. Fantastic support from the Support Team at Wnsoft - thanks to all. Best regards, Lin

Hi Ralph, Thanks much for both the explanation and link. I just checked his email and the file is 10 bytes short or 221 bytes when saved in Notepad as a file "reg.key". Also it doesn't end with the equals sign and quotation so I suspect it was corrupted because it was sent as an attachment. I forwarded his email to Igor at wnsoft support and asked if they could resend it as a zip file. Hopefully that will "cure" the problem. Best regards, Lin

I suggested a friend purchase PicturesToExe which he did, Today he received an email with what was supposed to be an attachment of his registration "key" but it appears instead of a registration key file to be something really strange. He's not very comuter literate so I asked him to forward his email to me so I could tell him how to proceed to unlock his copy but I'm unsure myself about this one..... It's been too many years since I've seen a P2E registration key file, but isn't it still a file with an extension? What he received looks like this: REGEDIT4 [HKEY_CURRENT_USER\Software\PTE] "Key"="0uzP57kC/RawlfLDyHdowRCiaDeRnTr9LFAshLZa20Sw31GPRria5gNiqcw3/s6qas7buhPLkKhqmdsoZ87iI014H/F6dt1yYM6Gcul3Iot4c5vNnkxfpZ77e3WYlGFyLHvs+********** Just in case it really is the registration key I've deleted a part of it and replaced it with the "*********" but I think this is not right. This looks like perhaps the "content" of the file rather than the file itself. I'm at a loss as to inform him how to proceed other than by asking for another email. Is it possible his email program could have done this? Lin

Thanks Ken, It does indeed! My mistake. Thanks for the reminder. I had not tried it without the navigation bar being displayed but the Pause key does stop and resume the show when the "permit control of show" is checked. It works slightly differently than with ProShow Gold in that any transition effect in operation will continue until the slide coming into display has appeared where in ProShow Gold the transition effect is also paused, but the important thing is that there is indeed a way to pause and resume without having to have the navigation bar visible. Best regards, Lin

One of the features of ProShow Gold which is very useful is to be able to pause the executable while in process by pressing the "Pause" key on the keyboard. This effectively stops both the presentation of the slide image and sound. Pressing the Pause key another time resumes the show and background sound from the exact place it ended when the Pause key was pressed. This feature allows someone who is presenting a slideshow to stop and start without begining the show all over. Obviously with PicturesToExe we can make a manual show - something which ProShow Gold can't do. We can start, stop, reverse, etc., the manual show but we have no way of stopping an auto-advance slideshow mid-stream and resuming. This could be a very nice improvement if it could be implemented. Lin

Hi Carol, I use ProShow Gold as well for the Ken Burns effects but am anxiously awaiting Igor's implementation. - actually the Flash slideshow I've linked to is a ProShow conversion trom MPG2 to FLV Flash via Riva Producer. The reason many of us don't want to use the same protocol as ProShow is that they use what is deemed to be a dangerous Windows Active X component which invites hackers to implant virus and trojans. It does work quite well in that you can get nice smooth transitions and excellent fades, etc., but it precludes MacIntosh users from watching which is why the interest in Flash. The aprox 340,500,000 byte show I linked to is actually a worst case scenario where I've used a bitrate of 1600, a frame rate of 29.7 and a rather large file size of 640x480. This taxes all but the most robust client equipment and requires about a 12 megabyte per second download speed to run without hesitation. The Riva Flash FLV implementation is excellent and not subject to the 16,000 absolute frame limits of SWF Flash so that there is no practical limit to the length of the show. The one I have linked to is 27 minutes in length with full sound. As an MPG2 file it's a bit over a gigabyte in size. As an optimized Flash file its nearly 340 megapbytes but as a full resolution executable it's only about 62 megabytes which shows the relative overhead carried by MPG2 and Flash compared to the executable. When coverted to a ProShow Active X it's quite good at under 80 megabytes. The Ken Burns effects add a tremendous overhead because they require separate images for each transitional frame in any pan, zoom, rotate, etc., When these are converted to true video such as MGG2 or Flash the addition of nearly 30 frames per second for each transitional frame is added to the already larger files so that the end result is a honking big one. I may do this slideshow again with Rive by making a much smaller frame and see how much improvement I can get.. If it could be brought down to about 150 meg in files size at 27 minutes in length it would only require about five megabytes per minute which would bring it much closer to what many could achieve for a smooth show. I also used lower quality sound, but the sound really isn't the big overhead it's the bitrate which is a killer and the bitrate must be high to handle smooth fades. I like your slideshows and think that in many cases the smaller Flash implementation would work well but probably not for all. We usually offer our shows in DVD, Executable or Flash depending on the client's ability to read them. Primarily we have Flash for our MacIntosh based clients. Best regards, Lin

Hi Al, Yes - that't what usually happens when the stream download can't quite keep up. Because the data is actually being deposited to a temp file, if you go back and try to run the show again after it temporarily hangs up a few times it will run smoothly unless or untill the temp file has been disrupted. It's a pretty inefficient way to display the shows unless the person viewing has a really fast and efficient internet link. It works for us for most of our clients because they generally have T3 links. Generally even a good cable which download 4 mps or better will run it smoothly, but I would much prefer a system which spools this same show as an 80 meg rather than a 340 meg file. The executable for this same slideshow is under 80 meg. Best regards, Lin

There are actually two issues here - to simplify. First is the issue of image processing to get the bet image for the intended purpose. What one does to a digital image for "print" purposes, and what one does for "display" purposes are often a good bit different. For print purposes the image is captured in either RAW or jpg then processed accordingly. The RAW image has the advantage of having the full bit complement and can be adjusted for a variety of things such as levels, color balance, saturation, white balance, exposure, etc., before converting to either tiff or jpg. The primary difference in a print ready file and a display file is size and sharpness. Sharpening should ordinarily be done after all interpolation and for print output it's generally overshapened as compared to what one would want for display purposes. The jpg file must be post processed as the 8 bit file it is unless it's first converted to tiff where it can be set to either eight or sixteen bit or even saved as a proprietary format in PhotoShop, etc., Of course if you plan to save the work and visit it again it needs to be saved and manipulated in a lossless format such as tiff until you either display it or archive it. As Maureen covered, the 72 ppi or 180 ppi, etc., is simply a print "tag" which determines how many pixels per inch will be the chosen density at a particular print size. This has absolutely zero to do with display image quality. Most present day computer screens will display at somewhere around 96 pixel per inch so when a file has a particular size such as 1600 horizontal by 1200 vertical (about 2 megapixels) it will display on a 1:1 ratio when the video card is set to a resolution of 1600x1200 pixels. It would be too large to see completely at one time on a 1024x768 resolution screen, etc., so the display size should be chosen accordingly. Just make your images look like you wish them to appear (assuming you have calibrated your monitor) and size them according to your intended audience. If you plan to project them then set the image size in pixels to correspond to the projector's resolution (800x600 - 1024x768, etc.). If you plan to put them on a DVD then my suggestion would be to either crop them to the final aspect ratio of the display or pay careful attention to the software being used so that you don't loose the important portion of your image to necessary crops for maintaining the proper aspect ratio on a TV monitor. As for file compression, I would suggest trying to keep the overall file size down to under 300KB to avoid overstressing the hardware and promoting a smooth slide response. Forget trying to display you image for slideshow purposes in the same quality you would for still image at full resolution - it's just not feasible to expect quite as much because of the tremendous variation in the client equipment. Some who play your shows will have low resolution screen displays and mediocre video cards with minimal memory while others will have state of art equipment. The "art" is in compromise to get the best overall presentation without loosing those in your audience who are equipment challenged. Best regards, Lin

Sorry - my server was doing strange things and I had to reload the file this morning. It "should" be working normally now - keeping my fingers crossed - HA! There will be about a 10 second delay with the opening slide and text frozen while the buffer fills then the show should start. The running time is about 27 minutes. This one is a real "torture test" for Flash. It demonstrates all the reasons why it's not very likely to work well for everyone. The file size is nearly 345 megabytes and the running time of the slideshow is 27 minutes. This combination means that the client who runs the show on the web must have a broadband capable of sustaning downloads of about 340,500,000/27 or over 12 meg per minute. With less you get hang up, freeze, start - stop, etc. The only way to get the file size down it to diminish either the frame rate or the bitrate or both. If the frame rate is less than 29.7 frames per second you get flicker and jerky transition and if the bitrate is set under 1600 you get poor fades. The bottom line is that it's just not a great way to really get quality slideshows unless the client has considerable computer and internet power. Those of you on cable with truly fast broadband download will probably find it works very smoothly but without optimal equipment it's a compromise. Hopefully Igor & company will find a better solution. The Active X solution which PhotoDex uses is quite smooth and works well for most but not for MacIntosh users. It also carries the danger of virus/worm infestation by hackers so for now I'm at a loss to come up with something better than Flash. I could diminish the image and show quality and get the bitrate and file size down, but then the quality is marginal....... Best regards, Lin

Hi Beth, Hope the cold is better - I thought I would post a link to a slideshow I just put up in Flash FLV done with Riva Producer. It's a ProShow Gold slideshow, but probably will give you some idea of what we might expect in terms of P2E version 5 displayed as a Flash FLV show. I suspect the quality of this one is perhaps about as good as we can expect from Flash with a reasonably large slideshow and numerous pan, zoom, scroll effects. This one was done with a large bitrate so is about as smooth as I can get the transitions and fades to work in Flash. It's 27 minutes long and the Flash code is a bit over 320 megabytes. It has a 10 second buffer so will be about 10 seconds after you see the screen before the actual show begins. With a reasonably fast video card, broadband and decent CPU it should be tolerable. Click the link to try it.... http://www.lin-evans.net/colorado/colorado.html Best regards, Lin

Hi John, That's a tough one and the answer may depend on the actual display screen being used. The "standard" for HDTV allows for approximately a two megapixel display, but the actual screen being used may be progressive or interlaced. If interlaced, this "resolution" at broadcast is divided into interlaced scan lines each of about a megapixel. If the screen being used is an LCD type I would try to match the actual resoluion of the display type itself which could be variously up to 1024 by 1024 but with the wide screen aspect probably 1024x768 would work well. I would think experimentation might be the best way to decide in this case. Standardized DVD output at the highest resolution usually works pretty well on most of our customer's screens whether CRT type or LCD but if the display "allows" for input of a computer executable we find 1024x768 works pretty well for us. Lin

Yes, it helps very much to match the projection resolution to the native size, otherwise you're dealing with on the fly resampling which can often introduce unwanted artifacts. The problem is that many today use high resolution screens to display their executable slide shows and when displaying a 1024x768 slideshow at high screen resolution one either has a postage stamp sized image for the slideshow or the program must upsample from a native 1024x768 to whatever it takes to fill the screen. Neither are satisfactory solutions in most cases. Our solution has been to duplicate the slideshow executables using higher resolution originals for the executable for screen display and 1024x768 or 800x600 (whatever the projector's native display size) for the projector. It's really quite easy to do using a freeware program such as IrfanView where you can batch resample and at the same time apply sharpening, etc., as necessary. Then create a menu on your CD and call the appropriate show. Lin

Hi Beth, What I meant was that Flash, as a solution, was discussed numerous times in previous threads and dismissed in favor of somthing better for the the upcoming version. The downside of Flash is that it doesn't handle fade transitions very smoothly. (PhotoDex) ProShow Gold elected to go with an Active X method which makes for very smooth transitions but carries the inherent threat of virus/trojan contamination so I believe Igor has something better in mind than either Flash or Active X for version 5. I suggested Riva because it's the least expensive way to get a quality psuedo-streaming Flash show from an available AVI file. The price is about $30 and the player is free. There are numerous Flash solutions as you know, but many use the frame limited SWF (limited to an approx 16,000 frames) format which limits a 30 fps slideshow to 9 minutes, far less time than many need. Riva uses the FLV format which has no such limitation so works well with the exception of smoothness. In the past I've posted links to slideshows made with ProShow Gold using Riva to convert to FLV Flash. These slideshows also use the Ken Burns effects which P2E version 5 will have. The consensus has been that though they are "satisfactory" for a web show, there are better options which Igor and the other developers wanted to explore. Best regards, Lin

This has been covered in some detail - go here: http://www.picturestoexe.com/forums/index.php?showtopic=3547 Lin

I think it's origins are from urban American blacks who originally used the term to describe showy or ostentatious jewelry. Lin

Hi Dave, Very nice! I recognized many of the places (RMNP & Maroon Bells areas) and enjoyed the show very much. Welcome to the P2E forums! Soon Igor & company will have the Ken Burns effects which will allow some of the beautiful panorama's I know you must have made. I did a similar show using ProShow Gold for some friends and clients and am looking forward to duplicating using P2E soon - maybe by Christmas we will have a beta to test. Here's a link to mine - I'm sure you will recognize lots of the same places (RMNP, Maroon Bells, Mt.Evans, etc.). http://www.lin-evans.net/coloradonature/rockymtn.exe Best regards, Lin (Berthoud area)

No, no offense, not at all. I agree that it's imperative to find optimal solutions for quality DVD, etc., presentations. There are issues, however, as Photodex has found out with ProShow. The compatibility issues and interference from already installed burn engines which are incompatible with ProShow's own engine have caused them many difficult moments. It's difficult to say which is the better approach - that is to embed the code in P2E or allow the user to use external solutions to burn from the AVI template as is done presently. Perhaps a way to do either might be a solution but Photodex has had a nightmare of compatibility issues which has turned many away from an otherwise decent program. The answer isn't easy because of all the different equipment out there. When ProShow can burn a DVD the quality is excellent - actually in my experience much better than what we get by using Ulead, but there is a sizable percentage of users who have been totally frustrated trying to get it to work with their own hardware. Here's a link to a typical "situation" which is ongoing on dPReview where seemingly a conflict between Nero and Roxio burn engines are stopping the user from being able to burn a ProShow slideshow: http://forums.dpreview.com/forums/read.asp...essage=15867535 Best regards, Lin

Hi Tom, That is rather strange - perhaps something which PhotoDex has embedded to get a handle on how their slideshows are being used - I wasn't aware of this but it's interesting to know about it. I suspect there are a couple things going on with the fades, especially when there is a zoom in or out happening simultaneously. Since zooms are constructed from multiple frames of incrementally different interpolations it makes sense that at some point there would be an interaction between the host computer's native display size and a particular zoom or "crop" ratio. As you know when we take a starting resolution and take increments such a 50%, 25%, etc., we have much less screen aliasing than when interpolating to odd values. Since during the process of zooming we must pass through these odd values it stands to reason that we would see some moire and artifacting. Since the frame rate is probably 30 frames per second or so, these effects would be seen more obviously in scenes where there was continuity of smooth backgrounds such as with water, etc., than where the backdrop consisted of vegetation which could act somewhat as camouflage. Perhaps I've way off base with this line of thinking, but it seems logical. Best regards, Lin