DVD slideshow GUI - development thread.

[george84]

Hi tin2tin

Thank you for your response

1.

It was rather by chance that I found out that PreEffect is per image and PostEffect is per slideshow.

I agree that the info is there (somewhere). I noticed that in a previous version of DSG the texts on the Project Settings window read: Pre-processimages) and Post-processslideshow).
Somehow you changed this, I preferred the old version. By the way: I use the english version.

2. Test procedure in general: I never used preview. As I said, I export to .avs and look at it in VirtualDub. I also do export to .flv. What I see in VDub and what I get in .flv is always identical.

3. Concerning Kaleidascope

This seems to be rather complicated with behavior which is not predictible. Example: I have a slideshow with 2 identical pictures. In the final result the two slides look different. In this slideshow I have also a portrait picture. If it is in last position then there is generated a kaleidoscope of the background. If it is in position 2 then there is generated a "correct" kaleidoscope.

4. Do you agree with this

PreEffect only modifies the original picture and stores it as .ebmp. It is static, has no temporal effect. You could achive the same effect by editing the picture in some photo editor.

Thank you

[george84]

Testing Post-processing and Backgrounds

1. Kaleidoscope. Results: It works perfectly. Every frame is rendered differently. There is an obscure problem when you want to playback the .avs in VDub, "free frame couldn't load filter".

2. Mirror. Results: It works perfectly.

General remark. Post processing really slows up things. It is probably useless for high resolution slide shows but OK for .flv.


3. Background Kandinsky. Result: there happens something in background, though not very impressive (I have only two slides). In this test I get a difference between VDub output and flv output.

General remark. Motion Background really slows up things.


A last general remark:

.avs export creates also a directory containing the .ebmp files needed to playback the .avs in VDub. If later I export al .flv then this direcory will be deleted. It is rather annoying that an export deletes the results of a previous export.

[tin2tin]

DVD slideshow GUI is just a GUI. As you can can see when you open an avs file from DSG is it "just" a text file. This is the "only" thing DSG produces the rest is done by other tools which I didn't code. Ex. most of the animated backgrounds are combinations(done with FFrend) of Free Frame plugins, which then are loaded into Avisynth which can frame-serve to a media player or encoder.

Some of the backgrounds are develop over time and some does this from videofeedback. That how most of the Free Frame based backgrounds, effects and transitions act. This makes them sometimes come up with non frame accurate results - like what you mention about the kaleidascope effect. Actually HCenc will complain about this when using a Free Frame based background, but it will render it correctly. The Kandinsky background takes time to develop as feedback.

Concerning Virtualdub - open the script editor and check that the paths of the loaded plugins are set up correctly.

.avs export creates also a directory containing the .ebmp files needed to playback the .avs in VDub. If later I export al .flv then this direcory will be deleted. It is rather annoying that an export deletes the results of a previous export.

Just save each file under a different name and you won't have that problem.

[george84]

Hi tin2tin

Thank you for the new version (9.3.6) . I will test it soon.

I have a little request concerning Jhead. I told you some time again, that Jhead had problems with some IPTC data. There now exists a new version "2.90", maybe you could include it in a future version of DSG.

Thank you

[pictureman]

HI tin2tin,

I have installed the application on an XP machine and it looks really good and quick. I have created a slideshow with approx 100 slides. I find that when previewing or rendering that I get a green screen for several slides in the middle of the show. The problem does not appear to move with a specific slide but does move if I delete earlier slides.

I am at a bit of a loss as to how to diagnose what is going on here. Any ideas?

I have tried resizing all the image files as they were quite large but the problem still remains. I also tried changing the transition from the FlipPage_Left to dissolve which didn't appear to make a difference.

The software does look really good if I can get it to render the output correctly.


Thanks,

Paul

[tin2tin]

Hmm, that sounds strange. It works fine on my XP computer.

First you could try to update Avisynth to the latest Beta(do not uninstall the old): here.

And if that doesn't work try to update the XVID codec: here.
(Apparently the green screen can be a result of some codec related issues)

Let me know if one of those things solves that problem.

[pictureman]

Hi,

I have tried what you suggested and I am still getting the same issue. The green screen doesn't always occur at the same location but occurs in a similar location. I have tried resaving and renaming slides around the offending area but still get the same problem.

Are there any log files which might be of help. I was also wondering whether the ebmp files have been created correctly. Is there a way to open them and check.


PSThere

Thanks,

Paul

[pictureman]

Hi,

As further infomation I created a presentation with 10 slides - All was OK. I then copied the same ten slides a further 3 times. I then got the green screen when the slides repeated. I thought this indicated a problem with duplicate filenames so I renamed all my files in the original project hoping that woul fix things. Alas it didn't.

Paul

[tin2tin]

Sorry to hear that.

To check the ebmp files the easy way is to download AvsP and then write:

imagesource("change the path here\000001.ebmp")

And toggel the preview in the lower left corner.

[Edit: do you have enough RAM and free space on drive C: ?]

[pictureman]

Hi,

I have some more information. Opening up the ebmp files most open OK but where the problem occurs the following is displayed.

ImageReader: error 'üÝ□' in DevIL library. reading file Could not open file (New File (1), line 1)

So to me it looks like the ebmp generation is going wrong. What does this and what diagnostics can I try.


I think RAM and hard disk space are OK but will monitor.

Thanks,

Paul

[pictureman]

I don't know how I missed this but it appears that not all the ebmp files are generated - Hence the error message.

So now I need to find why some of the files are not generating in the middle of the slideshow.

Paul

[tin2tin]

ImageReader: error 'üÝ□' in DevIL library. reading file Could not open file (New File (1), line 1)

Sounds like a speciffic image can't be loaded into Avisynth. What happens if you add the original image file to the ImageReader command in AvsP?

DVD slideshow GUI "prepares" the (non-animated) slides by (in Avisynth: ) downscaling them and overlaying them ontop of the background and saves them as ebmp(avisynth native format). If Avisynth somehow can't import an image - which is what I suspect might be the problem - then the ebmp can't be saved correctly and turns out green?
(This process is to avoid having 5-10 mb photos eat up all the RAM and speed things up when previewing(overlay in the final avisynth will slow things down).

So the question is if it is possible to narrow the green screen error down to speciffic slides(they are rendered in batches of 16 images - which all will render badly if one of them goes wrong). What really puzzels me is this:

As further infomation I created a presentation with 10 slides - All was OK. I then copied the same ten slides a further 3 times. I then got the green screen when the slides repeated.

Which indicates that it aren't problems with reading of speciffic slides!?

Another thing to try is changing the profile for HCenc which is used to touch the script and render the images.
In the DVD slideshow GUI folder you'll find a file called HC_fast.ini open that file in Notepad and try to change this line: *PRIORITY HIGH to *PRIORITY IDLE or *PRIORITY LOW or *PRIORITY NORMAL to see if that changes anything? If it does this is somehow a bug in HCenc...

[pictureman]

Hi Tintin,

A good tip to open the files direct in AVS. I have just opened the files either side of the green screen error and I can view them OK.

What I really do not understand is where the green screen occurs changes if I move the slides about so I cannot pin this down to a particular slide. Is there a way to run the script that generates the ebmp line by line and see a debugging log.

I have really spent too long on this but I feel its worth pursueing because if I can get it to work the software looks very good.

Paul

[tin2tin]

I don't know how I missed this but it appears that not all the ebmp files are generated - Hence the error message.

So now I need to find why some of the files are not generating in the middle of the slideshow.

Paul

Is that error messsage from when you try to open a file in AvsP? Or when DSG is preparing a preview/render?

A good tip to open the files direct in AVS. I have just opened the files either side of the green screen error and I can view them OK.

It is the images within the 'greenarea' you should check if the original photos open properly in AvsP.

I have really spent too long on this but I feel its worth pursueing because if I can get it to work the software looks very good.

I really sorry for you time spend on this. Since I'm not able to reproduce that error it's a bit hard for me to fix it, however if you have this problem, someone else is bound to run into the same problem - and if we can find a solution other people will not have to encounter this problem. The joys of freeware...

My best guess is either is it related to a speciffic image(located in the green area) which can't be loaded into Avisynth and the saving of the images fail or else it might be how the priority is set in HCenc which causes makes the saving of the images fail.

[pictureman]

Hi,

The error message was when I tried to open the file in AVS. All the error message indicated was that the ebmp file was not there.

I have been trying to see how the preview scripts are run. I managed to "capture" a file which seemed to indicate that you are generating the ebmp files in batches. This would probably explain why the failure keeps moving because I now suspect that its one batch not being generated. Knowing this I will open more of the photos in AVS.

My best guess is either is it related to a speciffic image(located in the green area) which can't be loaded into Avisynth.

I will look at this again!

and the saving of the images fail or else it might be how the priority is set in HCenc which causes makes the saving of the images fail.

The above means nothing to me. What can I try?

Thanks,


Paul

[tin2tin]

I should proberly make the script check if an image can be read to avoid one image to ruin the entire batch. So far could "bad" images be caught when opening them in DSG, but apparently there are some images which can be loaded in DSG and not in Avisynth... I don't know about the HCenc - it's really a long shot - I'll try to explain later(or look above) - that is if you do not find one of the original images which makes Avisynth choke.

[BTW. DSG deletes all temp files such as the ebmp's after a render or a preview - so to make sure that they are not deleted you can hit preview and keep Media Player Classic open while checking the ebmps. Well, actually you only need to check the original images within the "green area", so the deleting of ebmp doesn't matter now.]

[pictureman]

Hi,

Thanks for your help. It looks like I found the offending image although I do not know what is wrong with it yet.


The losing the entire batch confused me when I was searching for it. The particular image had been converted with a different editor to usual so perhaps it has changed something causing a problem.

The error I get is Evaluate : System exception : Access violation

I'll try rendering it without this file. Fingers crossed!!

PS I have sent you a cup of tea!!


Paul

[tin2tin]

I'll try rendering it without this file. Fingers crossed!!

Oh, I am eagerly awaiting the results.

What editor did you save the image in - is there some way I could try to imitate the process - to generate the same file/error as you're getting?

PS I have sent you a cup of tea!!

Thank you very much! I should send you one right back for your persistence.

[pictureman]

I used Portrait Professional to edit the image and then DxO Optics pro. It's not the best image so I don't mind dropping it from the slideshow but if its the PP edit then the problem will crop up again.

I'll have a look at it again and let you know what I find.

Thanks again for your help.

Paul

[tin2tin]

If the conclusion is that it relates to a speciffic image type, which Avisynth should be able to import, could you make an image file I could share with the Avisynth people, so they could try to fix that bug/limitation?

[pictureman]

Hi,

I am starting to think that the file has got corrupted somewhere as I have not been able to produce another file with the same problem. If I can reproduce then I will send you a file.


The file in question opens in most software but will not open in paint. If its not just a single file corruption I am sure I will come across the problem again. Now I know that paint cannot open the file as well it will be easy to check.

Thanks,


Paul

[pictureman]

Hi tin2tin,

I don't know whether you have noticed that if you add multiple images simultaneously then the last image is added as the first.

It is dead easy to work around the problem but it may be a good improvement to make at some point.

Regards,

Paul

[tin2tin]

I don't know whether you have noticed that if you add multiple images simultaneously then the last image is added as the first.

Here on Vista images are imported in the same order as in the import window? Could you be a bit more speciffic on how to reproduce that order thing?

BTW. there has been a number of unstable alpha and betas of Avisynth out since the DSG included version( 2.5.8 ) came out. You could try one of the later ones to see if that image loading thing has been adressed - it might have? Here. NB the two 2.6 Alphas are not full installs and must be installed over a full install. Or else you could just load that image causing the error in Photoshop or Paint.net and resave it - that might correct the error causing behaviour.

[george84]

Bug in Color Management

Hi tin2tin

I was trying to figure out how I should prepare my pictures to get the best quality on my TV screen.
I spent a whole day studying DSG source trying to find out how it handles the colors and read several discussions in forums.

I found this article https://www.videohelp.com/forum/archive/tv-safe-colors-t359049.html in videohelp forum especially helpful.
The originator of this thread was also active in your thread.

My conclusion is, that DSG doesn't handle colors correctly. More exactly the colors are correct (grey is always grey) but the brightness is not correct.

I tested with image "retained.png" which I took from videohelp forum thread.

I propose to change the function "Levels(32,1,235,16,235)" in generated avs after ebmp import to "Levels(30,1,235,16,235)".
This results in better black values, while there is noch change in almost white values.
I must admit that I don't completely understand why this change improves the quality.

I document my results as follows:
OriginalRGB(0,0,0) DSGRGB(0,0,0) NewLevelsDSG(0,0,0)

This means the original picture had RGB value 0f 0,0,0 which resulted in 9.3.6 DSG in 0,0,0 and resulted in my new Levels function in 0,0,0.


My test results and results after my change are as follows.

OriginalRGB(0,0,0) DSGRGB(0,0,0) NewLevelsDSG(0,0,0)
OriginalRGB(4,4,4) DSGRGB(1,1,1) NewLevelsDSG(4,4,4)
OriginalRGB(12,12,12) DSGRGB(9,9,9) NewLevelsDSG(12,12,12)
OriginalRGB(20,20,20) DSGRGB(17,17,17) NewLevelsDSG(20,20,20)

OriginalRGB(231,231,231) DSGRGB(232,232,232) NewLevelsDSG(232,232,232)
OriginalRGB(251,251,251) DSGRGB(250,250,250) NewLevelsDSG(250,250,250)
OriginalRGB(255,255,255) DSGRGB(254,254,254) NewLevelsDSG(254,254,254)

[george84]

Bug in Color management of animation

Hi tin2tin

In my last post I told you about my findings with normal, non animated slides.

Now I did tests with image "retained.png" and animation. I used this slide for two animations.
In the first animation I did a zoom of 120 and a rotate of 15.
The second animation was not really an animation, I just set a key at he beginning and at the end of the slide.

The results for both animations are identical and rather bad. I get

OriginalRGB(0,0,0) DSGRGB(18,21,20) NewLevelsDSG(
OriginalRGB(4,4,4) DSGRGB(23,23,23) NewLevelsDSG(
OriginalRGB(12,12,12) DSGRGB(30,30,30) NewLevelsDSG(
OriginalRGB(20,20,20) DSGRGB(37,37,37) NewLevelsDSG(

OriginalRGB(231,231,231) DSGRGB(231,231,231) NewLevelsDSG(
OriginalRGB(251,251,251) DSGRGB(249,249,249) NewLevelsDSG(
OriginalRGB(255,255,255) DSGRGB(253,253,253) NewLevelsDSG(


This means that animated slides are very much different from the same normal slides.

It seems that the exported ebmp for an animation is already much different from the normal export.


Is there a reason for this big difference???

[tin2tin]

It may seem insane to push the backs up from 0->32, but the reason for doing this is because from yhe very beginning the entire slideshow is coded in yv12, which is what HCenc(and back then Quenc) needs. I wasn't planning on using the alpha channel for anything any way. And everthing was fine until one day I thought it might be fun to add a motion (video) backgrounds to the slideshow. At that point it would be insane to change the exporter coder into rgb32 which has alpha channel - so instead of doing that I pushed the blacklevel of the imported images up to 32 so there would be room for keying a black temp background out in the area of 16-32 and exchanging the animated background with that area. After this procedure push the blacks down to 16 again. I know some of the black will be lost in this process. You win some and lose some.

Finding the right values for keying scaled images is a bit trail and error to avoid trearing holes in the black areas of the images. Luckily it seems that this works ok for non animated slides:

I propose to change the function "Levels(32,1,235,16,235)" in generated avs after ebmp import to "Levels(30,1,235,16,235)".

I'll add this in the next release.

Working in the exporter code is a nightmare. This ambition with adding animation of avi and avs is just about to drive me nuts. And I sort of swear that I will never touch the export code again, because I tend to break more than I add or fix.

It seems that the exported ebmp for an animation is already much different from the normal export.
Is there a reason for this big difference???

Yes, it's completely different code - and most likely a different bug... Animation is working with the original image, for better quality, which means you can see the entire code in an exported avs script for how the animated image is handled. Those numbers are they from an animation-tool-preview or a normal slideshow-preview?

[george84]

Those numbers are they from an animation-tool-preview or a normal slideshow-preview?

Those numbers are from a normal slide preview.

I just realized that in animations the colors can go wrong. Examples


OriginalRGB(126,126,126) DSGRGB(133,136,135) NewLevelsDSG(
OriginalRGB(153,153,153) DSGRGB(158,160,160) NewLevelsDSG(


So the pictures look a little yellow.

I found a little workaround, quick and dirty. My deduction goes as follows: The blacks are too bright, but the whites are Ok. So why don't we just insert a "Level" the way you do it with normal pictures.

img = img.Lanczos4Resize(int((img.width()/1)/4)*4,int((img.height()*1/1/1/4)*4))
a = AddAlphaBackNoLev(img,back).ConvertToYV12()
a = a.Lanczos4Resize(1920,1080)
a = a.levels(32,1,255,15,255,coring=false)
at = trim(a, a.framecount-1, a.framecount)
at = loop(at,25)
a = audiodub(a,BlankClip(length=a.framecount, fps = rate, audio_rate=48000, stereo = true))

I inserted the bold line in the avs where the animation is handled. The result looks quite good, grey is mostly grey. In Details.


OriginalRGB(0,0,0) DSGRGB(18,21,20) NewLevelsDSG(0,0,0)
OriginalRGB(4,4,4) DSGRGB(23,23,23) NewLevelsDSG(4,3,6)
OriginalRGB(12,12,12) DSGRGB(30,30,30) NewLevelsDSG(12,12,12)
OriginalRGB(20,20,20) DSGRGB(37,37,37) NewLevelsDSG(19,19,19)

OriginalRGB(126,126,126) DSGRGB(133,136,135) NewLevelsDSG(125,125,125)
OriginalRGB(153,153,153) DSGRGB(158,160,160) NewLevelsDSG(150,150,150)

OriginalRGB(231,231,231) DSGRGB(231,231,231) NewLevelsDSG(227,227,227)
OriginalRGB(251,251,251) DSGRGB(249,249,249) NewLevelsDSG(247,247,247)
OriginalRGB(255,255,255) DSGRGB(253,253,253) NewLevelsDSG(250,250,250)


So the blacks and midtones are much better now, while the white is a little worse.

I find encouraging, that with a single statement we can improve a lot.
Please check that there are no sideeffects. By tuning the parameters of the "Levels" we might even improve the results.

By the way: I checked the results in a real m2v file too.

[tin2tin]

Yeah, sounds like I'll have fix that.

[pictureman]

Tin2Tin,

Regarding inserting the pictures. For me it works as follows on Windows XP.

Slideshow - Add Slides and videos
Pick first slide in show.
While holding down shift key select last slide in show.
Open

Now all slides are inserted but the first slide is the last slide I clicked. They now appear in the show in the following order;
-Final slide
-First slide
-Second slide
-Third slide
- etc

It is easy enough to move the slide to the end of the show. I have only installed the software on one PC so I don't know how repeatable this issue is.

Many thanks,

Paul

[tin2tin]

Winter Olympics in Vancouver Canada - Demo slideshow
Exported as 720p, mp4 and uploaded to Youtube.

Please note that it can be played in 720p. Direct link to 720p here!

Photos from: http://www.boston.com/bigpicture/2010/02/vancouver_2010_part_1_of_2.html