Bodmer / JPEGDecoder

A JPEG decoder library
Other
227 stars 65 forks source link

Esp8266 #3

Closed fredericplante closed 7 years ago

fredericplante commented 7 years ago

Hey Bodmer, may chance you make your library compatible with the ESP8266 version of the Arduino platform?

fredericplante commented 7 years ago

ESP8266 SPIFFS version

;)

Had to be Serial TFT to fit with the ESP8266 pin amount limitation.

Have fun!

Bodmer commented 7 years ago

Great, making it use SPIFFS was something I wanted to do. Thanks.

fredericplante commented 7 years ago

I was wondering, would it be possible to process only part of the JPEG, so we could like in this case, scroll around the picture to watch the whole picture but only partially at one time. I would improuve the library by a lot I think,

Bodmer commented 7 years ago

That may be possible but it is not something I need at the moment. The problem with JPEG files is that due to the compression used they must be decoded from the beginning and thus a large buffer would be needed (320x240x2 bytes = 153kbytes) or it would be slow.

PS. There is a bug in your fork for the bx_limit, the min calculation has a copy and paste style error, it should read:

if (8 < image_info.m_width - (mcu_x * image_info.m_MCUWidth + x)) bx_limit = 8; else bx_limit = image_info.m_width - (mcu_x * image_info.m_MCUWidth + x);    
fredericplante commented 7 years ago

One more question. Let's pretend that instead of a TFT screen we would send it to the Arduino Due VGA, from @stimmer. What would be the best way to "downgrade" the color value from 16bits color to 8bits color?

By the way, thank you so much for the bug report :D It's fixed.

Also, has noted in the development page, your algorithm fill a 320*240 SPI TFT in about 460ms using an ESP8266 clocked at 160mhz, so in theory It could pick 2 pictures per second from a Serial JPEG camera using the network connection, instead of a picture on SD or flash.

It's more then enough ;)

Some way of getting part of the picture are now appearing since i saw your way you cut out the part that would be out of the TFT display space , Yeah, it's getting clear, how to do it I mean, I must get the algorithm to read the whole thing but leave out the unwanted part, and sending the part you want to the TFT. No need for large memory map.

If I can do that, I will be able to integrate a bunch of icons coming from 1 JPEG file. The real fun of an ESP8266 is that is is a tiny computer hooked on the net. with few components you make something really impressing.

Bodmer commented 7 years ago

To answer you question. The JPEGs are stored as 24 bit colour, this is converted to 16 bit in the library by taking the most significant 5 bits for Red and Blue and 6 bits for Green, these are then assembled into 16 bits (5+6+5 bits of RGB colours). The same approach can be used to assemble a 8 bit 3+3+2 (RGB) colour.

I like the NodeMCU boards a lot and have them dotted around the house sending sensor values to ThingSpeak. I also have an Amazon Echo and found that an ESP8266 can be made to look like a Wemo switch on my network and thus can be controlled via on/off voice commands from the Echo.

I have a library on GitHub called TFT_ILI9341_ESP that has been optimised for the ESP8266 and ILI9341 SPI displays. The optimisation makes it run about 2x faster.

Bodmer commented 7 years ago

There is still a bug in that line near the end mcu_y should read mcu_x as folows in this correct line:

if (8 < image_info.m_width - (mcu_x image_info.m_MCUWidth + x)) bx_limit = 8; else bx_limit = image_info.m_width - (mcu_x image_info.m_MCUWidth + x);

fredericplante commented 7 years ago

Thanks I fixed, :D But i'm pretty sure I can make a more efficient use of the switches. The library might change in the future

Bodmer commented 7 years ago

Yes, the library is going to change, particularly in the area of the "switches", that was a bit of an ugly hack to get it working with arrays. I have a library copy in test that lets users use SD cards or arrays (and now SPIFFS too) to store Jpegs all together if needed in the same sketch. I keep smaller image icons in the raw 565 format as drawing them is much faster than trying to decode a jpeg even if they are pulled from SPIFFS.

Your branch has introduced a bug into the array handling. There is also another bug that leaves a value on the stack that may eventually cause the processor to crash and the fix is not in your branch as it branched off before it was fixed in the master copy!

I have pulled all your changes into the Master library manually and now the array handling works. This is now working well with the ESP8266. I have added credit to you for those changes.

You might like to branch off again and add your SPIFFS example as I see your branch has gone, that way you get the current and future bug fixes! I've got quite a few updates that are held back pending adequate testing and you will be able to benefit from those.

There is a draft "Instructable" that details using the JPEGDecoder library which is held back awaiting publishing. I will let you know when it is ready. When all that is done the aim is to try to get it added to the IDE library manager!

Bodmer commented 7 years ago

Trying to add your changes without having a working fork seems to have introduced a bug in the decoder.

So sadly I have had to strip out all your suggested changes and start again from the Mega/Due only code. But thanks for all your efforts.

I have used a different method of adding ESP8266 support which only needed minor changes, plus a few new almost duplicate functions to cater for specific needs.

The ESP8266 can now draw from SD card, SPIFFS and large arrays in program memory fine all within the same sketch!

The min() function now works too, it was simply a clash with another ESP8266 specific function name hidden in the core.