31 thoughts on “ham_convert”

1. Really Nice. Thax a lot!

   How can I view the pics on amiga in ham8?

   Reply ↓

   • You need an iff picture viewer. I use Deluxe Paint 5 for testing. Amiga can read a 720KB (not 1.44MB) PC-formatted floppy disk (instruction: http://goo.gl/ryk71d).

     Reply ↓

     • IIRC, my AGA Amigas had no trouble with 1.44MB PC floppy disks. I had an external Hi-Density Amiga drive and used the DiskSpare.device (free software) to get 1.96MB out of floppies. I seem to also recall using 1.44MB PC HiDen floppies with it. That was on an A1000 IIRC. You would need a Hi-Density floppy drive to get 1.44MB PC drive support from any Amiga.

       I seem to recall that only the A4000 came with Hi-Density floppies, but my A1200 has a HiDensity drive in it. Odd.

       TRSE is probably a good practical environment to play with actually using Amiga imagery. Even just or slideshows and demos. (I don’t know if it supports SHAM more or Dynamic HiRes though. Ask the developer- he seems to be a literal genius.) I will paste that URL in below.

       https://lemonspawn.com/turbo-rascal-syntax-error-expected-but-begin/

       Reply ↓

2. Any chance for Gameboy Color support? It uses 8 palettes, 4 colors per each. Each palette is applied to 8*8 pixel block (tile). Kind of Speccy on steroids since you can have 4 colors per tile and twice as much to choose from. 🙂

   Reply ↓

   • I can’t promise anything. I will do some research but currently I’m concentrating my work on Amiga modes. Non-Amiga modes aren’t fully implemented and they use an almost brute-force approach to palette generation. Game Boy Color has a palette of 32,768 colors so the number of combinations it too high to check them all. NeuQuant algorithm which I use for color reduction doesn’t work well with less than 16 colors.

     Reply ↓

     • Oh, I see. I’m not familiar with this stuff so I just asked seeing that there’s support for other 8bit platforms. No problem!

       Reply ↓

3. Nice converter! I’ve noticed the IFF saving option being disabled by modes that change the palette on a line by line basis. Would it be hard to implement writing the palette changes as PCHG chunk? Or at least as another simple text format file so it’s possible to convert it to a program/copperlist for the real machine!?

   Reply ↓

   • I’ve never had time to finish coding the sliced modes. There aren’t fully Amiga-compatible because in reality in 16-color mode not all 16 can be changed and with more colors it gets even worse. According to this document: http://wiki.amigaos.net/wiki/ILBM_IFF_Interleaved_Bitmap#ILBM.PCHG “in laced pictures the changes can only happen on even lines”.
     Number of color changes per line line can be selected in the DynamicHires mode, and in the latest beta version palettes are written to a png image (it was used for debugging but I’ve enabled it in the beta version).
     PCHG IFF support will be added after the current 1.2.0 release.

     Reply ↓

     • PCHG IFF export is available in 1.3.0 beta (in DynamicHires mode).

       Reply ↓

       • Sliced HAM6 PCHG IFF export is available in 1.7.0.

         Reply ↓

4. I have coded a colorcycling effect using palette changes per line starting from a 256 color base palette. I still have problems with horizontal artefacts when the palette changes from one line to the next. I saw in your images there are no such horizontal artefacts. What’s your strategy on minimizing these?

   Reply ↓

   • The effect can be seen here: http://www.pvv.org/~espenamo/11colorchanges256basepal.MOV

     Reply ↓

     • The only mode with color changes between lines supported by ham_convert is DynamicHires. Other modes including HAM use single palette. ham_convert is mostly optimized for HAM conversion, DynamicHires conversion still needs more work.
       Color changes calculation (DynamicHires mode):
       -16 unique colors per line.
       -Color changes only every 2 lines (2 successive lines have the same palette).
       for(j=0:number_of_lines-1)
{
for(i=0:number_of_changes_per_line-1)
{
0.if(j==0)calculate 16-color palette from the source image, else copy palette from line j-2,
1.prepare 16 palettes with color i,1,...,15 removed (remove 1 color from each one), convert lines j,j+1 of the source image to a new palette and calculate an average color distance between original pixel and converted pixel,
2.select palette with the lowest average color distance,
3.swap added color with color at index i,
3.convert lines j,j+1 of the source image to rgb444 and populate the array with all unique colors,
4.check all items in the array by putting each one in the empty space of the palette from (2.), convert lines j,j+1 of the source image to a new palette and calculate an average color distance between original pixel and converted pixel,
5.select palette with the lowest average color distance,
6.select palette with the lowest error,
7.convert line to a new palette.
8.j=j+2
}
i=i+1
}
       More advanced color changes calculation was developed by Trachu for his converter which produces DynamicHires images with less artefacts than ham_convert: https://www.ppa.pl/forum/scena/38042/dynamic-hires-czyli-nowe-otwarcie-mocy-amiga-500

       Reply ↓

       • Thanks for the detailed explanation! I’ll try it out for future demo projects 🙂 for this particular demo release I ended up skipping the per line color changes as the artefacts were too dirty and the deadline was coming fast.

         Reply ↓

5. Ham converter it’s a very beautyful software for project a bitmap graphic.
   I have work for my personal graphics.

   Reply ↓

6. Great program, thanks a lot!
   Would it be possible to add yet another feature? Namely to limit the number of actually used base-colors by having an edit field to tell the program to only use e.g. the first 55 of the 64 available base-colors for HAM8 and to ignore the remaining 9. My idea is to have some base-colors available for color cycle effects and such.
   What do you think?

   Reply ↓

   • I can add this feature in the next version.

     Reply ↓

     • That’s fantastic news, thanks in advance!

       Reply ↓

       • Added to the latest beta version. HAM6: 2-16 colors, HAM8: 2-64 colors.

         Reply ↓

         • Thanks, man, that’s great news! Just saw the update, fantastic work!

           Reply ↓

7. Yo man! Great update, as always. The triple-speedup works quite well.
   I have one idea for further improvement:
   the converter tends to use HAM modification-commands even if it could use a base-color instead.
   For example, here I have a logo with large patches of some greenish color (RGB 24,132,48) which ends up in base-color #24 (essentially this green is the main background color).
   But instead of using 24,24,24,24,… for a solid green horizontal line, hamconvert generates something like this instead:
   24, 225, 76, 134, 134, 134, …
   which means
   1. base-color #24
   2. change green to 132 (which it already is)
   3. change blue to 48 (which it already is)
   4. change red to 24 (which it already is)
   5. dito
   6. dito
   …

   While the resulting HAM8 picture is technically correct, not using the base-color whereever possible needlessly produces HAM artefacts when trying to do something with the picture beyond just displaying it.
   In my case I wanted to use DIWSTRT / DIWSTOP with a cover sprite to build a curtain effect.
   But because of the above this becomes impossible, the HAM artefacts are too severe.

   I added a patcher to my own HAM-to-proprietary-format converter to fix this by simply going over all pixels and checking for useless color-modification commands in respect to the last base-color command.

   Probably something like this would be a nice addon for hamconvert too.
   Cheers!

   Reply ↓

   • Thanks for the bug report. I will investigate this problem and I will try to fix it in the next release.

     Reply ↓

     • I’ve implemented a fix in the current beta version and it works in ham6 where the original image is converted to rgb444 first. It doesn’t make much difference in ham8 if the exact background color isn’t present in the generated palette. It happens quite often, because both NeuQuant and Wu frequently can’t faithfully retain background color. For example they generate 27,135,51 instead of 28,136,52. It’s often very close, but with all 3 components slightly different from the original it will be used once and then updated with modify until it reaches the exact value. If the program kept repeating the set it will never reach the exact value.
       Stretch contrast option alters the background color, so that you don’t know what color has to be present in the palette to generate consistent set pixels.
       NeuQuant, Wu, Scolorq can’t reliably retain background color when reducing palette to 64 colors. I’ve added Median Cut, which often retains background color, but generates worse palette overall. I’ve tested color reduction in IrfanView and it also generates slightly different background color. I think most other programs do that below certain number of colors. For now the user will have to manually modify palette using build-in palette editor or edit the calculated pal file in text editor to ensure the exact background color is present or select Median Cut, which degrades the quality. I’ll continue working on this.

       Reply ↓

8. Hi there, will it possible to add ‘Cancel’ or ‘Abort’ feature – for very slow conversions (like dynamic palette) it is common that results are not acceptable but there is no possibility to interrupt processing – we need to wait to the end or quit and close application. It could be nice to have opportunity to stop processing so different options can be verified.

   Reply ↓

   • Hello, I can try but it will be difficult to do safely on most Amiga modes.

     Reply ↓

     • Thx, you just triggered my curiosity – why aborting conversion and restoring initial state can be unsafe on most Amiga modes? ‘Exit’ button works great but it means you need relaunch ham_convert and set all options from scratch.
       Also this seem there is no repeatable behavior as computed palette seem to be different each time when conversion is started? It is correct observation (or i’m just confused?).

       For today i usually use GIMP with XiMagic Quantizer plugin to generate optimal 16 color palette for HAM6 (SColorQ method) then apply Gimp ‘Dither’ to restrict RGB 4:4:4 uniformly sampled (so OCS/AGA nibbles are matched) after this use GIMP ‘Index’ to convert true color into 16 color (after this step i can also rearrange colors in palette so they can be more functional like dark on index 0 and bright on index 1 or opposite for OS2 color scheme) then extracting JASC palette (trough IrfanView) as separate file so it can be used in ham_convert. As you see this is quite complex process.
       Btw i have few ideas to share – not sure if they are good or not – glad to hear your opinion.

       First – for HAM images horizontal edge detection may be helpful to take decision about using color from index or HAM – HAM fringing can be avoided by using index color so computing CLUT is important for edge areas – never tried to do this in GIMP or similar editor so perhaps building index palette focused on edge pixels can be good way to avoid HAM fringing.

       Second at least in theory resize, dithering should be done in linear light space (so remove gamma – dither – reapply gamma).
       Recall from slow computer times that trick to avoid costly processing in linear light space was performing all operations on inverted (negated) image – of course after processing there is need to negate negated result. Not sure it this work but some algorithms not focused on subjective quality (like median cut) can build different palette if this approach is used.
       Third is Ulichney dithering (blue noise) – can be useful for image sequences with animation target – i know some Ulichney precomputed tables are available. It looks like FS dither but it is stationary similarly to Bayer so no error propagation.
       Fourth is “standard”, precomputed OCS 16 color palette – not sure if there is possibility to embed such “standardized” OCS palette (it can be downloaded as external one but having possibility to select it from option can be faster than manually selecting it trough external file).

       Thx once again, returning quite regularly to check ham_convert, great work.

       Reply ↓

       • Generated palette is the same each time you run the conversion.
         I’m currently working on Oric Atmos conversion. Meanwhile I’m evaluating CIELAB alternatives like ICtCp, CAM02, CAM16.
         As for the dithering, I’ve already added Ostromoukhov variable-coefficient error dithering with coefficient tables generated from noise.
         16-color grayscale OCS palette can be selected using the pal. source – fixed 4-bit grayscale OCS. It produces quite ok HAM6 quality.
         I don’t know if adding edge detection will make much difference, because now when I calculate set/modify operation for the current pixel in triple mode I actually calculate a sequence of 3 pixels – current and next 2, so that the choice in the current pixel will produce better possible colors in the next pixels. In ham6 I think it’s more important to check how many color components are different from the previous pixel, because it determines how many modify operations are required. With a 3-pixel sequence modify operations can start before the edge to better reproduce color transition and reduce the lag between source color component values and actual ham6 values. Most edges can’t be reproduced using the limited 16-color palette.
         Dynamic Hires conversion cancel option was added in http://mrsebe2.bplaced.net/ham_convert/ham_convert_1.9.3_beta_12-12-2023.zip

         Reply ↓

         • Thx for Cancel/Abort – this will for sure improve possibility to quickly verify various settings (if i see that conversion results are NOK then i can try different settings).
           Edge detection – my opinion was related to fact that HAM6 is sensitive for something called “overload” – normal thing in delta modulation/compression (as HAM is delta compression). If edge (i.e. rapid change) of signal occurs then fringing is outcome – using horizontal edge information may narrow intensive search for lowest error in surrounding pixels. Of course this my naive interpretation.

           Reply ↓

9. Blue noise (Ulichney) noise mask generator can be found for example here:https://github.com/jdupuy/BlueNoiseDitherMaskTiles

   Reply ↓

10. Hi, this converter is amazing, thanks for developing it!
    I am trying to find the best combinations to convert some videos to CDXL (via agaconv), but I am not sure if the options used are the best. I extended agaconv to support different color schemes (like lab_cie94), but I am not sure if I am missing something.
    The generated command looks like this:
    java -Xms500m -Xmx2g -jar ham_convert_1.10.0.jar tmp-agaconv-video-ham6-320-20948/ham_convert_batch_file.txt ham6_q5 norle nopng dither_masked color_lab_cie94

    Not sure how to activate the triple mode or if there are better dither options – masked atm produces a sort of “colour-interlace” effect that makes the video look *a lot* better than FS!

    Another thing I noticed: the software runs faster on a 2012 i5@2.5GHZ (Mac Mini) than it does on an M3 Pro (2023)… any idea what could be the root cause? I can think either of an excessive number of threads (maybe I need to optimise via command-line), lack of memory, or unsupported math functions that need more operations on ARM.

    Reply ↓

    • I’ve added a more precise description of command line ham6 conversion profiles. Triple mode is activated in ham6_q4 – ham6_q7.
      Dither and dither_masked option use dithering more appropriate for ham6 that avoid adding additional noise. Second variant flips pattern on even lines to make it less visible.
      There is a new color space option in 1.10.0 that you can try instead of color_lab_cie94: color_ictcp.
      On ARM cpu you should install native ARM build of java: https://adoptium.net/temurin/releases/?os=mac&arch=aarch64. Otherwise it will use slower Intel emulation (there is an articlecomparing java 11 and 17 on arm mac: https://bitrise.io/blog/post/building-android-apps-on-apple-silicon). M1, M2, M3 have different types of cores – performance and efficiency. It’s possible that the installed version of java incorrectly assigns cores. There is a command line parameter to adjust number of used threads manually – threads_X – CPU threads, X=1 to available CPU threads.

      Reply ↓