On Fri, 24 Jul 2015 14:11:12 -0700, John Larkin wrote:> On Fri, 24 Jul 2015 14:55:50 -0500, Tim Wescott > <seemywebsite@myfooter.really> wrote: > >>On Thu, 23 Jul 2015 19:56:41 -0400, Phil Hobbs wrote: >> >>> On 7/23/2015 7:22 PM, John Larkin wrote: >>>> On Thu, 23 Jul 2015 17:54:47 -0500, Tim Wescott >>>> <seemywebsite@myfooter.really> wrote: >>>> >>>>> On Thu, 23 Jul 2015 15:30:11 -0700, John Larkin wrote: >>>>> >>>>>> On Fri, 24 Jul 2015 01:19:09 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>>>> wrote: >>>>>> >>>>>>> On 24.7.2015 ?. 00:50, John Larkin wrote: >>>>>>>> On Fri, 24 Jul 2015 00:13:19 +0300, Dimiter_Popoff >>>>>>>> <dp@tgi-sci.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 23.7.2015 ?. 23:49, rickman wrote: >>>>>>>>>> On 7/23/2015 4:34 PM, Phil Hobbs wrote: >>>>>>>>>>> On 7/23/2015 2:18 PM, John Larkin wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm designing a tachometer box and it will have a web page >>>>>>>>>>>> interface as one way to talk to it. I thought it would be >>>>>>>>>>>> cool to include an ADC so we could display waveforms, too. My >>>>>>>>>>>> software guys here are mostly embedded types so we don't know >>>>>>>>>>>> a lot about Javascript and such. I did a little searching and >>>>>>>>>>>> mostly found things for displaying audio envelope cartoons; I >>>>>>>>>>>> want a real oscilloscope-looking thing, so users can see what >>>>>>>>>>>> happens as they change gains and filtering and trigger level >>>>>>>>>>>> settings. Dual trace would be nice, the analog waveform and >>>>>>>>>>>> corresponding comparator outputs. >>>>>>>>>>>> >>>>>>>>>>>> Has anybody done this? We'd consider getting outside help, >>>>>>>>>>>> either advice or actual coding. >>>>>>>>>>>> >>>>>>>>>>>> I assume our box will, through some port, deliver HTML, >>>>>>>>>>>> Javascript, and maybe some zipped JS libraries to the >>>>>>>>>>>> browser. And the company logo of course. The browser will >>>>>>>>>>>> send us text strings to parse if the user wants to change >>>>>>>>>>>> parameters or such. We would also deliver blocks of waveform >>>>>>>>>>>> data on request. >>>>>>>>>>>> That's my PHB perspective on things; I'm just the hardware >>>>>>>>>>>> designer. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> One approach is a CGI script that runs gnuplot under the >>>>>>>>>>> covers. >>>>>>>>>>> IIRC quite a few folks do that. (I'm a static HTML guy >>>>>>>>>>> myself.) >>>>>>>>>> >>>>>>>>>> Isn't there an actual oscilloscope display package under Linux? >>>>>>>>>> It should be fairly straightforward to drive that from an >>>>>>>>>> internet connection. I guess requiring the customer to >>>>>>>>>> installing such a package is not preferred. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> He is after a browser plugin - something like VNC, the way I do >>>>>>>>> it on our spectrometers (I do not use a plugin but I could if I >>>>>>>>> wanted to). >>>>>>>> >>>>>>>> Actually, I don't want a plugin, just a way for the browser to >>>>>>>> display a waveform, using some javascript. We can store any >>>>>>>> reasonable zipped javascript libraries in our gadget and deliver >>>>>>>> them to the browser. >>>>>>> >>>>>>> I am not sure I have seen that done for live graphics - then >>>>>>> scaling, perhaps autoranging etc., even if doable it would be a >>>>>>> massive pain to support with all browsers as they keep on >>>>>>> evolving. >>>>>>> Your best bet might be to produce locally a .gif (or .png or >>>>>>> whatever) >>>>>>> bitmap, maintain it live and persuade the browser to refresh it >>>>>>> regularly. Don't know how the latter is to be done though. >>>>>> >>>>>> We could do that in the FPGA! If nobody murders me for suggesting >>>>>> it. >>>>> >>>>> I don't know how to persuade a browser to auto-refresh, but GIF >>>>> format uses run-length limiting for compression. That means that >>>>> line drawings of few colors tend to be very small -- you'll use up >>>>> way more bits on text than on the pictures. >>>> >>>> There is some simple HTML thing that makes a page reload >>>> periodically. That's apparently easy to do. >>>> >>>> A BMP would be easy to make inside the FPGA, but that would be slow >>>> to load. Maybe the ARM could make a GIF or PNG. That would avoid all >>>> the javascript nonsense. We'd just have to find the code somewhere. >>>> >>>> This bmp is 556K bytes. >>>> >>>> https://dl.dropboxusercontent.com/u/53724080/Circuits/Current_Limiters/>>LM317L_ilim.bmp >>>> >>>> That wouldn't be really terrible to send once a second or so over 100 >>>> MBPS Ethernet. But my FPGA doesn't have enough RAM. >>>> >>>> >>> Bumpfiles are simple, so that's a win. I usually generate those in my >>> code, then (in a script) call ImageMagick's 'convert' to make them >>> into .jpg or .png or whatever. >>> >>> Cheers >>> >>> Phil [system("convert foo.bmp foo.png") covers a multitude of >>> sins]Hobbs >> >>Kinda hard for John to do since he has no OS (if I remember this whole >>thread well enough). > > 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.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: <<https://drive.google.com/file/d/0B5lSHlBBxGvjNl90MFA0MkI5NlU/view? usp=sharing>> <<https://drive.google.com/file/d/0B5lSHlBBxGvjQ2l1T05qV1VvejQ/view? usp=sharing>> -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
waveform display in browser
Started by ●July 23, 2015
Reply by ●July 24, 20152015-07-24
Reply by ●July 24, 20152015-07-24
On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote:> On Fri, 24 Jul 2015 20:15:21 +0000, Grant Edwards wrote: > >> Implementing LZW in an FPGA would be a daunting, but people have done >> it. > > I'm not so sure it would be all that bad, if you were writing > something specific to GIF format.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.>>> I'll even do it for you -- if you wait until November for me to get >>> started on it. > > My offer still stands, GIF or TIFF. John's looking at SVG, which isn't a > bad choice if it's universal.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 ...
Reply by ●July 24, 20152015-07-24
On Fri, 24 Jul 2015 18:42:11 +0000 (UTC), sipping burgundy and listening to Mahler, Grant Edwards <invalid@invalid.invalid> wrote:>On 2015-07-24, John Larkin <jlarkin@highlandtechnology.com> wrote: > >> I heard that Flash is on the way out. And I think that a lot of my >> customers may not install Flash. > >If you do it in Flash, it won't work on iPads, or in the current >version of Firefox (which blocks flash), or in any browser configured >by sane people everywhere.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.
Reply by ●July 24, 20152015-07-24
On 2015-07-24, Jasen Betts <jasen@xnet.co.nz> wrote:> On 2015-07-24, Grant Edwards <invalid@invalid.invalid> wrote: >> On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote: >> >>> If I recall correctly, GIF encoding is on the lines of >>> >>> 100 black, 1 white, 25 black, etc., for each line. >> >> 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. > > no, N bits per colour with a 3*2^N table ( 1 <= N <= 8 ) >i mean per pixel. -- umop apisdn
Reply by ●July 24, 20152015-07-24
On 7/24/2015 6:41 PM, Jasen Betts wrote:> On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote: >> On Thu, 23 Jul 2015 16:22:04 -0700, John Larkin wrote: >>> >> 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. > > No, Gif uses LZW compression not RLE. there was a LZW compatible RLE > encoder, but that was purely a patent dodge. > >> So if you could generate a bmp in your FPGA, > > 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)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
Reply by ●July 25, 20152015-07-25
On 24.07.2015 23:11, John Larkin wrote:> > 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.You can calculate the bitmap within the browser. Here a minimal html file which displays a random bitmap: <!DOCTYPE HTML><html> <head></head><body><script> window.onresize = resize; function resize(){window.location.href=window.location.href;} var intFrameWidth = window.innerWidth-16; var intFrameHeight = window.innerHeight-24; document.write('<canvas id="Canvas" width="'+intFrameWidth+'" height="'+intFrameHeight+'"></canvas>'); 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); </script> </body> </html>
Reply by ●July 25, 20152015-07-25
On 2015-07-24, Clifford Heath <no.spam@please.net> wrote:> On 25/07/15 08:44, Jasen Betts wrote: >> On 2015-07-24, Grant Edwards <invalid@invalid.invalid> wrote: >>> On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote: >>> >>>> If I recall correctly, GIF encoding is on the lines of >>>> >>>> 100 black, 1 white, 25 black, etc., for each line. >>> >>> 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. >> >> no, N bits per colour with a 3*2^N table ( 1 <= N <= 8 ) > > That's incorrect. GIF uses an 8-bit (256 element colour map) that has > 3x8-bit RGB elements. The actual image data is 8-bit indices into that > colour map, LZW compressed - exactly what Grant said.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
Reply by ●July 25, 20152015-07-25
On 2015-07-24, Clifford Heath <no.spam@please.net> wrote:> On 25/07/15 00:08, Jasen Betts wrote: >> On 2015-07-24, Martin Riddle <martin_ridd@verizon.net> wrote: >>> On Thu, 23 Jul 2015 21:08:55 -0700, John Larkin >>> Be willing to support future browsers with a firmware update. >> If you get it right you won't need to update. >> Don't guess, follow the standards, it's just like reading a datasheet, >> except that errors in the description are fixed by updating the product. > > Don't try to read or follow the standards, because those don't tell you > which browsers diverge from the standard or in what way.that doen't matter because browsers only get better, if you write good javascript that works today. it will still work in 10 years.> Instead, use a Javascript library that papers over the differences. The > vast majority of sites now use JQuery for that, and nothing will change > in the browsers that stops that working properly.replacing 100 lines of well written javascript with 3000 lines is not likely to help long-term reliability. -- umop apisdn
Reply by ●July 25, 20152015-07-25
On 2015-07-24, Clifford Heath <no.spam@please.net> wrote:> On 25/07/15 08:08, Grant Edwards wrote: >> On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote: >>> My offer still stands, GIF or TIFF. > > TIFF is Tagged Image File Format. It's not an compression format, though > it supports many compressions. With monochrome data, the G4 fax encoding > is truly spectacular.I guess the only format I ever worked with in TIFF was the run-length encoduing used by faxes. I had forgotten there were other options for compression.> SVG wasn't available in IE prior to version 8. Other older browsers > that didn't do SVG have almost all been upgraded, so its reasonable > to require that. > > If you want to use SVG, but fall back to VML back as far as IE5, I > recommend the Raphael Javascript library at <http://raphaeljs.com>. It > does what it says on the box. But these days I'm just using SVG.It's good to hear that SVG support is common enough to be useful. The last time I needed to do data plots on web pages was something like 6-7 years ago, and SVG was a bit too bleeding edge at the time. -- Grant
Reply by ●July 25, 20152015-07-25
On 2015-07-24, YD <ydtechHAT@techie.com> wrote:> On Fri, 24 Jul 2015 18:42:11 +0000 (UTC), sipping burgundy and > listening to Mahler, > Grant Edwards <invalid@invalid.invalid> wrote: > >>On 2015-07-24, John Larkin <jlarkin@highlandtechnology.com> wrote: >> >>> I heard that Flash is on the way out. And I think that a lot of my >>> customers may not install Flash. >> >>If you do it in Flash, it won't work on iPads, or in the current >>version of Firefox (which blocks flash), or in any browser configured >>by sane people everywhere. > > 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.Blocking flash (with an optional white-list) is absolutely essential to making the 'web a useful place. Unless it's a site providing someting I desperately need, I usually just completely avoid web sites that require flash to get something done. -- Grant
