Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Image Decoder

Status
Not open for further replies.

Attachments

  • line_scanner.JPG
    line_scanner.JPG
    34.1 KB · Views: 303
Last edited:
I need some 3/4 pvc pipe you want to trade LOL only about 3 inch piece
 
Last edited:
i was reading about FPGA stuff and got so lost heh... i think i can make one with a PIC or ARM if i knew how to decode JPEGs and stuff heh.. i can do BMP so it wouldnt be that hard with that but JPEG is so confusing... Quantum crap!!
 
i was reading about FPGA stuff and got so lost heh... i think i can make one with a PIC or ARM if i knew how to decode JPEGs and stuff heh.. i can do BMP so it wouldnt be that hard with that but JPEG is so confusing... Quantum crap!!

BMP is easy because it's uncompressed, lossy compression like JPEG is incredibly more difficult, and requires much more processing power and memory space. Even GIF isn't very simple, because it's highly compressed, even though it's not lossy (it worls in a similar way to ZIP).

I've got a book at home somewhere about picture formats, using C unfortunately, I converted any bits I wanted to Pascal decades ago.
 
Back when I was a graphics programmer for dos applications I used to use RLE formats, they can be pretty good for 2 colour things like icons and logos that have repeated bit strings of the same colour pixel.

The good side is they are extremely easy to compress and decompress, you just replace a sequence of pixels (say 1-31 pixels) with a command like Cxxxxx where C is the bit colour and xxxxx is from 1 to 31 pixels. The pixel strings wrap from right to left sides of the icon.

It can be expanded for 16 colour and 256 colour icons, and you can even turn the RLE on/off and use it for borders etc and use 1 byte/pixel for the details. I think the original .PCX format allowed for some pixel data and some RLE data combined.
 
That's cool RLE here some C++ code

From some of my friends over at https://www.daniweb.com/code/snippet216388.html

Code:
/* Basic RLE Compression 
 *
 * Read the file, write compressed as frequency of each byte in sucession
 * I.E
 *
 * 2, 4, 4, 1, 1, 1, 1, 5, 5, 5 compresses to:
 * 1, 2, 2, 4, 4, 1, 3, 5 (1 two, 2 fours, 4 ones, 3 fives)
 *
 * Returns the saved fraction (* 100 = % compression)
*/

float compress(const char *fname, const char *cname)
{
    fstream file;            // original file
    fstream compressed;      // compressed file
    char character;          // read character
    char next_character;     // last character read
    int fsize = 0;           // file size
    int frequency = 1;       // unique byte values
    int write_pos = 0;
    
    file.open(fname, ios::in | ios::ate | ios::binary);
    compressed.open(cname, ios::out | ios::trunc | ios::binary);
    fsize = file.tellg();
    
    for(int i = 0; i < fsize; i++)
    {
        file.seekg(i, ios::beg);      // safety net
        file.read((char*)&character, sizeof(char)); // get current character
        next_character = file.peek();

        if(next_character != character)
        {
            compressed.seekp(write_pos, ios::beg);
            compressed.write((char*)&frequency, sizeof(char));
            compressed.seekp(write_pos + 1, ios::beg);
            compressed.write((char*)&character, sizeof(char));
            write_pos += 2;
            frequency = 0;
        }    
        frequency++;
    }    

    file.close();
    compressed.close();
    
    return (write_pos / float(fsize));
}    

void decompress(const char *fname, const char *uname)
{
    fstream file;
    fstream ufile;
    char character;
    int frequency = 0;
    int fsize = 0;
    int write_pos = 0;
    
    file.open(fname, ios::ate | ios::in | ios::binary);
    ufile.open(uname, ios::trunc | ios::out | ios::binary);
    fsize = file.tellg();
    
    for(int i = 0; i < fsize; i += 2)
    {
        file.seekg(i, ios::beg);
        file.read((char*)&frequency, sizeof(char));
        file.seekg(i + 1, ios::beg);
        file.read((char*)&character, sizeof(char));

        for(int j = 0; j < frequency; j++)
        {
            ufile.seekp(write_pos, ios::beg);
            ufile.write((char*)&character, sizeof(char));
            write_pos++;
        }    
    }    
    file.close();
    ufile.close();
}

/* any credit to myself if you find this useful would be extremely welcolme 
 * as I do spend a LOT of time ensuring that code works and is useful ect... 
 * before I consider posting/releasing it! :) Hope you find this useful
 * took a bit of time to figure out. Any comments / suggestions feel
 * free to add in below! 1o0oBhP
*/

// ps this method works well on low detail bitmaps and repeated chars!
 
Last edited:
Back when I was a graphics programmer for dos applications I used to use RLE formats, they can be pretty good for 2 colour things like icons and logos that have repeated bit strings of the same colour pixel.

The good side is they are extremely easy to compress and decompress, you just replace a sequence of pixels (say 1-31 pixels) with a command like Cxxxxx where C is the bit colour and xxxxx is from 1 to 31 pixels. The pixel strings wrap from right to left sides of the icon.

It can be expanded for 16 colour and 256 colour icons, and you can even turn the RLE on/off and use it for borders etc and use 1 byte/pixel for the details. I think the original .PCX format allowed for some pixel data and some RLE data combined.

The Amiga used RLE encoding, I can't remember what the format was called now? (but it was simple to read and write) - I wrote various DOS utilities to convert between Amiga and PC graphics.
 
When I had my Amiga 4000/Video toaster 4000 it mainly used portable network graphics, png. A format windows also uses now for lossless compression.
 
When I had my Amiga 4000/Video toaster 4000 it mainly used portable network graphics, png. A format windows also uses now for lossless compression.

The Amiga used IFF for graphics, the 4000 was a far later machine - PNG didn't even exist when the original Amiga was out.

Just googled, the PNG spec was only released in Oct 1996 - IFF was 1985.
 
Really RLE was to save space on the disk you where compressing DIB files with RLE compression routines.
 
heh i might just go back to the old way ... make a program for windows that decompresses the image and makes it into a format i can read faster. This will allow me to load images super fast.
 
heh i might just go back to the old way ... make a program for windows that decompresses the image and makes it into a format i can read faster. This will allow me to load images super fast.

The amount of power of modern Windows PC's means you won't see any difference - it should decompress faster than the display (and your eyes) update.
 
hi Nigel im mean for embedded stuff.. so i can place a new decompressed file on my SD card and open it without having to shift bits and skip bytes because of the BMP format.

Basically Ill make a program that will open the image decompress it and save it as raw data. Then simply use the ARM or PIC to read the raw data as fast as possible...
 
What's the image data? Are they icons or photographs? If they are icon like graphics you might just be able to convert to 16 colour, which only needs 4 bits per pixel. That halves data storage (compared to 256 colour) and has little to no decoding penalty at the display end.
 
Compression isnt needed at all... i mean the max image size is 128*160... at 16bit per pixel its (128x160)x2 = 40960 Bytes thats 40kb a image... im using a 1GB card so 1GB = 1,073,741,824 bytes heh so thats

1073741824 / 40960 = 26,214 full sized images (of course maybe a couple less but come on heh thats alot)

Now if its half icons and half images:

536870912 / 40960 (FULL) = 13,107 FULL IMAGES
536870912 / (icon 60x60) = 74,565 ICONs (60x60)

Well more than i should need. If anything i can get a 2,4,8,16gb...etc card so im set! I was just bored and though there was a IC for decoding images like you send it the RAW bytes from opening the file and it determines if its a JPG,BMP etc and decodes it and send you back something like 24BPP data
 
Status
Not open for further replies.

Latest threads

Back
Top