Greetings everyone,

As I continue down the learning path of my 9600, I've just hit the hard wall today...out of memory. The current config file now will not download to the device as it indicates that the file is simply too large to load into the Pronto.

A little bit about my file. I've pretty much emulated LowPro's type of implementation for DVD's and the like. As it turns out, my image sizes are pretty close to LP's. One thing I did take a different approach on was the use of JPG instead of PNG. After generating cover art, JPG's were coming in at almost half of the PNG's and at the slated screen size, there was no visible difference in quality. So I opted to use JPGs instead. But I must pay the proper respect to LP as he has provided me with the basic inspiration and look for what I thought to be a well thought out approach. I've added a few tweaks of my own, but nothing huge. As I have been developing the file, I've watched the free memory decrease steadily and it was still at 25% which I thought was still ok. Then, today, it just spit out a message indicating that the file was too large to load. And I thought I was actually helping this by reducing some of the graphics and reloading those images!

My problem is, my DVD library is *half* of what LP's is. I did take the approach to use the built-in font where reasonable instead of PS generated graphics/text as this did seem to have a distinct impact upon the over all file size. Not as pretty as what I wanted from PS, but this approach did seem save on the file size.

So, my fundamental question is...how to gain back memory and reduce the overall file size. I like what I have at this point but there must be a way to compact this thing into something more efficient.

So some questions are;
1. Does the editor/hardware handle one graphic format more efficiently than the other?
2. Do removed objects (i.e pages, devices, graphics, etc.) from the editor leave "trash" in the file that remains even though they have been cut/removed from the file?
3. Do learned codes for devices steal memory?
4. Are there any diagnostic tools to insure that my Pronto is seeing all of its installed ram? (i.e., not something in hardware causing this issue)

LP...can you chime in here with your thoughts?

Thanks!

1. If it works the same way as the Pronto NGs, JPGs are converted internally to PNGs and end up taking a lot more room. Starting with PNGs in the first place is the most efficient.

2. No - just take a look at the XML that is generated in the XCF. You might want to check that old images are not still being referenced.

3. Of course - the learned code has to be stored somewhere. Even database codes get copied down to the Pronto and take up space in the config.

Thanks for the reply Peter.

1. Well, that conversion would be very interesting to be sure. I was hoping that my efforts to use JPGs where I could would go a long way in reducing memory usage. If you are correct, then my efforts in this area are simply wasting time and not entirely effective. Switching back to native PNGs poses no issue, just a lot or reinserting the appropriate graphic....wish dynamic imaging was a reality on this platform. This problem would then simply vanish.

2. Ok...dumb quetion here. Are you saying look at the XML code to check those references? How does one do this? I've never delved into XML but am a willing learner.

3. The purpose on this issue was that I was wondering if learned codes occupy more space than some other "native" code.

Again, thanks

2. Take a copy of your XCF and rename it to have a .ZIP extension. Open teh ZIP file and you will see the XML and a folder containing the images. If tehre are unwanted images there, you will need to find where they are referenced in your config. If you can't find it using the editor, you could try looking at the XML.

3. It is not clear how a database code is stored in a 9600. In previous versions, the whole datbase was stored in the firmware of the Pronto and your config just had pointers to the codes you used. This does not happen with the 9600. It can't take more space than a learned code so a database code would be expected to use less or the same amount of memory. However, the amount of memory all your codes take would be minuscle copared to the total memory size.

Do as Peter suggests, unzip the file, replace .jpg with .png and for each "Bitmap_xxx" file, edit ConfigEdit.xml and change the file extension from .jpg to .png.

That's the only real memory saver here.

One thing you should contemplate doing is storing your graphics outside of your config. Consider writing a PC program to serve up images or or putting them on a web server. It is anticipated that the next version of firmware will support dynamic image download.

Once we have this capability, there should really be no reason to maintain the LowPro DVD Lobby format on these remotes any longer.

Just my 2p.

Lyndel

Thanks Lyndel

I have all of my graphics already prepared and ready if/when this becomes a reality. Are individuals like yourself or others working on this code that may/might be shared publicly here with others seeking this functionality? It will certainly go a long way in alleviating this memory issue.

Thanks,
PC

PC, for what it's worth, I too, use LowPro's DVD Lobby format to run my DVD collection from my TSU7000 remote control.

To free up as much memory as I can for my 72x100 DVD cover jackets, I use Adobe Photoshop 7.0 and save the images as PNG's using the "Save for Web ..." dialog box feature.

What is the file size of each .jpg file?

I would suspect you may have some other graphics in there which could be reduced?

Any unusal backgrounds in use, like pictures, etc. Any excessive pages in other devices? (other than LP's DVD device).

Maybe turn automation off?

Dave

Yes...this is the understood format. I am using PS CS3 for all of my graphics creation and modification. The "save for web" is also what I use to prepare all of the covers.

Thanks for the addtional input!

Hi Dave,

I've pretty much stripped out everything else in my config. I'm using many of the built-in/supplied backgrounds from the basic environment. My covers are similar to the size of LP's (within a few pixels in dimensions). When I compared the JPG cover to the PNG cover, the JPG was basically 1/2 the size of the PNG file. That's why I thought I could use these instead of PNGs for my covers. Last night, I started a few simple replacements of these JPG's with their PNG opposites and watched the file sizes as I replaced these. Oddly enough, the overall file size on the congfig started to reduce as the PNG replacements were inserted. Odd, but true so Lyndel's suggestion for this problem appears to be correct. Although I'm fairly well along in this process, I can still replace the JPGs with their PNG opposites. I'm going to look into the XML option to see if I can identify any other "trash" that might be carrying in the config. This may further reduce the size. Haven't spent any time in XML but, I can learn!

Hey, it's a labor of love and I want this device to be an aid in the house, so getting it right will involve a bit of work. But in the end, it will be worth it. I may not be as sophisticated as others here in this forum, but with all the other work going on here and the great advice here that others post goes a long way in helping out individuals like myself in getting their Prontos to integrate into their homes.

Hopefully, these suggestions will help me get a bit more control over this undertaking.

The 9600 uses a native PNG engine to display graphics. That is, PNGs retain their size upon download. JPG files, however, are most likely converted to 24bit images during download.

You can compare an contrast file sizes by viewing the 'DATA' directory where the editor is installed during a download. The .bin or .dat file that is there is the real size of your config.

I discussed how to do this a while back in the NG forum. Here's a link.

[Link: remotecentral.com]

Keep in mind that PCF and XCF although for different remotes still likely use the same download engine. You can use a small XCF file with a single panel to test. All you have to do is swap out between JPG and PNG and you should see the difference.

Peter,

I tried this and the zip file had nothing inside of it. No other files, nada. I know it's a simple rename but no joy on this approach.

Any ideas?

Change the .XCF to .ZIP.

If you are not seeing .XCF, then you need to make sure you do not have "Hide Extensions for Known File Types" turned on.

If you have Windows XP or Vista, you just need to double click on the Zip file to open it. Any other version, you will ned to get WinZip or WinRAR.

JPG's when converted to PNG files via the Pronto editors (this includes the editors for the Pronto NG line as well) are saved as 24-bit images. As a result, inserting JPG's does nothing but ensure that each graphic used in your XCF takes up the most space possible. To optimize the size of your XCF on the graphics end always insert PNG's after first making sure that each PNG file has been saved at the lowest color depth possible while still maintaining the visual quality you find acceptable.

LP,

See my post #11 above.