<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://git.reviewboard.kde.org/r/116567/">https://git.reviewboard.kde.org/r/116567/</a>
     </td>
    </tr>
   </table>
   <br />





 <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">My understanding is that all image formats we support are supposed to be lossless (including JPEG 2000, when quality is set to 100). In other words, if there is a deviation in RGB data, I would consider it as a bug, which the tests should at least warn about.

If this is about XCF images: These can contain multiple layers which are alpha-composed during load-time. For those operations, an exception could be made, because blending could even be hardware-accelerated.</pre>
 <br />









<p>- Christoph Feck</p>


<br />
<p>On March 3rd, 2014, 1:04 p.m. UTC, Alex Merry wrote:</p>








<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for KDE Frameworks.</div>
<div>By Alex Merry.</div>


<p style="color: grey;"><i>Updated March 3, 2014, 1:04 p.m.</i></p>









<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt;">Repository: </b>
kimageformats
</div>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Implement fuzzy image matching in readtest

Images are converted to ARGB32 format, then each byte (ie: each pixel
channel) in the read image is allowed to deviate by 1 from the
corresponding byte in the expected image, to allow for rounding errors
etc.

Extract QImage::Format parsing into its own header

Use the array-of-strings suggested by David Faure so that only one list
has to be maintained instead of three.</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">imagedump still works.  Most tests still pass; note that the non-alpha pic tests fail without https://git.reviewboard.kde.org/r/116568/diff/ as the wrong format (ARGB32 instead of RGB32) is constructed.

This should make the xcf tests pass again on Jenkins.</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>autotests/readtest.cpp <span style="color: grey">(dec9686e38389b04296fdf176db9fb8c1f3a56a4)</span></li>

 <li>tests/format-enum.h <span style="color: grey">(PRE-CREATION)</span></li>

 <li>tests/imagedump.cpp <span style="color: grey">(4b38c07d151d9bcb895f49a76e2bd03ddee41487)</span></li>

</ul>

<p><a href="https://git.reviewboard.kde.org/r/116567/diff/" style="margin-left: 3em;">View Diff</a></p>







  </td>
 </tr>
</table>








  </div>
 </body>
</html>