ugovaretto/tjpp

Lightweight C++ frontend to libjpeg turbo

tjpp

Lightweight C++ frontend to libjpeg-turbo. Distributed under GPL v.3.0 license.

Dependencies: see dep/README.md

tjpp's Issues

colorspace != pixel format

In TjDeCompressor.h we call:

    tjDecompressHeader3(tjDeCompressor_,
                           jpgImg,
                           size,
                           &width,
                           &height,
                           &jpegSubsamp,
                           &colorSpace))

then later call:

    if(tjDecompress2(tjDeCompressor_, jpgImg, size, img_.DataPtr(),
                     width, pitch, height, colorSpace, flags))

The problem is that a turbo jpeg colorspace (TJCS) is not the same as a turbo jpeg pixel format (TJPF). The TJCS (colorSpace) returned by tjDecompressHeader3 cannot be passed as a TJPF to tjDecompress2.

It seems the pixel format isnt actually stored in the header, or at least isnt exposed by tjDecompressHeader3 and there seems to be no other header related functions. This means you must know the pixel format in advance and pass it directly to the Decompress() function along with the data pointer, size, flags and pitch.

( For TJCS vs TCPF: https://cdn.rawgit.com/libjpeg-turbo/libjpeg-turbo/master/doc/html/group___turbo_j_p_e_g.html#ga4f83ad3368e0e29d1957be0efa7c3720 )

Add in-place compress method

Add a method that accepts a JPEGImage& as the compression target

inline helper functions

Should be inlined to avoid multiple definitions:

1. NumComponents(), TJDeleter(), two versions of UncompressedSize() in JPEGImage.h
2. NComp() in Image.h
3. FromTJ() and FromCS in colourspace.h

UncompressedSize() is not bytes

In JPEGImage.h:

The UncompressedSize() function returns the number of components per pixel * number of pixels.

To be consistent with JPEGSize() it should be number of components per pixel * number of pixels * sizeof(pixel component), where in this case pixel component is float32.

It may simply be a case of multiplying by 4, as I dont see any capability in tjpp for non float32 based images, but in case supporting that is planned for future perhaps it needs a more clever approach. (I didnt check whether lib turbo jpeg supports non-float images, i guess if it doesnt then the answer is simply multiply by 4 appropriately in the UncompressedSize() function)

JPEGImage reset() suspicious

This line in JPEGImage reset() is suspicious, I think it should be corrected for the same reasons as #6, tjBufSize returns bytes whereas w * h * NumComponents(pf) is not bytes

   const size_t sz = std::max(tjBufSize(w, h, s),
                               static_cast< unsigned long >(
                                   w * h * NumComponents(pf)));

JPEGImage reset() doesnt update jpegSize_

At the end of reset() you should insert the following line so that the size is reported correctly by JPEGSize()

jpegSize_ = sz;

Fix default parameter in TjDeCompressor::DeCompress

Pixel format is now a required parameter: so pf cannot have a default argument anymore.

replace:
//read data from header case
    Image DeCompress(unsigned char* jpgImg,
                     size_t size,
                     int flags = TJFLAG_FASTDCT,
                     int pf = -1,
                     int pitch = 0) {
with: 
     //read data from header case
    Image DeCompress(unsigned char* jpgImg,
                     size_t size,
                     int pf,
                     int  flags = TJFLAG_FASTDCT,
                     int pitch = 0) {

Fix colorspace/pixelformat

Use TJPF_* everywhere, the Image class is supposed to be used only within this jpeg lib wrapper framework so the pixel format must match the jpeg format.

Extract SyncQueue

SyncQueue should have its own separate project

Add documentation

• doxygen
• wiki: getting started, examples
• generate doxygen into gh-pages to make it accessible online

Put timer in tjpp namespace

Otherwise Time conflicts with an Xlib typedef (would be helpful if the X guys used a namespace too!)

Implement serializers

Add serializer/de-serializer for JPEGImage in a format compatible with the srz::* framework currently part of zrf. This allows images to be streamed for e.g. remote visualization tasks.