fish2000 / libimread Goto Github PK

Observe:

Figure 1. TIFF Multiwrite with im.Batch.

Figure 2. What actually happens: left: singular written TIFF file; right: multiwrite TIFF; center: source material.

OK so:

• Width and height are swapped, in a fucked way?
• Planes are read as interleaved during multiwrite (but NOT singular write)?!
• The TIFF library is doing that boundary-condition-repeat shit visible in the singular-write image; I did not specify that – I mean that is nicer than a segfault I guess, but where does it fucking come from???
• Basically those are my chief concerns dogg

1. Move more functionality to the base ancestor struct im::seekable
2. Do format detection inline therein, as is done by Pinterest in these NSData category methods
3. Do mutable stuff separately with method sigs and base functionality defined in like e.g. im::mutable or some such thing
4. Common ancestors should have the method sigs for turning these things to and from various image structs
   • e.g. im::Image and im::HybridImage but also ndarrays, CGImage/CIImage/CALayer, vImage, GL textures and stuff, ofImage, cv::Mat, NSWhateverTheFuckImageRep, et cetera ad nauseum
   • … use anything against which we can build, link conditionally in CMake, such that libimread/libimread.hpp defines the proper DO_WE_HAVE_XXX_FORMAT macros
     • that turn into type-trait features, within the definitions of im::ImageFormat subtypes
5. Separate I/O data path for dumping and loading via HDF5 storage
   • HDF5 I/O is NOT an image format – not defined in e.g. libimread/IO/hdf5.hh
   • API might offer async I/O via blocks, or pthreads, or fork() and ømq (q.v. note 1 sub)
   • Allow for more debug-y in-memory data dumping as well as a metadata control API
   • Define additional base type to supply methods (e.g. im::storeable/im::loadable or whatever)
6. If for some reason you feel like doing crypto, then do yr crypto (HMAC stuff, signature digests) herein
7. The ability to dump and load uncompressed pixel-format memory data, respectively, from im::Image to and from im::byte_sink and im::byte_source, would also be nice

[1] I have no freaking idea what tech or library to use, really – but who doesn’t love to pause and speculate idly in the moment, thinking of what it’d be like to find yourself coding such-and-such feature using this-that-and-the-other API, thinking of it like just for a second or two, maybe with a smile, thinking thoughts like these:

“yeah oh yeah that would totally be awesome and truly worth my time somehow, not at all a circuitous, distracting, total absolute Howling Debug Fantods sort of thing”

… I mean this one is soooo open-ended as at the time of writing this, I have not done anything involving anything explicitly async – e.g. like for example block stuff, or GCD primitives, or (alternatively) OpenMP pragma directives, or pthreading or fork()ing or NSOperationQueueing, or process-wrangling in general, or TSRing for that matter, or even <csetjmp>ing beyond the insistances of the libjpeg and libpng API boilerplate [2] – other than the extraordinary high-level calls one can express through the Halide scheduler’s API I have devoted little thought and given few fucks about doing any libimread stuff concurrently.

I don’t even really know what I am supposed to do when any one of the exceptions I have defined in my implementations ends up shooting off; I don’t do mutexes or deal with signal-handler state; I don’t give a fuck about focus lock when calling into CoreGraphics… and so on.

Obviously, I would prefer to do as little as possible aside from reading and writing images – which so like that means:

1. Whatever playful data-fuckery that requires’ll be in C++
2. My high-level APIs are in C++, Python/Cython, and Objective-C++
3. I use /((?P<objc>(ObjC|Objective-C))|(?P<c>(C)))?(?P<plus>(C|\+\+|PP|XX))?/ as I need to make calls, be they to:
   • FLOSS libraries (e.g. libpng)
   • Embedded Halide runtime-JIT programs
   • Halide Generator AOT libraries
   • GPU-accelerated OpenGL shader code
   • Mac-specific APIs (simultaneously, the most awesome and the least portable)
4. Some extra-credit loopy shit we are working on pushes these boundaries a bit, e.g.: a debug raster display with xterm 256-color terminal output, native XCode asset-catalog output through a write_multi() implemented on top of the pincrush ApplePNG’s hacks and the SSZipArchive API – which we did have write_multi() like waaaaay before the original mahotas-imread added its comprable imsave_multi() call, by the way I am just sayin

[2] which I am aware that referring to setjmp() as a “concurrent programming interface” is akin to calling the material commonly observed in a contiguous cluster near Donald Trump’s local altitude-maxima “hair,” like in how otiosely generous would saying that be; I am sure the original setjmp() author has to fight the urge to call Mom and brag, should talk of their concurrency API (née “parallel programming paradigm” or “domain-specific flow-conrol idiom” or “portable dynamic zero-cost calling-site abstraction” depending upon who is tweeting at whom with what) end up burning their personal ears

Evidence of same:

… at the time of writing I can’t explain that nonsense