bdsup2sub++ - convert and tweak bitmap subtitles.

[Selur]

Thanks! :D

[paradoxical]

You're welcome. :) Should be rounding the corner to finishing up all issues slated for 1.0.2. Please bang on it hard.

[djmasturbeat]

thanks
been meaning to check out the ++ versions (more, actually I had the previous "a" build, but only used it minimally, and not with ScnBD at all but for other things).
will test with ScnBD when I get a chance, and test out split epochs/dual windows/overlapping and time conflicting subs.

[paradoxical]

Yeah, the more testing it gets the better. Please bang away on it and let me know of any more limitations/errors one can find as I've only had a limited amount of samples to test with.

Edit to add: I think fades will still be an issue right now. Does anyone have any example SUPs that actually have fade effects, palette animations, etc.? I opened an issue to implement support for this in a later version.

[djmasturbeat]

i can demux sups from some of my own stuff (subtitles created with avs2bdnxml latest build) which uses fades, some done as inline effects hacked into the xml file before importing to scnbd, some fades left in the .ass

however ~ is this information intact in the sup if I demux with tsmuxergui, anyone know?

i will start with my Gundam Wing Endless Waltz, and send you a sup, send the PES+MUI, plus my .ass files and xml+png from avs2bdnxml
NB: the xml still has in a bug which happened for me on my first few projects, in the xml file from avs2bdnxml... no one else can reproduce it, so it seems to be heisenbug (bug based on heisenberg principle) as it was called in that thread, but I haven't had time to play much with a diff/alt build of his software yet. anyhow the bug is basically the first line appears twice consecutively with a ms or 2 delay between instances, and this creates a flicker, o/c. I fix it in ScnBD by removing the second instance and extending time of first one, in PES editor.
you can use the.ass to locate the fade effects that remain in the script. I don't think I did any inline effect fades (you can ctrl-f "fad" on the .xml just to be sure), I just shortened the fades that gave me underflows and removed other sub fx.
I will send you these in a pm and try to get some more stuff to look at later.

[paradoxical]

Cool, I appreciate it. Anyone also know of any retail discs that have subtitles that use such effects? Especially if they use one of the other authoring programs besides Scenarist just to see if the resulting SUP might look any different.

[djmasturbeat]

retail.... I will have to think on that.
Perhaps, but it seems like fan discs, as usual, are more of a labor of love than assembly-line mindset.

I will try to get you more of my own personal stuff and include all the files (.ass, avs+png, pes+mui, sup) to help better link what equates to what amongst these things.


I can get you stuff from another authoring tool just for general observation.
I will try to remember to send the Kiki's Delivery Service retail (dub)subs in sup and pes+muiwith my rendered fansubs and scripts, but I don't know that they have any fades or palette animations, nor any kind of inline subtitle effects. The only reason I would add them is they were made with Panasonic Authoring (PACR), which is a vastly different system from ScnBD, though if they are w/o inline effects, I have little idea what use they will be, if any for comparison.

Again, i don't know of any retails offhand with fades, but I will think on it.

[paradoxical]

Well, it was more for the curiosity than anything. And, yeah, the more stuff you can send me the better. Again, thanks a ton!

[paradoxical]

Hmm, so according to this (http://forum.doom9.org/showthread.php?t=156420) post the Lord of the Rings Fellowship of the Rings uses fade effects. Haven't watched mine yet so this would be a great time to crack open the discs and examine the subs. :) Should be at least a good starting point to how retail discs do fade effects.

So as I said, if anyone knows of any other retail BDs that use fades, palette animations, etc. let me know. I'll try to fix all the shortcomings inherited from the original program as best as I can relating to this.

[djmasturbeat]

which LotR, the TC, or the even-more-overly-long ones?
sorry, loved the books but found the movies a snooze, and hated the color/hue palette change thing they did on the BDs (was it only the extended they did that to?)

[paradoxical]

I have both actually.

So in testing, fades might not actually be an issue at least on the import side. For subtitles that I tried that the original BDSup2Sub says "WARNING: Palette animation: result may be erratic" and then basically does no fading. bdsup2sub++ on the other hand does the fade as you would expect. Though I expect that the way the subpictures are written back out will need to be optimized so that image objects aren't duplicated when the only difference is in the palette id. I'll need to test export but from reading the code it doesn't look like the palette update flag and the palette id ever get updated in the headers being written out so that will need to be changed. But it's an encouraging sign nonetheless.

[Chetwood]

The subs are only animated for the director's comment in which the name of the person currently speaking fades in/out. Another thing: would it make sense to save back to PGS when resizing 1080p subs to 720? After all, PGS allows for more colors than VobSub and might result in more readable subs.

[paradoxical]

The subs are only animated for the director's comment in which the name of the person currently speaking fades in/out.

Well for the theatrical cut there are a couple of forced subs that do fading, too. The point really was just to see if the code would handle fades at all which it did. I just need to fix export so that the fades aren't destroyed when writing the sup back out.

Another thing: would it make sense to save back to PGS when resizing 1080p subs to 720? After all, PGS allows for more colors than VobSub and might result in more readable subs.

Yes, it'd make more sense to do PGS since that would be guaranteed to be supported. 720p VobSub is sort of non-standard and you never know how it will be handled by various players and/or subtitle filters.

[paradoxical]

Spotted a crash in picture decoding for BD SUPs due to some parsing logic errors. I didn't spot it before since it didn't crash the release build only on debug. This has been fixed. If you were using the previous beta and want the newest binary it can be downloaded here (https://www.dropbox.com/s/vyo4j2x9v7mt827/bdsup2sub%2B%2B102b_20132003_Win32.7z). First post has been updated as well.

[djmasturbeat]

looks like the dropbox link is dead for the update

[paradoxical]

Yeah, I'll fix the link shortly. After fixing the previous issue an export bug cropped up. Arggh.

[paradoxical]

As an update I know what the issue is and I have a fix for it. I have to go to the dentist now so once I get back I'll commit the fix, test it and post a new build.

[r0lZ]

I have a palette problem that drives me crazy. I don't think it's a BDSup2Sub++ bug, as the java version and the VsFilter/VobSub plugin for Avisynth give the same result.

The original stream is in SRT format, and has been converted to SUB/IDX (and also, for testing to PNG/XML) with 3DSubtitler.
I have uploaded a (very) small sample here (http://download.videohelp.com/r0lZ/tmp/test_subs.7z) in PNG/XML format.

The first subtitle is correct. Its colour is white, with a black outline.
The second subtitle looks correct in the upper part of the BDSup2Sub++ GUI (source), but the font colour is blue in the lower part. I don't understand why. It should be white too, and if I open the PNG in an image editor, the colours are correct.

I have tried many things to fix that palette problem, including converting the PNG images to TIF and then back to PNG, but w/o success.

Finally, I've discovered that saving the XML/PNG as BD SUP with BDSup2Sub++ seems to work. When I reload the SUP, it has the correct colours. But as soon as I change the output format back to IDX/SUB, the second subtitle turns blue again!

Trying to save as IFO/SUB with a new palette doesn't work either. When I try to edit the palette, the colour of the subtitle changes, but the program selects automatically another colour. Finally, BDSub2Sup++ has crashed.

What am I doing wrong? How can it be that some images are correctly shown, and other ones, saved with the same program, are wrong? Is it a way to fix that problem?

[paradoxical]

Ok, I'll look at it.

[r0lZ]

Thanks. BTW, I have finally found a way to convert the stream with correct colours. I have edited all colours of the palette in the BdSup2Sub++ GUI, leaving just one black, one grey and all other colours white, then I've saved the palette. Then, I've loaded the PNG/XML subs, and re-loaded the palette. It seems that that has forced BDSup2Sub++ to select the "best colour" from the palette to replace the blue, and luckily it picked white. The saved IDX/SUB seems correct. That works, but obviously, there is something strange, as it should not be necessary to use that bizarre trick.

[paradoxical]

Yeah, I've noticed the problem too. I'm guessing something weird is going on when mapping to the reduced palette. Maybe in the quantization phase. I'm still working out all the kinks for import/export of BD SUPs but I look at it after that. I'm busy this weekend so I won't be able to finish to BD SUP stuff up until early next week.

[r0lZ]

Strangely, the avisynth VsFilter has exactly the same problem, with the same subtitles, also shown in blue. So, I guess something is strange in some PNGs. But that should not prevent BDS2S to convert them correctly. Goof luck, and have a nice weekend.

[paradoxical]

Well I've noticed it also for BD SUP to Vobsub that colors get screwed up, too.

[r0lZ]

Yes. BTW, I did some tests with v1.0.0 too, without success for the colour problem, but I've discovered that the subtitle start and end times were screwed up when converting from PNG/XML (to any format, I think). I didn't know that bug and I've verified with v1.0.1. Obviously, it has been fixed. Good job! :-)

[paradoxical]

So there was a big delay in getting this out, but a new beta version is here (https://www.dropbox.com/s/wpoxlgkgxo0yewr/bdsup2sub%2B%2B102b_20132803_Win32.7z). This should put to rest all the issues with import/export issues with multi-region SUPs. There is still a few optimizations that can be done be for subtitles that share a composition object when output back out as BD SUP but those will have to arrive for 1.0.3. The lack of that doesn't seem to harm anything, but it would make the SUP files smaller and match closer to what is output by professional authoring tools. This now just leaves the move issue and the change to fix where settings file is saved which I will work on now. Please report if you do see any issues though.

[r0lZ]

Thanks. BTW, I've also noticed a small typo. The name of the config file is bdsup2sup++.ini instead of bdsup2sub++.ini. Not a big deal, but that's easy to fix. :-)

[paradoxical]

Yeah, that's pretty weird. Will fix that. Apparently it's been that way for a while.

[paradoxical]

Refreshed the file to fix that and another fix. So I'd recommend regrabbing if you already got it.

[r0lZ]

It seems that the palette is still wrong when saving to SUB/IDX or SUB/IFO. But this time, the color of all original subtitles (in PNG or SUP format) is wrong too, regardless of the output format. With v1.0.1, I have been able to convert with the good colors by forcing a palette with only black, gray and white colors, and the antialiasing worked well. Now, the antialiasing (present in the original SUP file) is lost too. When the palette is forced, it picks black for the outline, and the gray for the text and the antialiasing, with some white pixels at random places. Really strange.

[r0lZ]

I've noticed an interesting thing. As you know, I have generated the original PNG/XML files with 3D-Subtitler (http://www.softpedia.com/get/Multimedia/Video/Other-VIDEO-Tools/3D-Subtitler.shtml). It has an option to change the contrast (in fact, it's more the brightness) of the generated subtitles. Its default value is 100, but iirc I've lowered it a bit, because the movie is very dark, and I don't want too bright subtitles. With that dark subtitles, BDSup2Sup (++ and java) fail when picking the colors of most subtitles. But if I set the "contrast" slider to its maximum (value 250), then the colors of the converted SUB/IDS are picked correctly, and the generated IDX/SUB is correct. (I have edited the palette in the IDX file to change the colors after the conversion, and that works well.) So, it seems that BDSup2Sub picks the wrong colours only when the original colours are not close enough to the existing palette.

Also, I have noticed another small bug. When I've tried to convert the dark subtitles, I have saved and loaded several palettes (in .INI format). I have loaded the BDSup2Sub++.ini file instead of the palette.ini by accident, and BDSup2Sub++ has changed all colors to black. Not a big problem, but if it's easy, it should check for the right file format before changing the palette.

[paradoxical]

It seems that the palette is still wrong when saving to SUB/IDX or SUB/IFO.

It's because no change was made for that yet.

Also, I have noticed another small bug. When I've tried to convert the dark subtitles, I have saved and loaded several palettes (in .INI format). I have loaded the BDSup2Sub++.ini file instead of the palette.ini by accident, and BDSup2Sub++ has changed all colors to black. Not a big problem, but if it's easy, it should check for the right file format before changing the palette.

Ok I'll look into it.

[paradoxical]

New git build here: here (https://www.dropbox.com/s/82dr1cq9hk2v535/bdsup2sub%2B%2B102b_20130404_Win32.7z). Has a fix where some flags were not properly set when using the CLI which caused the output to differ from conversion in the GUI. Also has a few improvements for exporting just forced subtitles.

[paradoxical]

All outstanding issues I wanted to get fixed for 1.0.2 are down. Please test with this build (https://www.dropbox.com/s/pwdm81ebgm47y2m/bdsup2sub%2B%2B102RC_20131204_Win32.7z) to see if you spot any issues. If not, I'll tag 1.0.2 and start work on other things on the list.

Just a word of warning that until I do some additional optimizations to the BD SUP output, if you convert a SUP file that has lots of fades or when composition objects are referenced across multiple epochs to another SUP file you will notice the resulting output will be larger (sometimes many times larger if there are lots of fades for example). This is because of limitations of the code as it is right now and that it duplicates those composition objects rather than just keeping a reference to them and using different composition states as you would see in proper output. It doesn't harm anything as the subtitles will still display correctly, it just means the file size will be bloated.

This will be an issue I will fix, but it required a bigger change to the output code than I currently wanted to do. This will be the first thing I do fix for the next version, though.

[paradoxical]

Oh and to add for you r0lz, I've added specific commandline switch for the move Y from origin. It requires you to specify up and down because for some reason the library I use for parsing commandline options would interpret giving an option a negative integer value as an option itself and thus would fail out because it was unrecognized. So you have to do "move-y-origin up" or "move-y-origin down". It's a little awkward but should work for now. I'll see if I can workaround the issue otherwise in the meantime. Also, the same option when used in the GUI also works properly now.

[r0lZ]

Thanks! I'll test the new version soon. :)

[Selur]

@paradoxical: I got two users who get crashes of bdsup2sub++ if they use a newer NVIDIA drivers than 296.10, using 296.10 everything is fine.
Are you using any OpenGL code that might be in conflict with newer NVIDIA drivers on some cards?

[paradoxical]

Nope. Also, the Qt I compile to link in is even specifically compiled without OpenGL or ANGLE.

[paradoxical]

Also my dev box is running 314.07 and I see no issues with it.

[Selur]

I'm running with the latest NVIDIA driver and have no problem either, but some older cards seems to have trouble with it.

[paradoxical]

I don't know. Maybe it's a Qt bug. I don't use anything OpenGL/DirectX directly.

[Selur]

What Qt version do you use to compile delaycut?

[paradoxical]

The version for the latest bdsup2sub++ builds is 5.0.2. You can always check that by going to About > About Qt.

[paradoxical]

Just as a thought, did you happen to get the information about what kind of CPU they had? The only other change with that build is that I compiled both the Qt libs and the application with MinGW-builds x32-4.8.0-release-win32-sjlj-rev1

[Selur]

No, but I will ask them and report back.

[paradoxical]

Hear anything? Having perused a thread it seems this happens with other apps as well according to that link to rename the DLLs. It's weird though as it seems to be almost random according to the posts about it. Just to test it doesn't have any crashes on the other main Windows machine I use to develop on which has a Quadro 2000 currently running 311.06.

[Selur]

Sadly no update from the users that reported the problem till now,...

[paradoxical]

Sadly no update from the users that reported the problem till now,...

Well, since it seems others have seen this issue with other apps, it's probably unlikely to be some sort of CPU incompatibility issue. So were they having issues with builds prior to the latest as well? If so, it means at least that it isn't a 5.x specific issue. Seems maybe Qt has some sort of bug or the NVIDIA drivers are just doing something stupid by loading DLLs that aren't needed. In either case, I'm not really sure that I can do anything especially since it's almost a random issue and one that only seems to affect a small amount of people.

[Selur]

will ask the users to try older Versions and report when I get feedback

[sl1pkn07]

is possible add "none" option to image filter?

[paradoxical]

Images only get filtered if you specify a different target resolution than the source resolution via CLI or choose "convert resolution" in the GUI. So there's no real point.