Yeah, there are way too many Flash vulnerabilities.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
I think FF just blocked it to "force" adobe to fix a number of known exploits with the latest flash update it isn't blocked
-Lasse
LM317L_ilim.bmp
Kinda hard for John to do since he has no OS (if I remember this whole thread well enough).
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
LM317L_ilim.bmp
I haven't personally done this, but I've poked at it, and an office-mate of mine did it, before all the file conversion stuff was readily available.
If I recall correctly, GIF encoding is on the lines of
100 black, 1 white, 25 black, etc., for each line.So if you could generate a bmp in your FPGA, you could generate the meat of a GIF almost as easily, then have the ARM processor wrap it with the appropriate header and footer and send it out.
I'll even do it for you -- if you wait until November for me to get started on it.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
LM317L_ilim.bmp
Whoops -- it's LZW encoding. It should still be fairly easy to implement, possibly even in FPGA-land. And, if not, there's probably code chunks out there in C.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
That's call run-length encoding, and it's what TIFF uses.
GIF files are encoded as 8-bits-per-pixel (with a 256-byte color lookup table), and then compressed using the Lempel-Ziv-Welch algorithm.
Implementing LZW in an FPGA would be a daunting, but people have done it.
--
Grant Edwards grant.b.edwards Yow! Gee, I feel kind of
at LIGHT in the head now,
gmail.com knowing I can't make my
satellite dish PAYMENTS!
And I won't have much ram; 256K bytes in the ARM, and some in the FPGA, but not enough to store an entire bmp anywhere.
SVG looks good so far; all we'd have to do is send the data points, as text, not an image. A couple of kbytes might do it.
-- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Huh. I musta had TIFF and GIF confused. TIFF may be suitable, if John doesn't end up using SVG.
I'm not so sure it would be all that bad, if you were writing something specific to GIF format.
My offer still stands, GIF or TIFF. John's looking at SVG, which isn't a bad choice if it's universal.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Current_Limiters/
I would make sure that SVG is universally available on browsers, but if it is -- go for it.
GIF or TIFF would reduce a typical O-scope image down to kbytes, too. TIFF, it appears, uses a bunch of different compression formats (including LZW); if you use the RLL version then the file is bigger than GIF, but still less than 100kB.
Just for giggles I did it, once to GIF, and once to TIFF using RLL. The GIF file here is 10kB, the TIFF file is 25kB:
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
I think you're right. It sounded nasty to me based on the descriptions of the LZW that I remember, but according to Google there have been a lot of people who've done it.
SVG is pretty nice, but until the past couple years, SVG support in browsers was pretty iffy. If you don't have to support old browser versions, SVG is worth looking at.
--
Grant Edwards grant.b.edwards Yow! over in west
at Philadelphia a puppy is
gmail.com vomiting ...
I have FF set to ask, and remember the ones I know and approve. Games mostly. A lot of pages are loading faster now. I had no idea how many ad-banners are Flash. Now there are grayed-out areas where they used to be.
- YD.
yeah, it does pixel (Canvas) vector (SVG) and 3D accelerated (WebGL) animation, video (H.264) out-of-band comms (websocket) and peer-to-peer (WebRTC) and wuite possibly other things.
I see any number of Flash games, but so far
Google put some games on its front page earlier this year.
-- umop apisdn
No, Gif uses LZW compression not RLE. there was a LZW compatible RLE encoder, but that was purely a patent dodge.
you don't need to generate the bitmap first, the pixel colour can be determine4d algorithmically (eg by running several bresenhan line algorithms in objects in a heap) gif compression only needs one pixel at a time. (but why bother, just send coordinates and call it SVG)
-- umop apisdn
The color map doesn't have to be full.
How so you survive in a technical career without being able to use Google?
Clifford Heath.
no, N bits per colour with a 3*2^N table ( 1
Replacing decades of hard-learned experience that's been distilled into the minimum possible code that actually handles all the warts of all the weird-ass browser versions out there, with some shit you just invented by believing the standards which almost nothing actually complies with is...
a *guaranteed* recipe for almost immediate failure.
Likewise, the bitmap doesn't need to be generated all at once. It can be generated one pixel at a time and sent out immediately requiring no bitmap storage at all. I considered doing this in a small oscilloscope once where the image would be generated in the chip and sent out a port rather than stored. Much of the display is fixed or text with the traces impacting the display in an easy to calculate manner... at least easy in a chip with many fast ALUs which sounds a lot like an FPGA to me.
-- Rick
You can calculate the bitmap within the browser. Here a minimal html file which displays a random bitmap:
window.onresize = resize; function resize(){window.location.href=window.location.href;} var intFrameWidth = window.innerWidth-16; var intFrameHeight = window.innerHeight-24; document.write('');
var canvas = document.getElementById('Canvas'); var context = canvas.getContext('2d');
// Creates an Image Object of size intFrameWidth * intFrameHeight var imageData = context.createImageData(intFrameWidth, intFrameHeight);
// Takes data in the Canvas Pixel Array var CanvasPixelArray = imageData.data;
// Calculate total no of pixels var total_pixel = imageData.width*imageData.height;
// Random RGBa values for each pixel for (var i = 0; i < total_pixel; i++) {CanvasPixelArray[i*4] = Math.floor(Math.random()*255); CanvasPixelArray[i*4+1] = Math.floor(Math.random()*55); CanvasPixelArray[i*4+2] = Math.floor(Math.random()*155); CanvasPixelArray[i*4+3] = 255; };
// Display the Image context.putImageData(imageData, 0, 0);
You're making shit up.
I just made a gif file here that's 73 bytes. explain that.
1 bit per pixel (before compression) monochome gifs were done and other colour depths too. the palette is variable length (I can't remeber if it's fixed to 2^n slots or allowed to be intermediate sizes. GIF was invented in 1987 when very few people had 8-bit colour displays.jasen@fozzie:~$ cat 1.pbm P1
1 1 1 jasen@fozzie:~$ convert 1.pbm 1.gif jasen@fozzie:~$ ls -l 1.gif-rw-r--r-- 1 jasen jasen 73 Jul 25 21:14 1.gif jasen@fozzie:~$ giftrans -l 1.gif Global Color Table: Color 0: Red 0, Green 0, Blue 0, #000000 (black, gray0, grey0) Color 1: Red 255, Green 255, Blue 255, #ffffff (white, gray100, grey100)
-- umop apisdn
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.