Kimball Thurston

thanks for that testing - any way you could contribute the wrapper scripts you used to create the above? (i see the separate repo, just thinking it'd be good to...

it took a while as I went into a rabbit hole to make dwa very much better, but the huf and dwa compression routines (encode / decode) were not as...

yes, now that we have replaced the lower level reading functions, the next release of openexr will swap out the writing classes, and then the "other" / secondary classes like...

hrm, yeah, the setting up of the pointers is a bit upside down, you want use the setup for each chunk and then init /update the writing context for each...

the core layer does not have utilities to write a whole image, it is a bit lower level and forces you to work in chunks...

nice one, glad you got it working - just as a side note, you do not need to fill in the channel name in the encoder.channels struct - it will...

yeah, if I read this file using exrmetrics, it reports that it reads the entire file in 0.2 seconds, although I of course have a different system. The pattern gimp...

Ah, yes, the fix I did that removed the cache which was causing memory bloat means that for multi-scanline compression (i.e. piz), the scanline chunk is not being cached from...

bah, that's kinda ridiculous, that has been in the standard since C99, so it's hardly a "new" thing. That says to me that visual studio is not compiling that core...

c11 / c17 is fine. I still have a pending todo to add detection and revert to __restrict. I AM setting c_std_11 on the library define (see OpenEXRLibraryDefine.cmake), I wonder...