Images - Revision history

Tectu: /* Color Palettes */

2021-08-02T15:38:56Z

‎Color Palettes

Tectu: /* Examples */

2021-08-02T15:38:35Z

‎Examples

Tectu: /* RAM usage */

2016-11-11T20:44:29Z

‎RAM usage

Tectu at 18:40, 11 November 2016

2016-11-11T18:40:15Z

Tectu at 18:39, 11 November 2016

2016-11-11T18:39:18Z

Tectu: /* RAM usage */

2016-11-11T18:37:12Z

‎RAM usage

Tectu: /* GIF vs. PNG */

2016-11-11T18:35:55Z

‎GIF vs. PNG

Tectu: /* RAM usage */

2016-11-11T18:34:48Z

‎RAM usage

Tectu: /* RAM usage */

2016-11-11T18:33:54Z

‎RAM usage

Tectu: /* Alpha & Transparency */

2016-11-11T18:32:16Z

‎Alpha & Transparency

@@ Line 32: / Line 32: @@
 <source lang="c">
 uint16_t   gdispImageGetPaletteSize(gdispImage *img);
-color_t    gdispImageGetPalette(gdispImage *img, uint16_t index);
+gColor     gdispImageGetPalette(gdispImage *img, uint16_t index);
-bool_t     gdispImageAdjustPalette(gdispImage *img, uint16_t index, color_t newColor);
+gBool      gdispImageAdjustPalette(gdispImage *img, uint16_t index, color_t newColor);
 </source>
 Please check the [[Images#API_reference|API reference]] to learn more about these functions.

@@ Line 132: / Line 132: @@
 int main(void) {
-	coord_t	swidth, sheight;
+	gCoord swidth, sheight;
 	// Initialize uGFX and the underlying system

@@ Line 100: / Line 100: @@
 Unfortunately there is nothing that can be done to further reduce the amount of RAM usage. There are a couple of big memory hogs in PNG decoding...
 * A sliding window of 32K is needed for the inflate decompression. While some images may use less, because the inflate window size is non-deterministic while decoding the maximum sliding window has to be allocated up front.
-* 2 scan lines of uncompressed data are required to perform PNG filtering. For a 16-bit RGB with alpha that amounts to (1 + 8 bytes per pixel x width) x 2. Obviously for an 8-bit palette based PNG it is (1 + 1 x width) x 2, and for a 1-bit palette PNG it is image (1 + width / 8) x 2
+* 2 scan lines of uncompressed data are required to perform PNG filtering. For a 16-bit RGB with alpha that amounts to (1 + 8 bytes per pixel * width) * 2. Obviously for an 8-bit palette based PNG it is (1 + 1 * width) * 2, and for a 1-bit palette PNG it is image (1 + width / 8) * 2
 Unfortunately these overheads cannot be reduced as they are required by the PNG specification.

@@ Line 26: / Line 26: @@
 == A word about close() ==
-The '''gdispImageClose()''' function performs a complete cleanup. Calling this routine will not only clean up all memory used by the decoder and the chaching, it will also close the file system. Therefore, this should really just be called when you're done with the image and you won't re-draw it for a longer time period.
+The <code>gdispImageClose()</code> function performs a complete cleanup. Calling this routine will not only clean up all memory used by the decoder and the caching, it will also close the file system. Therefore, this should really just be called when you're done with the image and you won't re-draw it for a longer time period.
 == Image formats ==
@@ Line 107: / Line 116: @@
 There is however one exception to the above, when a GIF image is cached to RAM using <code>gdispImageCache()</code> we cache the decompressed byte stream. For PNG we cache the compressed byte stream. In this situation it is likely that cached GIF images will display faster than cached PNG images but will take more RAM to cache.
 == Examples ==

@@ Line 5: / Line 5: @@
 == API reference ==
 The API reference for the image support can be found [http://api.ugfx.org/group___image.html here].
 == Image formats ==
@@ Line 94: / Line 116: @@
 </source>
 Please check the [[Images#API_reference|API reference]] to learn more about these functions.
 == Examples ==

@@ Line 60: / Line 60: @@
 ==== RAM usage ====
 PNG images have the following RAM requirements:
 * 64 bytes (or less) for the <code>gdispImage</code> structure and internal PNG image information

@@ Line 80: / Line 80: @@
 ==== GIF vs. PNG ====
-We have not performed any speed tests comparing GIF's with PNG's. Both use similar technology to decode the image but the differences will determine the relative speeds. They use different compression algorithm's. GIF is also 8 bit palette pixel format only whereas PNG supports a multitude of internal pixel formats. Both support transparency but only PNG supports alpha blending. With GIF we support interlacing but not with PNG due to complexity. GIF supports animation, PNG does not. In conclusion, the differences in decoding speed between PNG and GIF is going to depend very much on the actual image.
+We have not performed any speed tests comparing GIF's with PNG's. Both use similar technology to decode the image but the differences will determine the relative speeds. They use different compression algorithm's. GIF is also 8-bit palette pixel format only whereas PNG supports a multitude of internal pixel formats. Both support transparency but only PNG supports alpha blending. With GIF we support interlacing but not with PNG due to complexity. GIF supports animation, PNG does not. In conclusion, the differences in decoding speed between PNG and GIF is going to depend very much on the actual image.
 There is however one exception to the above, when a GIF image is cached to RAM using <code>gdispImageCache()</code> we cache the decompressed byte stream. For PNG we cache the compressed byte stream. In this situation it is likely that cached GIF images will display faster than cached PNG images but will take more RAM to cache.

@@ Line 71: / Line 71: @@
 Most PNG decoders (and decoder libraries) require:
-* A full copy of the input file in memory
+# A full copy of the input file in memory
-* The PNG header information and palette storage overheads
+# The PNG header information and palette storage overheads
-* The 32K sliding window and scanline buffers (although this is often integrated into #4 below)
+# The 32K sliding window and scanline buffers (although this is often integrated into #4 below)
-* A full copy of the decompressed byte stream in memory
+# A full copy of the decompressed byte stream in memory
-* A full copy of the output image in PNG color format after scanline filtering
+# A full copy of the output image in PNG color format after scanline filtering
-* A full copy of the output image in output device color format.
+# A full copy of the output image in output device color format.
 Obviously this is a huge amount of RAM, well beyond the capabilities of most embedded devices. We therefore wrote our decoder from scratch to remove those overheads where-ever possible. For our decoder we only need #2 and #3 and furthermore #3 is only needed while the decoding is actually happening.

@@ Line 57: / Line 57: @@
 ==== Alpha & Transparency ====
-The decoder supports both transparency and alpha. When a background color is specified in the PNG file alpha and transparency are handled by color blending with the background color. If a background color has not been specified by the PNG file then any pixel alpha below GDISP_NEED_PNG_ALPHACLIFF is just not displayed.
+The decoder supports both transparency and alpha. When a background color is specified in the PNG file alpha and transparency are handled by color blending with the background color. If a background color has not been specified by the PNG file then any pixel alpha below <code>GDISP_NEED_PNG_ALPHACLIFF</code> is just not displayed.
 ==== RAM usage ====