ARW: Support new LJPEG compression on ILCE-7M4 and ILCE-7R5 #483
Conversation
* Support large-resolution ARW from ILCE-7RM5 * Generalize sonyArrange in LJPEG arrangement to support 1x2 Co-authored-by: Artemis Tosini <me@artem.ist>
Recap: due to crop size roundup to multiples of tile size (512) Sony lossless files exhibit black areas if not further cropped down to actual pixel area, which is covered by the sensor. Exif.SubImage1.0x7038 seems to reliably provide the true crop size, whereas Exif.SubImage1.DefaultCropSize only crops to OOC jpeg size losing some pixel area
* upstream/pr/482: Do not apply crop from cameras.xml and set crop origin to 0,0 Boyscout: make sony exif tag naming consistent Use Exif.SubImage1.0x7038 field for Sony lossless compression crop ARW: Support new LJPEG compression on ILCE-7M4 and ILCE-7R5
…ld for square MCU's
`#pragma omp for` is non-sensical on itself.
Looks like UBSan sanitizes even the OpenMP-produced synthetic computations, and thus `rwDecoder.cpp:337:5: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned int'`.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## develop #483 +/- ##
============================================
+ Coverage 38.54% 59.22% +20.68%
============================================
Files 643 232 -411
Lines 36905 13879 -23026
Branches 5073 1939 -3134
============================================
- Hits 14224 8220 -6004
+ Misses 22106 5524 -16582
+ Partials 575 135 -440
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
…ght' LJpegs We support 'weird width' Ljpegs, where last MCU of row produces more pixels than needed. Now that we support square MCU's, the same can happen in another dimension. At least for now, explicitly note that it is not supported.
It does not appear to make any performance difference on the normal codepath.
There's `MCUSize` member variable in `LJpegDecompressor` class, so it's a shadowing/confusing, but only Xcode is complaining...
| const iPoint2D MCUSize = !interleaveRows | ||
| ? iPoint2D(frame.cps, 1) | ||
| : iPoint2D(frame.cps / 2, frame.cps / 2); | ||
|
|
There was a problem hiding this comment.
Is there still a plan to eliminate interleaveRows and keep generalizing this?
The reason I ask is, I don't see how this new MCUSize scheme can support the Blackmagic case, which would need something like iPoint2D(frame.cps / 2, frame.cps * 2) with frame.cps / 2 having to be 0.5!?
There was a problem hiding this comment.
Is there still a plan to eliminate
interleaveRowsand keep generalizing this?
LJpegDecoder should not take interleaveRows, so i guess this needs to be generalized further, yes.
The reason I ask is, I don't see how this new MCUSize scheme can support the Blackmagic case, which would need something like
iPoint2D(frame.cps / 2, frame.cps * 2)withframe.cps / 2having to be 0.5!?
No idea. That is a future me problem.
There was a problem hiding this comment.
That is a future me problem.
Might warrant a thought though, so you don't have to potentially tear down what you're building up now? Not that there is anything wrong with that if that process works for you ;)
|
Ok, i can't be bothered. |
3 participants
Based on #482 & #386