NOAA radar ..
Peter KG6LSE
Posts: 1,383
I have a question for yall
I have a goal to make a NOAA standalone display that lets me preset a URL in to the prop and the prop based device loads up the NOAA dial up IMG ( . PNG ) in to the prop or ram and then displays it with NTSC or VGA so I can have a standalone non computer based LOW POWER instaint on radar ..
Here is the URL that I am fed for the most simple radar for my area DMX ( desmoins )
http://radar.weather.gov/lite/N0R/DMX_0.png
I can hazard a bet that the prop can read BMP but a PNG is my issue .
can it be done ??
I am thinking of the spinnernet as the IDEAL platform !
OR soon to come WiFI with a PDB then a in the end a home brew board .
With the WiFi I can add a Mobile hot spot and volla a storm chasers dream !
and a good complement to a COTS noaa radio ..
Any ideas are welcome !
Peter
I have a goal to make a NOAA standalone display that lets me preset a URL in to the prop and the prop based device loads up the NOAA dial up IMG ( . PNG ) in to the prop or ram and then displays it with NTSC or VGA so I can have a standalone non computer based LOW POWER instaint on radar ..
Here is the URL that I am fed for the most simple radar for my area DMX ( desmoins )
http://radar.weather.gov/lite/N0R/DMX_0.png
I can hazard a bet that the prop can read BMP but a PNG is my issue .
can it be done ??
I am thinking of the spinnernet as the IDEAL platform !
OR soon to come WiFI with a PDB then a in the end a home brew board .
With the WiFi I can add a Mobile hot spot and volla a storm chasers dream !
and a good complement to a COTS noaa radio ..
Any ideas are welcome !
Peter
Comments
The propeller can certainly display these images - see attached. But there might need to be some pre-processing.
The first one is your entire screen compressed down to 256x224. You lose a bit on that one and the cities are no longer legible.
But zoom in a bit and you can get everything legible. You get 4 of these screens per the large screen.
To make those pictures I ran those pictures through painshop to capture and scale them, and then through a Floyd-Steinberg transform to dither to the propeller colors. You would also need to convert a .png to RGB values prior to doing this.
I think this could be a really practical use for the propeller. I wonder if a few of us could get together and work on various bits of the code that we would need?
http://tools.ietf.org/html/rfc2083
...That seems like a lot of trouble for a PNG file.
A similar issued occurs with .WAV format being useful and .MP3 being unavailable due to compression.
I convert .PNG files to .BMP with ImageMagick - a powerful and free software application that runs at the command prompt. It may be helpful if you need to convert images, but the conversion takes place on a PC - not in a Propeller.
If you can develop the means to uncompress and resize a .PNG on a Propeller, it would be very useful. I suspect others here would be interested in helping out. Personally, I think that limiting the conversion to single image .PNG files would be adequate as the conversion of animated images substantially increases the complexity of the conversion. The good thing about .PNG is that is is not a 'lossy compression', so all the original image data can be preserved.
@Dr_Acula
ImageMagick is open source. So if you took a look at the CONVERT command's code, you would find at least one example of migration of .PNG to .BMP. The only problem is that this command is set up for many formats which are identified by their file extension. So there is a lot to look through.
What fun is that??? Any phone can do it, sure... but it's not a learning experience getting it there.
Bill
http://en.wikipedia.org/wiki/Portable_Network_Graphics
Everything is simple except for that DEFLATE algo to compress the data. Interestingly enough, there is a 6502 implementation (called INFLATE) that we might be able to use to decode it with something via LMM. There is a lot of C and C++ examples as well, so maybe Catalina would be a good fit here.
Bill
Apparently everything about .PNG is public domain. That is a plus. The fact that the compression is lossless is another plus. And the really appealing fact is that the compression appears to use the same method that ZIP files do.
So it seems that this might break down into two useful projects: [1] creating a ZIP and UNZIP utility on Propeller DOS files and [2] creating a converting .PNG to .BMP application as a pre-processor. .BMP files seem to be directly accessible to the Propeller. It looks as though one reads the .BMP file header to determine configuration, and then bit map is read backwards from the end of the file towards the front in order to get a top-down raster scan.
The Wiki also clarifies how animated .PNG files differ from single images.
Yea static single frame is Ok . and if it takes a minit to think I dont see it as a issue as we really just need to have it ahow the radar ..
as for a phone ....
A) can break easy .
c) most are not VGA or NTSC out .
Peter...
Maybe .gif is easier to crack open... It's just LZW with 8bpp.
I did a little LZW in spin while looking at MP3 decoding...
Maybe the last or first frame in the .gif is the same image as you want?
BTW: I don't I'd use dithering on this type of image. It's great for photos, but not as great for computer graphics...
Besides, the request was to start with .PNG. I think that help with LZW might be a starting point for decompression. Right now, I am trying to get all the ducks in a row - searching and reading. This is slow going for me. But here is a list of tasks.
1. Using a .PNG file, uncompress and create an uncompressed copy for the Propeller to access.
2. Convert the .PNG to .BMP if necessary.
3. Re-dimension the .PNG or .BMP to appropriate size for the Propeller video parameters AND an appropriate range of colors (4 bit or 8 bit, certainly NOT 24bit or 32bit).
5. Use the modified file to display on a VGA display.
And then there is something that is in the back of my mind - Maybe, just maybe.... find a way to compile executable files to be loaded on the SDcard, and then have the ability to ZIP, UNZIP, and CONVERT like real command line DOS commands. Just think how nice it would be to have an SDcard full of utilities for the Propeller that can load and unload to unused cogs.
http://en.wikipedia.org/wiki/DEFLATE
Zip aka DEFLATE is WZ77 and not WZL. So we get off into a tangent if we try to decode the compression for MP3 files and .GIF files.
I am sure that there are people out there that want to do WZL for a music player rather than fool around with graphic files, but I am not one of them. I must admit that I was thinking wrongly when I mentioned animation though in conjunction with .PNG files. The .PNG files don't specifically support such, but .GIF files do.
Any way, there are just to many file formats to try to deal with more that one at a time. Some are easier for a person to get started with due to origins in the public domain. And we all have different ambitions and our projects reflect them.
And here is another peek at what lies ahead - WZ77 decompression shown in C.
http://www.mikekohn.net/file_formats/kunzip.php
Peter
The high level request is to to receive the stated PNG
http://radar.weather.gov/lite/N0R/DMX_0.png
and display it on VGA and/or NTSC TV.
The intent is low power, stand alone, and constantly updated given an ethernet connection.
The high level functional requirements can be something like:
1. Connect to URL
2. Receive file
3. convert file to displayable format as needed.
4. Display image.
The system level functionality for high level requirements 1 and 2 are provided by existing spinneret code in the OBEX, is this correct?
So the unresolved questions are centered around high level requirements 3 & 4.
Question: Is the display format to be 600x550 BMP? How does this affect available memory, can one image be store directly in the prop? The image I downloaded says its 32.5k (33,237 bytes).
Question: How does affect VGA and TV? What is the desired display size? What are the best options, if any? What is the default color depth of the PNG, what affect will having 4 or 8 bit have on size/readability? Will it look like Dr_Acula's conversion in #3?
What other high level questions are unresolved?
As Dr Acula showed, the image can be downloaded (to SD for example) and processed, possibly into four (or other number) of sub images. Can this be done using the prop, is there existing code? How does doing this affect the preceding questions? (Each time a new questions is asked or answered, I like to check if it affects anything that came before. I tend to do a lot of work before coding starts, but have fewer issues.)
Is it possible to have a PC connected to the internet to do the conversion ? The PC could be anywhere in the world. It could actually convert it to a format the propeller could use natively.
Bean
we know that the prop can do VGA and NTSC .
we know it can dispaly with in reason a BMP and
we know the thing can get a file off the web .
we need to convert the file IN the device
I now if I need a non parallax chip to do the conversion and use the prop as a main brain and a really good display driver then that is OK /...
I" feel " the P1 can do it . and the P2 shuld too ..
Peter
http://www.nirsoft.net/utils/seqdownload.html
...With a small wrapper program you should be able to serve up the converted images.
EDIT... sorry I didn't see your post on #17
But, it would probably take several seconds (maybe minutes) to do it...
As Rayman says, dithering probably not needed here as the the radar is 'dithered' already. So just take the RGB values and match to the nearest prop colors (there is a 'least distance' formula to do this which is only a few lines of code).
#include <stdio.h> #include <stdlib.h> #include "png.h" /* libpng header; includes zlib.h */ #include "readpng.h" /* typedefs, common macros, public prototypes */ /* future versions of libpng will provide this macro: */ #ifndef png_jmpbuf # define png_jmpbuf(png_ptr) ((png_ptr)->jmpbuf) #endif static png_structp png_ptr = NULL; static png_infop info_ptr = NULL; png_uint_32 width, height; int bit_depth, color_type; uch *image_data = NULL; void readpng_version_info(void) { fprintf(stderr, " Compiled with libpng %s; using libpng %s.\n", PNG_LIBPNG_VER_STRING, png_libpng_ver); fprintf(stderr, " Compiled with zlib %s; using zlib %s.\n", ZLIB_VERSION, zlib_version); } /* return value = 0 for success, 1 for bad sig, 2 for bad IHDR, 4 for no mem */ int readpng_init(FILE *infile, ulg *pWidth, ulg *pHeight) { uch sig[8]; /* first do a quick check that the file really is a PNG image; could * have used slightly more general png_sig_cmp() function instead */ fread(sig, 1, 8, infile); if (!png_check_sig(sig, 8)) return 1; /* bad signature */ /* could pass pointers to user-defined error handlers instead of NULLs: */ png_ptr = png_create_read_struct(PNG_LIBPNG_VER_STRING, NULL, NULL, NULL); if (!png_ptr) return 4; /* out of memory */ info_ptr = png_create_info_struct(png_ptr); if (!info_ptr) { png_destroy_read_struct(&png_ptr, NULL, NULL); return 4; /* out of memory */ } /* we could create a second info struct here (end_info), but it's only * useful if we want to keep pre- and post-IDAT chunk info separated * (mainly for PNG-aware image editors and converters) */ /* setjmp() must be called in every function that calls a PNG-reading * libpng function */ if (setjmp(png_jmpbuf(png_ptr))) { png_destroy_read_struct(&png_ptr, &info_ptr, NULL); return 2; } png_init_io(png_ptr, infile); png_set_sig_bytes(png_ptr, 8); /* we already read the 8 signature bytes */ png_read_info(png_ptr, info_ptr); /* read all PNG info up to image data */ /* alternatively, could make separate calls to png_get_image_width(), * etc., but want bit_depth and color_type for later [don't care about * compression_type and filter_type => NULLs] */ png_get_IHDR(png_ptr, info_ptr, &width, &height, &bit_depth, &color_type, NULL, NULL, NULL); *pWidth = width; *pHeight = height; /* OK, that's all we need for now; return happy */ return 0; } /* returns 0 if succeeds, 1 if fails due to no bKGD chunk, 2 if libpng error; * scales values to 8-bit if necessary */ int readpng_get_bgcolor(uch *red, uch *green, uch *blue) { png_color_16p pBackground; /* setjmp() must be called in every function that calls a PNG-reading * libpng function */ if (setjmp(png_jmpbuf(png_ptr))) { png_destroy_read_struct(&png_ptr, &info_ptr, NULL); return 2; } if (!png_get_valid(png_ptr, info_ptr, PNG_INFO_bKGD)) return 1; /* it is not obvious from the libpng documentation, but this function * takes a pointer to a pointer, and it always returns valid red, green * and blue values, regardless of color_type: */ png_get_bKGD(png_ptr, info_ptr, &pBackground); /* however, it always returns the raw bKGD data, regardless of any * bit-depth transformations, so check depth and adjust if necessary */ if (bit_depth == 16) { *red = pBackground->red >> 8; *green = pBackground->green >> 8; *blue = pBackground->blue >> 8; } else if (color_type == PNG_COLOR_TYPE_GRAY && bit_depth < 8) { if (bit_depth == 1) *red = *green = *blue = pBackground->gray? 255 : 0; else if (bit_depth == 2) *red = *green = *blue = (255/3) * pBackground->gray; else /* bit_depth == 4 */ *red = *green = *blue = (255/15) * pBackground->gray; } else { *red = (uch)pBackground->red; *green = (uch)pBackground->green; *blue = (uch)pBackground->blue; } return 0; } /* display_exponent == LUT_exponent * CRT_exponent */ uch *readpng_get_image(double display_exponent, int *pChannels, ulg *pRowbytes) { double gamma; png_uint_32 i, rowbytes; png_bytepp row_pointers = NULL; /* setjmp() must be called in every function that calls a PNG-reading * libpng function */ if (setjmp(png_jmpbuf(png_ptr))) { png_destroy_read_struct(&png_ptr, &info_ptr, NULL); return NULL; } /* expand palette images to RGB, low-bit-depth grayscale images to 8 bits, * transparency chunks to full alpha channel; strip 16-bit-per-sample * images to 8 bits per sample; and convert grayscale to RGB[A] */ if (color_type == PNG_COLOR_TYPE_PALETTE) png_set_expand(png_ptr); if (color_type == PNG_COLOR_TYPE_GRAY && bit_depth < 8) png_set_expand(png_ptr); if (png_get_valid(png_ptr, info_ptr, PNG_INFO_tRNS)) png_set_expand(png_ptr); if (bit_depth == 16) png_set_strip_16(png_ptr); if (color_type == PNG_COLOR_TYPE_GRAY || color_type == PNG_COLOR_TYPE_GRAY_ALPHA) png_set_gray_to_rgb(png_ptr); /* unlike the example in the libpng documentation, we have *no* idea where * this file may have come from--so if it doesn't have a file gamma, don't * do any correction ("do no harm") */ if (png_get_gAMA(png_ptr, info_ptr, &gamma)) png_set_gamma(png_ptr, display_exponent, gamma); /* all transformations have been registered; now update info_ptr data, * get rowbytes and channels, and allocate image memory */ png_read_update_info(png_ptr, info_ptr); *pRowbytes = rowbytes = png_get_rowbytes(png_ptr, info_ptr); *pChannels = (int)png_get_channels(png_ptr, info_ptr); if ((image_data = (uch *)malloc(rowbytes*height)) == NULL) { png_destroy_read_struct(&png_ptr, &info_ptr, NULL); return NULL; } if ((row_pointers = (png_bytepp)malloc(height*sizeof(png_bytep))) == NULL) { png_destroy_read_struct(&png_ptr, &info_ptr, NULL); free(image_data); image_data = NULL; return NULL; } Trace((stderr, "readpng_get_image: channels = %d, rowbytes = %ld, height = %ld\n", *pChannels, rowbytes, height)); /* set the individual row_pointers to point at the correct offsets */ for (i = 0; i < height; ++i) row_pointers[i] = image_data + i*rowbytes; /* now we can go ahead and just read the whole image */ png_read_image(png_ptr, row_pointers); /* and we're done! (png_read_end() can be omitted if no processing of * post-IDAT text/time/etc. is desired) */ free(row_pointers); row_pointers = NULL; png_read_end(png_ptr, NULL); return image_data; } void readpng_cleanup(int free_image_data) { if (free_image_data && image_data) { free(image_data); image_data = NULL; } if (png_ptr && info_ptr) { png_destroy_read_struct(&png_ptr, &info_ptr, NULL); png_ptr = NULL; info_ptr = NULL; } }Since the algorithm originates in bytes, 32 bit processing may not be much of an advantage for reducing the assembly code to a smaller foot print.
In sum, what is available is very close to possible on one cog. But it is going to take some effort sort out a good successful piece of code.
Also, the author of the site has his code actually being used to decompress .PNG files in the Linux graphic application called GIMP which is quite well accepted by Linux users.
I must admit that this is getting beyond my own abilities, but I certainly will try to follow along and learn something.
If this works It would make a very fun OBJ .
perhaps a OBJ list to get started and we can at least test the display to get a good color range and yet still have a good sized raster ...
MY PPDB is warrmed up and readdy to compute ..
Peter
The code depends on the zlib deflate code and the png library itself, so it hides most of the work. (The code also suffers from K&R syndrome.. it casts 'malloc', which is a big no-no. But that's another story and something I can go and bother the pngbook authors about.. just be aware of it if you re-use the code. Get rid of all those casts, they can hide programming errors.)
As for zlib deflate, the current implementation in zlib is pretty complex. That's all part of making it as fast as possible, and as portable between compilers as possible.
[Edit: Removed part about old implementation - I could not find out how to add the overstrike tags in this forum. What I wrote was that deflate/inflate came from the end-of-eighties PKZIP program, but that original implementation was the 'implode' algorithm which was slightly simpler. The next statement still holds true.. I think.]
But someone can probably implement something in PASM, starting with the deflate algorithm specification. Gut feeling is that it should be possible in a cog.
-Tor
-Tor
hmm - that is one of my pet hates - hiding half the code inside some sort of secret library. I thought the code looked a bit too short.
/end rant
I checked my local radar http://www.bom.gov.au/products/national_radar_sat.loop.shtml and buried in the source code is also some .png files so it is probably a 'radar standard' of some sort.
I know heater said you can get this on your phone, but if you can get inside the code you can do more cool things. eg you could count the coloured pixels around where you live and sound a buzzer to warn that rain is on the way and time to bring the washing in.
As for speed, my local radars are updated every 10 mins, so if it took a minute or two of Spin or C to decode a .png that would still be fine.
This is a fun little project. We just need to find some proper .png source code...
Try gziplite or kunzip for alternatives in C code.
http://sourceforge.net/projects/gziplite/
http://www.mikekohn.net/file_formats/kunzip.php
Compressing needs more, but we don't have to worry about that for this project.
-Tor
I can see a couple of solutions. One is a prop chip with external memory running XMM C with an SD card for storage. The other prop does graphics and it also might have an external ram, depending on whether you want 256x224 or if 256x96 is ok.
But there might be a way to combine both those props together. My local radar is only updated every 10 mins, so you could have a prop running C to do the processing, then store the data to external ram, then reboot that prop and load in the graphics code and display the graphics for 10 mins, then reboot and get the next .png file.
What would be very useful would be to have some C89 code, and it does not matter how big the program is, nor how big buffers might be. Input to the program will be a .png file from the sd card. Output might also go to the sd card (or later, to ram), and will be a binary file of bytes that the prop display understands (I call them .vga and .tv files).
One advantage of code that is written in C89 and whose sole function is to take one file and create another file, is that it should be possible to debug and test this on a PC rather than on the propeller. That might make debugging quicker.
If anyone can get the .png data into an array in C that has RGB values 0-255, then I have code that can take that and convert to .vga and .tv (.vga is easy - just take each RGB value and right shift by 6 places, ie divide by 64. Converting to .tv is a few more lines of code but still pretty easy).