What is the proper syntax for calling a image file that is not hosted within the project? I know in the example projects there are images in folders, but if I want to link to one that’s hosted at BrightCove, what would be the proper way to do that?
ABBREVIATED EXAMPLE
Sub initTheme()
app = CreateObject("roAppManager")
theme = CreateObject("roAssociativeArray")
theme.OverhangSliceSD = "pkg:/images/Overhang_BackgroundSlice_Blue_SD43.png" '<<==NORMAL WAY TO SET IMAGES
theme.OverhangLogoSD = <WHAT URL FORMATTING GOES HERE??>
app.SetTheme(theme)
End Sub
I tried several different combinations and they all didn’t seem to work.
Are you trying to set a non-locally hosted overhang logo pic? You’re really better off snagging it from the web and editing it yourself to make sure that you get it the right size so it will display correctly. Other than exacting size specifications in theme- work, you can set image url for poster screens, spring boards, etc. just by using the url. Those objects don’t have strict dimension requirements like your theme pics
I was actually trying to offload as many images as I could as I read there is a limitation to what can be saved to the Roku, and they suggested hosting them elsewhere if you have a bunch (which I will). I already got a couple of warnings when side loading the project that I’m going over on size.
I had our graphic artist go through and make images as per dimensional guidelines, now was hoping to host them at BrightCove.
Overhangs HAVE to be hosted in the .pkg, poster images and most others can be hosted anywhere. You can however use the download function to download the overhang locally to the box and then use it for an overhang, although I haven’t tested that this works.
There’s a 500k soft limit, and 2000K hard limit to channels (after zip conpression). If it’s a core part of the channel, I suggest including it in the package. If it’s dynamic in nature, then yes, definitely offload it.
Last I heard not all components allowed remote URLs to be used to define the files, but in that case you can use an roURLTransfer to download it to a file in tmp:/ and reference it there. If it’s part of the initial screen, and you still want to remotely reference it, I suggest displating some sort of splash screen while that’s happening.
“brocker” wrote:
I was actually trying to offload as many images as I could as I read there is a limitation to what can be saved to the Roku, and they suggested hosting them elsewhere if you have a bunch (which I will). I already got a couple of warnings when side loading the project that I’m going over on size.
I had our graphic artist go through and make images as per dimensional guidelines, now was hoping to host them at BrightCove.
Thanks
Bud
Those theme files should be so small in size that really it’s not worth going to the trouble of keeping it out of the package. If you were even able to put all image data off-site, if the channel were to have connection issues, or the box itself had connection issues when the user opened it, only a skeleton-like frame would show in the channel and kind of look crappy if you know what I mean.
What is the proper syntax for calling a image file that is not hosted within the project? I know in the example projects there are images in folders, but if I want to link to one that’s hosted at BrightCove, what would be the proper way to do that?
ABBREVIATED EXAMPLE
Sub initTheme()
app = CreateObject("roAppManager")
theme = CreateObject("roAssociativeArray")
theme.OverhangSliceSD = "pkg:/images/Overhang_BackgroundSlice_Blue_SD43.png" '<<==NORMAL WAY TO SET IMAGES
theme.OverhangLogoSD = Some good advice from the other posters, and here's some example code
“brocker” wrote:
I was actually trying to offload as many images as I could as I read there is a limitation to what can be saved to the Roku, and they suggested hosting them elsewhere if you have a bunch (which I will). I already got a couple of warnings when side loading the project that I’m going over on size.
I had our graphic artist go through and make images as per dimensional guidelines, now was hoping to host them at BrightCove.
Thanks
Bud
Those theme files should be so small in size that really it’s not worth going to the trouble of keeping it out of the package. If you were even able to put all image data off-site, if the channel were to have connection issues, or the box itself had connection issues when the user opened it, only a skeleton-like frame would show in the channel and kind of look crappy if you know what I mean.It could be coded to have fall back files in the package, if the hosted ones are unavailable.
“brocker” wrote:
I was actually trying to offload as many images as I could as I read there is a limitation to what can be saved to the Roku, and they suggested hosting them elsewhere if you have a bunch (which I will). I already got a couple of warnings when side loading the project that I’m going over on size.
I had our graphic artist go through and make images as per dimensional guidelines, now was hoping to host them at BrightCove.
Thanks
Bud
Those theme files should be so small in size that really it’s not worth going to the trouble of keeping it out of the package. If you were even able to put all image data off-site, if the channel were to have connection issues, or the box itself had connection issues when the user opened it, only a skeleton-like frame would show in the channel and kind of look crappy if you know what I mean.It could be coded to have fall back files in the package, if the hosted ones are unavailable.
it could, but then that’s defeating the intended purpose of moving images out of the package and only saves the space difference between the two sets of images, and adds to the work
“stratcat96” wrote:
it could, but then that’s defeating the intended purpose of moving images out of the package and only saves the space difference between the two sets of images, and adds to the workTrue, if the purpose is space-saving. I was thinking of dynamic theming. And wouldn’t really be that much work.
“brocker” wrote:
I was actually trying to offload as many images as I could as I read there is a limitation to what can be saved to the Roku, and they suggested hosting them elsewhere if you have a bunch (which I will). I already got a couple of warnings when side loading the project that I’m going over on size.
I had our graphic artist go through and make images as per dimensional guidelines, now was hoping to host them at BrightCove.
Thanks
BudIf you’re using png (and you should be ), you can ‘pngcrush’ the files to reduce them to the smallest possible size, without any quality loss. Here’s good forum post on the topic: http://davidwalsh.name/pngcrush
Actually, the most effective png (and .jpg actually) size reduction tool is Adobe ImageReady. I believe the functions of ImageReady have been integrated in photoshop in recent versions, look for an Optimize menu. Recent channels I’ve worked on I’ve managed to squish down to 30 to 80k by doing lots of work optimizing the images. The default images included in the Roku examples are really quite large in file size and can be reduced dramatically without losing any visible quality.
“jbrave” wrote:
Actually, the most effective png (and .jpg actually) size reduction tool is Adobe ImageReady.
Is that tested? I’m not saying pngcrush IS faster, but it actually brute force searches through a fairly large set of optimizations and compression techniques until it finds the one that worked best for that particular image.
Faster? I don’t know, but I’m getting equal or better crushing from adobe, and great .jpg optimization as well - a 50% jpg saved from photoshop without the optimize function looks kinda yucky, whereas a 50% from ImageReady looks great. I used pngcrusher till I discovered that ImageReady (and this is like the last PPC only version of Photoshop/imageready, before mac came out with Intel Processors, so it runs under Rosetta) does a better job on both the file size and the quality of .png file.
Edit: also dropping an ImageReady processed .png on pngcrush does not usually result in a smaller file.
And that last link lists several other image optimization options. Which is best appears to be a matter of some debate ;). In any event, I think everyone agrees it certainly pays to optimize the images.
“jbrave” wrote:
Faster? I don’t know, but I’m getting equal or better crushing from adobe, and great .jpg optimization as well - a 50% jpg saved from photoshop without the optimize function looks kinda yucky, whereas a 50% from ImageReady looks great. I used pngcrusher till I discovered that ImageReady (and this is like the last PPC only version of Photoshop/imageready, before mac came out with Intel Processors, so it runs under Rosetta) does a better job on both the file size and the quality of .png file.
Maybe we’re talking about different things? Pngcrush only reduces unneeded data in the PNG file (throws away comments, etc), and tries different compression techniques to encode the exact same data, comparing the resulting sizes. By it’s nature there is absolutely no data loss. In referring to 50% and a different quality in appearance between PhotoShop and ImageReady, you seem to indicate you are referring to quality level of the saved file, which is something else.
I’ll admit that’s pretty good evidence in ImageReady’s favor.