Garbled pbm output of window

[alexshendi]

I am using Medley Interlisp 2.0 for DOS.

I have tried to write a hardcopy routine to save window contents as an ASCII portable bitmap.

However the output is garbled (see attached png). I think there might be an off-by-1 error somewhere. The function in question is SAVEPBM.

PLOT3.TXT was renamed from PLOT3.LSP, which was generated using MAKEFILE. To run you could say:
(LOAD 'PLOT3.LSP)
(DEMO2) ;; Will take a long time

MYPBM.TXT was renamed from MYPBM.PBM and is the output of SAVEPBM.

Also I would be grateful, if there was a way to programmatically save a bitmap to a more modern format, that can be converted to PNG. There is READBITMAP/PRINTBITMAP, but while that should be more efficient thar querying the bitmap puxel by pixel, the format isn't documented.

The mouse menu hardcopy doesn't work because of missing fonts and ist only does InterPress/Press formats anyway.

Thank you for following my confused rambles so far and for possibly replying!

PLOT3.TXT
MYPBM.TXT

[nbriggs]

I loaded the PLOT3 package, compiled it -- (TCOMPL 'PLOT3) ran (DEMO2) (it took 3.8s on my old macbook air) and the resulting PBM looked just like the screen image. Gets the same output interpreted as compiled (and doesn't actually make much difference in the time). I'm running in Medley 3.51 and I know we fixed a BITMAPBIT issue not that long ago, but I didn't think it was present in the Medley 2.0 code. You have access to all the source, so you can look at PRINTBITMAP, which calls \WRITEBITMAP to see the format it writes the bitmap in (looks likes nibble at a time values offset by character code A, probably padding involved).

Middle of the night here, so I'll leave it at that.

[alexshendi]

Thank you. Normally, people insist that my code is buggy, while I am adamant that it works perfectly!

The machine that I ran it on is an 386SX @ 40 MHz, no match for wven an old Macbook.

[masinter]

by the way, I think the Dodo networking code includes a Interpress to PDF converter (written in Java, charset 0 only).

[nbriggs]

To see if it's BITMAPBIT that's causing trouble, I suggest a couple tests - first, make your bitmap a multiple of 16 bits wide (e.g., 256 wide instead of 242 wide) and see if that gets you the result you expected with your plot demo, second make a bitmap with, say, (BITMAPCREATE 17 10) (i.e., NOT a multiple of 16 wide) then read back the bits with BITMAPBIT and see if they're all 0, then fill it with black: (BITBLT NIL NIL NIL yourbitmap NIL NIL NIL NIL 'TEXTURE 'REPLACE 65535) and read the bits back again and make sure they're all 1. You can also try using (BITMAPBIT yourbitmap x y newvalue) to set bits and make sure that when you look at it with the editor (EDITBM yourbitmap) the bits are in the right place.

[alexshendi]

Thank you for your suggestions. Sorry, I have been travelling and have just returned.
I have changed the window's bitmap size from 242x230 to 256x256, but the pbm-file doesn't match the the displayed window contents (i.e. still garbled).

[alexshendi]

Further investigations:

• The format used by PRINTBITMAP seems to be:
  • A list containing the following:
    1. number of rows
    2. number of cols
    3. a number of strings (nrows total) of length ncols/4 (one char per nibble, in the format (code-char (+ nibble (char-code #\@))). At least that's the case for a 256x256 bitmap.

Execution times:

1. plot to window: 125s
2. saving to PBM via SAVEPBM: 2527s
3. saving via PRINTBITMAP: 9s

Please note again, that this is for a 386SX CPU @ 40 MHz.

PS: The bitmap created by PRINTBITMAP can be read in and displays correctly using EDITBM.

[nbriggs]

Sure sounds like BITMAPBIT failure. Re speed - did you compile your code?

[alexshendi]

No, I didn't. Here are the updated timings for compiled code:

1. plot to window: 112s
2. saving PBM via SAVEPBM: 1019s
3. saving via PRINTBITMAP: 9s

So greatest savings in SAVEPBM.

[nbriggs]

I presume the results of the saved PBM file are still incorrect?

[alexshendi]

YES.

[alexshendi]

One more question:
do the indices run from 0 .. 255 or 1 .. 256? But since it works with newer versions, I guess it's 0..255.

[MattHeffron]

It looks like each erroneous piece is 16 pixels wide.
This leads me to think it may be related to how the bitmap is being stored vs. accessed.
Specifically, is something getting 32-bit pieces of a row, but not treating the two 16-bit halves in the correct order?

It does work correctly on my latest release in Ubuntu 24.04 on WSL 2 on Windows 11.

[nbriggs]

Indices are from 0. The Medley 2.0 DOS version probably doesn't have DINFO loaded, so I'd suggest having a browser window open on online.interlisp.org so you can check the IRM pages easily - e.g, if you were to type (BITMAPBIT ?<return> in an Interlisp exec window it would pull up the manual page, and you could scroll around and see how bitmaps are addressed.