"Ooops! The modified encoded subpic does not fit in the available space..."

[dilophosaurus65]

Yep. This shows when I try to replace a menu subpic in DVDSubEdit, that I've already edited in Photoshop. Is there any way to fix this? Edit some of the subpic info or something? Plz HEELP!!!

[manono]

You can try replacing it using VobBlanker. Should work but no guarantees.

Is the size of the edited BMP the same as the original? You didn't change the number of bits, did you? 16bit to 32bit, something like that?

[dilophosaurus65]

Just checked the sizes: the original subpic is 1*244*214 bytes and the edited one is 1*244*216 bytes. Perhaps this does indeed matter...?
Anyway, this is the main menu:



this is the original subpic:



and the same subpic, edited:

[manono]

Oh, that makes it clearer. And I misread you and thought you wanted to replace the menu background where you clearly stated you wanted to replace the subpic. In that case DVDSubEdit is the only program I know that can do it, although I'm sure there are others. Perhaps someone else can help. Nice job with the edited subpic.

[dilophosaurus65]

Aw, thanks!! I'm really into editing those kinds of stuff and get really annoyed when such thing stands in my way.
I really appreciate your help manono, you're the only one who's replying to me.
Yes, it's really a shame that dvdsubedit is the only program capable of doing such stuff.
Actually I just made a registration in Digital Video Forums - perhaps someone there knows a thing or two.

[mazinz]

For sake of argument are you using photoshop to create your new subpic? I mention this because (unrelated) if I want to replace a normal menu with dvdremakepro, I noticed that in Photoshop the bitmap at default wants to save as 32bit and this won't work, you need to save it in 24 bits.

So if you can open your altered bitmap in Photoshop, do a "save as" rather than "save" and it offers the option of what bit to save your bitmap in. Choose 24 and try this with dvdsubedit

[dilophosaurus65]

Well, I've been saving it, using "Save As" all along and in 24 bit as well. But still no result.

Ps. I would have figured out 32 bit won't work because dvdsubedit says that as well

[mazinz]

Well, I've been saving it, using "Save As" all along and in 24 bit as well. But still no result.

Ps. I would have figured out 32 bit won't work because dvdsubedit says that as well

Well it was worth a shot. Are you using the last (2011) version of the program or one older than that? Could be a bug in the last version (or if older previous version). They have a link in the software section here for older editions if you want to give it a try

[dilophosaurus65]

It says ver. 1.52

But this is what found in the dvdsubedit manual:

"It’s not always possible to re-import the modified bitmap into the subpicture, because the encoded bitmap has to fit in the number of subpicture packs used by the original bitmap (DVDSubEdit cannot insert packs in the VOB file – that would be a very lengthy operation). To help with that, DVDSubEdit crops the modified bitmap as it imports it, and attempts to move commands and data in the subpicture packs to maximize the amount of space available for the modified bitmap. In general, small modifications don’t pose a problem, but if you add too much to the bitmap it is likely that it won’t fit into the original space. In that case, DVDSubEdit issues an error message, and restores the original bitmap."

Oh, well.....

[mazinz]

Hmm what if you shrunk the wording down of your modified file? That might work

[dilophosaurus65]

I'm experimenting a bit and it seems to work when there's only one of the four words visible only (not all four together). I was thinking, if maybe I can somehow demux the menu (to video stream, audio stream AND subpic stream) - can't I edit the info in the subpic? In dvdsubedit it says:

DCSQT: 0
Set Color: e2=0 e1=0 p=0 b=0
Set Transparency: e2=0 e1=15 p=15 b=15
Set Display Area: sx=247 ex=490 sy=118 ey=414
Set field indexes
Forced Start

Perhaps it is these numbers that matter...

[manono]

I had been thinking of this when writing my previous (useless) reply, but didn't mention it because I wasn't entirely sure how to do it myself.

In your own previous reply you mentioned demuxing the menu (easy enough using PGCDemux) and my thought was to reauthor the menu cell and replace it using VobBlanker. One problem with that is you have to convert that edited BMP into either a SUP or SST subtitle file for reauthoring using Muxman, the authoring program with which I've had the most experience. Or maybe create a different kind of subtitle file for authoring in any other authoring program with which you're more familiar.

And then it's easy enough to replace the cell in VobBlanker, except I've never replaced menu cells with edited subpics and don't really know if it'll work as-is or if there are other things that might have to be done to make it play properly.

[mazinz]

I had been thinking of this when writing my previous (useless) reply, but didn't mention it because I wasn't entirely sure how to do it myself.

In your own previous reply you mentioned demuxing the menu (easy enough using PGCDemux) and my thought was to reauthor the menu cell and replace it using VobBlanker. One problem with that is you have to convert that edited BMP into either a SUP or SST subtitle file for reauthoring using Muxman, the authoring program with which I've had the most experience. Or maybe create a different kind of subtitle file for authoring in any other authoring program with which you're more familiar.

And then it's easy enough to replace the cell in VobBlanker, except I've never replaced menu cells with edited subpics and don't really know if it'll work as-is or if there are other things that might have to be done to make it play properly.

Hmm if he had the old program dvd maestro technically he can do this since it allowed you to import separate images for menu and subpic, then again dvdlabpro which had a similar layout may allow that as well, though neither being free programs

[dilophosaurus65]

So many interesting suggestions from you both, I'll sure be trying every one of those!! And keep in touch here.

[EddyH]

Reading between the lines here, you're probably out of luck unless you go to the trouble of fully re-authoring the disc (this is one of the many reasons why DVD annoys the heck out of me). As just written in another thread, DVD subpictures are actually RLE compressed, essentially using a very simplistic and less efficient form of GIF or compressed-BMP encoding, and their compression efficiency drops dramatically when faced with horizontal detail (which your lettering would certainly count as).

The uncompressed sizes you found by measuring the image dimensions don't really matter so much in this case; the original subpic will be very, very small on-disc, in comparison to its unpacked size, as it's an RLE encoder's dream - most of the lines have no detail on them at all and can probably be represented in a few dozen bits (a few repeats of "maximum representable number of pixels, colour = black"). The ones occupied by the top and bottom buttons have only two colour transitions per line; essentially you take that same data but interrupt it just before halfway across (maybe changing one of those blocks to define a shorter run of black) and insert an extra block that simply says "X number of pixels, colour = red", where by eye I'd say X varies between maybe 4 and 16, and then pads to the end of the line with black again. The middle lines where the left and right buttons sit insert two similar code blocks, just about one third and two thirds the way across instead. That picture should take up only 1 or 2kb at the very most, if not just a few hundred bytes (heck, the original BMP is only ~6kb, and the raw DVD subpicture data generated from it - which is 2-bit, not 1-bit - would be about 12kb).

The additions you made are fairly simple, but they're almost as tall - ie, they add red-pixel data to about as many lines - as the buttons themselves at the top and bottom, so at the very minimum making it as if there were two vertically stacked buttons there with the matching additional data load, and similarly the left/right text is at least equivalent to adding an extra two buttons along those middle lines... bearing in mind doing so can also make the black encode less efficiently if the longest run of it between red pixels is less than the representable maximum (in the region of 64 pixels iirc).

But actually, the text is somewhat wider than those buttons, and is made up of a number of what are essentially separate buttons (ie the individual letters), so that's a lot of extra "red" (and short black) blocks to insert. The data load is already climbing quite rapidly. And then you have to consider each letter's complexity in the horizontal direction, which looks quite fine, certainly like there are red or black parts which are no more than 2 or 3 pixels wide in several places; elements 3 pixels wide is roughly where encoded size is equal to raw size, and 2 or 1 pixel wide blocks actually use more data once encoded than they did originally. The more complex letters may well use as much data each as an entire blank black line does. The total number of bits used to represent the image therefore has gone sky-high.... maybe not objectively so, but certainly in comparison to what it was originally. If the compressed version now takes up 3 or 4kb when originally it might have been less than 1kb, then it simply isn't going to fit. It doesn't matter whether that's actually "a lot" of data or not - if it's a single byte, or even a single bit too long, it will be rejected, as that last bit can't be stored without moving or overwriting something else. And if you're going to move the next piece of the data structure forwards, then even with deletable padding, there's going to be some other value in a data table somewhere that will need to be updated, and it might not be obvious what it is, meaning you'll have to do an exhaustive search of all the rest of the PGC and IFO (and VOB?!) structures just to make sure.

It might yet be possible to do some clever hacking and make it work, but it depends on how big the actual outline of your subpicture is; it would be useful if, e.g. the area on those mostly-black images that's NOT subpicture could be filled in with some other colour (primary green or magenta is traditional; neither is really appropriate here, nor white, due to possible clashes with the menu image or the subpic detail, so maybe an amber or sky blue?) to better highlight what part of the entire screen it takes up and how much of a border there is, that may help. Given that 244x216 isn't THAT big vs a 720x576 frame, I'm quite surprised and impressed you managed to fit the left and right button text in there, and figure there's likely no fat that can be trimmed off.

(In fact, looking at it again... no, something's not right, there is NO WAY your subpicture is still 244 pixels wide, unless something very strange is going on with the encoding. I'd expect it to be closer to twice that, and probably 300+ high, and that's without allowing any excess border at all, ie it can't be trimmed down. How did you measure that size?)

If you still want to highlight the text as well as the buttons, an alternative might be to *outline* it? As in, instead of filling in the white parts within the black outlines (which, to be perfectly frank, might actually look pretty terrible and not be very easy to read, depending on your screen and connection method - NTSC may be infamous for mishandling primary red, especially on a black or white background, but PAL isn't *so* much better at it, unless you have a proper RGB connection; there's a reasonable chance the original menu author did that on purpose to get a fuzzy, glowing effect "for free", even!), you could try putting a red glow AROUND that outline? Maybe even overlapping halfway onto it? But not enveloping each letter, is the thing - the idea is to reduce how detailed the image is, as much as possible, especially in the horizontal direction; which can be achieved very nicely by not drawing the actual letter detail, or putting in outlines that separate each letter...

And taking it further, it might be possible to trim the actual subpixel outer dimensions down by making it look more like a glow from the buttons as they turn red... so, it only wraps around the upper side of the lower text, lower side of the upper, and ditto for left and right.

Really, I'd be sore tempted to look at how complicated it might be to re-author the entire disc, because if there's not much padding around the existing subpictures within however many packs they take up (and really, if it's more than one, you're almost certainly screwed, what we need is for them to take up less than a third of a single pack), you could trim it down to be almost no different from the original at all, after hours of work and multiple retries, and it still wouldn't fit. Whereas if you reauthor it, even without changing or re-encoding any other part of the whole (which I expect you already did, though, which is how you've ended up at this point, so at worst you'd just need to do that bit again), you can make the image as complex as you like, within the limits of the format itself (300-and-some transitions per line...), and it might not even take very long.

[awgie]

When you export or edit a subpic with DVDSubEdit, it creates an image file the full size of the screen so the subpic is in the correct location. But that's not how the DVD itself handles subpics.

The image is cropped before it is stored. Only the displayed portion of the subpic is stored in the VOB. The "Set Display Area" in the subpic definition indicates the exact location on the screen where that image is to be positioned.

So by adding the text to the image, you have effectively changed the image from a 242x256 picture (61952 pixels) to a 527x329 picture (173383 pixels - nearly 3 times as many), and the data won't fit in the same space within the VOB file.

[EddyH]

That, and it's RLE compressed, so adding a bunch of detailed text to what was previously just four simple ovals will have quite likely doubled the total file size (or more?) even if the outline was the same... If it's also ~2.8x larger in area as it is here, that could be a more than 5x increase.
(well OK, maybe more like 3.5 to 4x, because the additional black areas will compress quite well, but we do have to allow for the text not only being more complex but also larger)

But, yeah, it can be surprising how much the storage requirements for even uncompressed images can mount up with deceptively small changes in outer dimensions. Take an underscanned computer image at 320x200, fitting into less than 64kb of space... adjust it so it more closely fills the available space on a CRT, which doesn't *look* like much of an increase... it's maybe now 364x240, still not a massive image... oops, you need nearly 90kb now!
(and oddly it's harder to judge because they ARE small when rendered on a typical computer screen, and there's not much context for the scale when it's just some red stuff on a plain black background)