DecodePixelData duplicated code and possible bug??

[jeffatrad]

DecodePixelData has a ton of duplicated complicated code that should just be refactored into one helper function by grabbing the chunk of code in the zip clause and putting it into a function. Then you can use the same post code for RLE, ZIP, PIZ and probably none. It could then be optimized and such, where right now, it's just terrifying.

Anyway, I was doing this in our branch, and I noticed an oddity. In the Piz clause vs the Zip clause, we have this:

  } else if (channels[c].pixel_type == TINYEXR_PIXELTYPE_FLOAT) {
    assert(requested_pixel_types[c] == TINYEXR_PIXELTYPE_FLOAT);
    for (size_t v = 0; v < static_cast<size_t>(num_lines); v++) {
      const float *line_ptr = reinterpret_cast<float *>(
          &outBuf.at( v * pixel_data_size * static_cast<size_t>(x_stride) +
          channel_offset_list[c] * static_cast<size_t>(x_stride)));

Where the Zip and RLE clauses use:

  } else if (channels[c].pixel_type == TINYEXR_PIXELTYPE_FLOAT) {
    assert(requested_pixel_types[c] == TINYEXR_PIXELTYPE_FLOAT);
    for (size_t v = 0; v < static_cast<size_t>(num_lines); v++) {
      const float *line_ptr = reinterpret_cast<float *>(
          &outBuf.at(v * pixel_data_size * static_cast<size_t>(width) +
                     channel_offset_list[c] * static_cast<size_t>(width)));

Why is the Piz code using "x_stride" and the Zip and RLE code using "width"? Also, only the "Float to float" path of the Piz code uses x_stride, while the other clauses use "width". Shouldn't everything be width or everything be x_stride?

Thanks!

[jeffatrad]

Here's a little diff from our version that cleans most of this up...

decodepixeldata.zip

[Syoyo Fujita]

Here's a little diff from our version that cleans most of this up...

You should post PR, not attaching zip

[jeffatrad]

Will do, later today.

[Syoyo Fujita]

No PR submitted, and possible bug may be fixed in recent master branch.