diff --git a/ANNOUNCE b/ANNOUNCE
index 1967b1626..b3b3987a6 100644
--- a/ANNOUNCE
+++ b/ANNOUNCE
@@ -1,5 +1,5 @@
 
-Libpng 1.5.3beta10 - May 17, 2011
+Libpng 1.5.3beta10 - May 19, 2011
 
 This is not intended to be a public release.  It will be replaced
 within a few weeks by a public version or by another test version.
@@ -134,7 +134,16 @@ Version 1.5.3beta09 [May 17, 2011]
    do any gamma correction.  Moving the tests back leaves the old, inaccurate,
    8-bit gamma calculations, but these are clearly better than none!
 
-Version 1.5.3beta10 [May 17, 2011]
+Version 1.5.3beta10 [May 19, 2011]
+  png_set_background() and png_expand_16() did not work together correctly.
+    This problem is present in 1.5.2; if png_set_background is called with
+    need_expand false and the matching 16 bit color libpng erroneously just
+    treats it as an 8-bit color because of where png_do_expand_16 is in the
+    transform list.  This simple fix reduces the supplied colour to 8-bits,
+    so it gets smashed, but this is better than the current behavior.
+  Added tests for expand16, more fixes for palette image tests to pngvalid.
+    Corrects the code for palette image tests and disables attempts to
+    validate palette colors.
 
 Send comments/corrections/commendations to png-mng-implement at lists.sf.net:
 (subscription required; visit
diff --git a/CHANGES b/CHANGES
index e260c31be..0e206ef3b 100644
--- a/CHANGES
+++ b/CHANGES
@@ -3389,13 +3389,24 @@ Version 1.5.3beta08 [May 16, 2011]
   Minor cleanup and some extra checking in pngrutil.c and pngrtran.c
 
 Version 1.5.3beta09 [May 17, 2011]
- Reversed earlier 1.5.3 change of transformation order; move png_expand_16 back.
-   The change doesn't work because it requires 16-bit gamma tables when the code
-   only generates 8-bit ones.  This fails silently; the libpng code just doesn't
-   do any gamma correction.  Moving the tests back leaves the old, inaccurate,
-   8-bit gamma calculations, but these are clearly better than none!
+  Reversed earlier 1.5.3 change of transformation order; move png_expand_16
+    back where it was.  The change doesn't work because it requires 16-bit
+    gamma tables when the code only generates 8-bit ones.  This fails
+    silently; the libpng code just doesn't do any gamma correction.  Moving
+    the tests back leaves the old, inaccurate, 8-bit gamma calculations, but
+    these are clearly better than none!
 
-Version 1.5.3beta10 [May 17, 2011]
+Version 1.5.3beta10 [May 19, 2011]
+
+  png_set_background() and png_expand_16() did not work together correctly.
+    This problem is present in 1.5.2; if png_set_background is called with
+    need_expand false and the matching 16 bit color libpng erroneously just
+    treats it as an 8-bit color because of where png_do_expand_16 is in the
+    transform list.  This simple fix reduces the supplied colour to 8-bits,
+    so it gets smashed, but this is better than the current behavior.
+  Added tests for expand16, more fixes for palette image tests to pngvalid.
+    Corrects the code for palette image tests and disables attempts to
+    validate palette colors.
 
 Send comments/corrections/commendations to png-mng-implement at lists.sf.net
 (subscription required; visit
diff --git a/pngrtran.c b/pngrtran.c
index fa464494c..4dec1f91c 100644
--- a/pngrtran.c
+++ b/pngrtran.c
@@ -1434,7 +1434,7 @@ png_init_read_transformations(png_structp png_ptr)
    {
       /* TODO: fix this.  Because the expand_16 operation is after the compose
        * handling the background color must be 8, not 16, bits deep, but the
-       * application will supply a 16 bit value so reduce it here.
+       * application will supply a 16-bit value so reduce it here.
        *
        * The PNG_BACKGROUND_EXPAND code above does not expand to 16 bits at
        * present, so that case is ok (until do_expand_16 is moved.)