-
Notifications
You must be signed in to change notification settings - Fork 20
Implement a safer TiffEntry/CiffEntry way of accessing data #142
Comments
@klauspost any opinion on this? getShortArray() and getIntArray() make bounds checking non-obvious so I'd rather just move everything into getInt() and getShort() as described. Any objection to that? |
@pedrocr : looking at the |
As far i'm concerned this got implemented and merged a while ago. |
I was referring to the second point and the 'sketch', especially the FileMap API changes regarding byte swapping. |
@axxel I haven't worked on this in a while but it's still a simplification opportunity in the code. Of the sketch I describe above only the first point is implemented. I've been toying with a rust implementation for a raw loading library and have implemented it like that: https://github.com/pedrocr/rawloader/blob/master/src/decoders/tiff.rs There is no TiffEntry/TiffEntryBE split, there's only a single TiffEntry that gets instantiated with an endianness and then an Endian implementation that abstracts away the swapping of bytes: https://github.com/pedrocr/rawloader/blob/master/src/decoders/basics.rs Works quite well. As for the BitPumps I've so far only implemented two and did them with code duplication so far but the rawspeed way of just having a base class and then implementing filling sounds good to me. BitPumps are very sensitive performance wise so optimizing for less code isn't ideal. I did that initially for the MSB/LSB pumps and the performance penalty was significant. |
@pedrocr Are you intending to pursue those sketched out plans further? As to the potential performance implications: I am well aware of them and would in no way sacrifice performance (my motivation looking into this in the first place, was my worry about a performance drop caused by the |
@axxel not really, if you're interested go ahead |
After the work in PR #141 I've come up with a sketch for a further API change to achieve two things at once:
So here's the basic sketch:
Since the TiffEntry API is used for metadata only the performance implications should be minimal if any. How does the plan sound?
The text was updated successfully, but these errors were encountered: