• Picture compression in TeXnicard

    From news@zzo38computer.org.invalid@21:1/5 to All on Sat Apr 25 12:10:59 2020
    Here I will describe the experimental picture compression used in TeXnicard (although it is in the Fossil repository with TeXnicard, it is not
    currently used in TeXnicard, but in future it will be, for pictures that
    are in the card database). It is a lossless compression, with three or four channels, and either seven or eight bits per channel.

    The picture converted from RGB to YCoCg, and then each channel is stored separately, starting with Y, and then Cg, and then Co. (If there are four channels, which would be the case if the picture is CMYK, then the fourth channel is not converted, but is still predicted and huffed.)

    First, predictions are made. The C code for making predictions is:

    static int make_prediction(const unsigned char*p,int x,int y,int w) {
    int a=x?p[-1]:y?p[-w]:0;
    int b=y?p[-w]:x?p[-1]:0;
    int c=x&&y?p[-w-1]:a;
    if(c>=a && c>=b) return a<b?a:b;
    if(c<=a && c<=b) return a>b?a:b;
    return a+b-c;

    For the Cg and Co channels, the valid range of values depends on the
    values in the previous channels (this is why Cg comes before Co), so the prediction is clipped into the valid range.

    Predictions are then encoded as follows (where p is the predicted value,
    and v is the actual value):

    if(p==v) return 0;
    if(p&128) v^=255,p^=255;
    if(v<p) return 2*(p-v)-1;
    if(v<p+p) return 2*(v-p);
    return v;

    (For 7-bit predictions, the second line is changed.)

    After that, rectangles where the predicted value is zero are found, and
    are recorded, and then the remaining data is huffed. Each channel is
    huffed separately.

    In my experience, it tends to be somewhat better compression than PNG. The intention of this format is to be stored as database blobs for the artwork
    of cards, since using an external program to decode pictures in blobs
    would be more difficult to do. External pictures can be stored in any
    format; external programs are required to encode/decode. However, this
    format I describe here could also be implemented for external pictures.

    I invented this format in order to have a simple format included in the program, which is public domain, without having to add too many additional dependencies (the only dependencies are SQLite, Ghostscript, and whatever
    are the dependencies of Ghostscript; because Ghostscript is AGPL, this
    means those who distribute TeXnicard or make it available over a network
    access are required to follow the requirements of AGPL). I did not want to
    have a format which is too complicated, yet storing uncompressed pictures
    would result in too big file size of the card database.

    However, for pictures which are included in templates, one thing that
    might be useful is some efficient way of storing versions of pictures for multiple resolutions, in case you are rendering the cards at different resolutions it can store an optimized picture for that resolution rather
    than having to rescale it automatically. In addition to that, when CMYK
    mode is used, TeXnicard supports up to four custom separations in addition
    to the standard CMYK process colours.

    Please mention whatever comments you have about this, please.

    This signature intentionally left blank.
    (But if it has these words, then actually it isn't blank, isn't it?)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)