[Dr Lancer-X]

I wrote a small tool today that I plan on expanding and that others might mind useful. It is just a commandline tool for converting images into MZX charsets.

The simplest invocation is:

ccv image.bmp

which will convert image.bmp to image.chr

ccv -mzm image.bmp

will convert image.bmp to image.chr and image.mzm.

These are partial charsets, unless the image supplied is 256x112 (the size of MZX's charset) or some other dimensions that require 256 chars. If you want to convert a larger image, be sure to use at least -c 256, although you may require lower values if you want to use -exclude or -offset.

Currently the only image files supported are monochrome 8-bit raws and BMP images.

It also contains a number of other features described somewhat here:

Quote

Usage:
ccv input.bmp
.. converts input.bmp to input.chr. The conversion will convert the image to a charset or partial charset containing a quantised representation of the image. No char reuse will be done.
ccv input.bmp -mzm
.. converts input.bmp to input.chr and input.mzm. If the same character would have been used multiple times, it will be reused. Hence while the .chr itself may not match the input image, the combination of the .chr and .mzm will.
ccv input.bmp -reuse
.. converts input.bmp to input.chr, reusing chars where possible. This option is implied with -mzm, but can be used for simple charset output with this.
ccv input.bmp -mzm -noreuse
.. converts input.bmp to input.chr and input.mzm without reusing characters.
ccv input.bmp -o output
.. converts input.bmp to output.chr
ccv input.bmp -mzm -o output
.. converts input.bmp to output.chr and output.mzm
ccv input1.bmp input2.bmp -mzm
.. converts input1.bmp and input2.bmp to input1.chr, input2.chr, input1.mzm and input2.mzm
ccv -c 30 input.bmp -mzm
.. converts input.bmp to input.chr and input.mzm, with no more than 30 characters used. If necessary, close characters will be reused. -c implies -reuse.
ccv -offset 128 input.bmp -mzm
.. converts input.bmp to input.chr and input.mzm with the char indices in input.mzm being offset by 128 places. Hence loading the charset with load char set "@128input.chr" and placing the MZM should result in accurate graphics.
ccv -exclude 32 input.bmp -mzm
.. converts input.bmp to input.chr and input.mzm. If char #32 would otherwise be used in the conversion, it will be replaced with a blank char instead and will not be referenced in the output -mzm.
ccv -exclude 32-63 input.bmp -mzm
.. converts input.bmp to input.chr and input.mzm. If chars #32 to #63 would otherwise be used in the conversion, they will be replaced with blank chars instead and will not be referenced in the output -mzm.
ccv -exclude 0,32 input.bmp -mzm
.. converts input.bmp to input.chr and input.mzm. If chars #0 or #32 would otherwise be used in the conversion, they will be replaced with blank chars instead and will not be referenced in the output -mzm.
ccv input.raw -w 256 -h 112
.. converts input.raw to input.chr. input.raw is assumed to be an 8-bit headerless image of the dimensions given, where zero is black and nonzero is white.
ccv input.bmp -threshold 160
.. converts input.bmp to input.chr turning pixels >= 160 brightness white and other pixels black. If not supplied, the default is 127.
ccv input.bmp -dither floyd-steinberg
ccv input.bmp -dither stucki
ccv input.bmp -dither jarvis-judice-ninke
ccv input.bmp -dither burkes
ccv input.bmp -dither sierra
ccv input.bmp -dither stevenson-arce
.. converts input.bmp to input.chr using the given error-diffusion kernel. Note that you can abbreviate it (i.e. 'floyd', 'jarvis') as it only has to match part of the name. Note that the -threshold value, if supplied, is still used here.

Source code
Windows (32-bit) executable
Java (1.6) graphical frontend. Put it in the same directory as the executable and run it. It will allow you to work more interactively and use more file formats as input.

[Lachesis]

Converting to char sets bigger than 256 might be useful for applications that don't involve loading the file directly. That said, I came up with a format a while ago which addresses that in a way I find useful (similar to what Pandora's Gate used), so I'm not sure I'd use it for that myself.

[Dr Lancer-X]

You can use this tool for that, but parts of it (like MZM output) won't work properly. Just pure charset output should be fine though.

[Lachesis]

Oo, neat. Will check it out.

[ThDPro]

You guys couldn't come up with this stuff like, a year ago?? If anyone's poked around in Heroes Lost, you'd see cutscenes where I had to literally manually turn .bmps into .chrs with (the now newly revamped and WAY easier to use) charcon. Nice timing.

This post has been edited by ThDPro: 07 February 2013 - 06:19 PM

[Dr Lancer-X]

Added ccv v0.02, now supporting most standard BMP files. No compression support because nobody uses it anyway.

EDIT: Added ccv v0.03 with three new dither methods. The currently available dither methods are:

Quote

Floyd-Steinberg
Stucki
Jarvis-Judice-Ninke
Burkes
Sierra
Stevenson-Arce

EDIT: ccv v0.04, changes how error is diffused in the dithering code. floyd-steinberg at least is much less of a disaster now.

EDIT: Added a GUI frontend (written in Java). Put it in the same directory and double-click it and it should work. I also updated ccv to v0.05, fixing a memory bug when working with large images.



EDIT: ccv v0.06 added, fixing a bug where ccv would freeze on an indexed image on images with rows that are not a multiple of 4 bytes.

[Dr Lancer-X]

I updated the Java frontend to now support copy and paste. I also added keyboard shortcuts to the other File options.

[Lachesis]

ccv has a 'feature' i'd like to discuss (having multiple exclude chars gives me segfaults)

 imoutosoft.bmp (656.3K)
Number of downloads: 294

gdb --args ./ccv_debug.exe -mzm -exclude 0-31 -w 640 -h 350 imoutosoft.bmp

Program received signal SIGSEGV, Segmentation fault.
0x00405094 in ExcludeChars (cset=0xc80dc8, mzm=0xc810e0,
    exclude=0x630074 '\001' <repeats 32 times>, offset=0) at ccv.c:857
857         remap[i] = i;
(gdb) bt full
#0  0x00405094 in ExcludeChars (cset=0xc80dc8, mzm=0xc810e0,
    exclude=0x630074 '\001' <repeats 32 times>, offset=0) at ccv.c:857
        ci = 513
        i = 258
        remap = 0x101
        remap_offset = 256
#1  0x0040558c in main (argc=11, argv=0xc80de8) at ccv.c:939
        image = 0xc80da0
        qimage = 0xc810b8
        cset = 0xc80dc8
        mzm = 0xc810e0
        file = 0x640290
        cfg = 0x630048

 blank.bmp (656.3K)
Number of downloads: 290

gdb --args ./ccv_debug.exe -mzm -exclude 0-31 -w 640 -h 350 blank.bmp

0x0040510d in ExcludeChars (cset=0x761038, mzm=0x761058,
    exclude=0xa10074 '\001' <repeats 32 times>, offset=0) at ccv.c:861
861           remap[i] = cset->chars;
(gdb) bt full
#0  0x0040510d in ExcludeChars (cset=0x761038, mzm=0x761058,
    exclude=0xa10074 '\001' <repeats 32 times>, offset=0) at ccv.c:861
        ci = 18
        i = 9
        remap = 0x9
        remap_offset = 9
#1  0x0040558c in main (argc=10, argv=0x760de8) at ccv.c:939
        image = 0x761648
        qimage = 0x761010
        cset = 0x761038
        mzm = 0x761058
        file = 0xa20290
        cfg = 0xa10048

[Dr Lancer-X]

Oh wow. Seems the right fix is to replace

  int remap[cset->chars];
  int remap_offset = 0;
  for (int i = 0; i < cset->chars; i++) {

with

  int remap[cset->chars];
  int remap_offset = 0;
  int cset_chars = cset->chars;
  for (int i = 0; i < cset_chars; i++) {

I'll update the build and source later.

Apparently -exclude doesn't adjust the default -c value so -c 224 helps you actually get a 256 char charset out of it.

[Dr Lancer-X]

Fixed and new build uploaded. The more I look at this thing the more I want to rewrite it...

[Lachesis]

There's a new bug : ( ccv won't exclude more chars than the original conversion uses after reuse.

$ ./ccv -mzm -w 640 -h 350 -exclude 0-127 blank.bmp
blank.bmp -> blank.chr (2 chars), blank.mzm

Maybe not the best example, but I have another file that uses 58 chars after reuse and the final version has 116 chars instead of the expected 186:

$ ./ccv -mzm -w 640 -h 350 temp/*.bmp
temp/frame0.bmp -> temp/frame0.chr (58 chars), temp/frame0.mzm

$ ./ccv -mzm -w 640 -h 350 -exclude 0-127 temp/*.bmp
temp/frame0.bmp -> temp/frame0.chr (116 chars), temp/frame0.mzm

EDIT:

bad fix removed

[Dr Lancer-X]

Aha, so the original behaviour was intentional, it's just that as the array was of fixed size it caused a buffer overflow. Okay. Probably the best answer is just to make the array 512 long and go with that.

Anyway I've uploaded a new version to the vault.

[Lachesis]

given that excludes are limited from 0-255, I think this is actually a better fix than my last (which I removed because it was dangerous):

  int remap[256];
  int remap_offset = 0;
  //int cset_chars = cset->chars;
  for (int i = 0; i < cset->chars && i < 256; i++) {

i'm already seeing another potential issue if a char gets remapped multiple times and an MZM is saved though

[Lachesis]

confirmed the MZM multiple remap bug. here's my fix:

  if (mzm) {
    for (int i = 0; i < mzm->w * mzm->h; i++) {
      while ((mzm->data[i] != remap[mzm->data[i]])) {
        mzm->data[i] = remap[mzm->data[i]];
      }
    }
  }

EDIT:

here's the file that causes it:

 frame0.bmp (656.38K)
Number of downloads: 238

sorry i keep finding these right after you upload a fix : (

[Dr Lancer-X]

That's fine. I would have actually tested it but I only had a couple of minutes while I was in front of a Windows environment, so I figured I'd just compile, upload and hope for the best. I'll fix it and reupload later.

[Dr Lancer-X]

Thanks. Updated.

[zzo38]

I have written some other programs in C to do something similar (although more general), but it doesn't have all of the features you listed that ccv has. It works like:

bmpff < image.bmp | ff-strip 8 14 1 | ffbit 0 0 B 000000 FFFFFF > image.chr

It is my opinion using UNIX philosophy of each program doing one thing well and each program being a filter.

I can later add other stuff such as MZM, non-duplication, etc. However, conversion in the other direction (from CHR to another picture) is already possible, using a command such as:

bitff 8 3584 B 000000 FFFFFF < image.chr | ff-strip 8 14 32 | ffpng > image.png

(The above command assumes that you want 32 tiles per row, with black background and white foreground.)

[CJA]

That's certainly a valid approach, but I feel like ccv already does only one thing really well and all of the necessary sub-tasks and options provided are more or less inherent and inseparable from that task. Especially considering that we often need multiple output files (char set and MZM at the same time) which is cumbersome for a filter, and writing that on the command line would just be rewriting what ccv already does the hard way every time it needs to be used

Wait, why am I even,