Announcing: BMP2SHR Version 2.0 - Convert BMP's to SHR and VOC files and more - for Download

[Bill Buckels]

Download:
http://www.aztecmuseum.ca/extras/B2S.zip

User's Manual (included in the above):
http://www.aztecmuseum.ca/extras/bmp2shr.pdf

Tutorial (included in the above):
http://www.aztecmuseum.ca/extras/bmp2shrTutorial.pdf

BMP2SHR is a command line utility to convert BMP files to Apple IIgs SHR
Files. Please see the User's Manual and the Tutorial for information on
using BMP2SHR.

If you have BMP2SHR Version 1.0 upgrading to Version 2.0 is well worth the
effort. If you want to learn more about the SHR (Super Hi-Res) display on
the Apple IIgs or on the Apple II VOC (Video Overlay Card) or you want to
work with either, downloading BMP2SHR is likely worth the effort as well,
especially for Windows Users.

The BMP2SHR utility is provided with source code and 3 flavors of executable
program(s):

B2S16.EXE - MS-DOS Executable

Built under Large Model 16 bit Microsoft C (MSC) Version 8.00c
Note: Run in an MS-DOS emulator like DOSBox if you can't run it raw.

B2S32.EXE (bloatware) - Win32 cmd

Built under Visual Studio 2005 Microsoft (R) 32-bit C/C++ Optimizing
Compiler Version 14.00 for 80x86

B2S.EXE - Win32 cmd

Built under MinGW 5.1.4 (gcc). This EXE was used for most of the testing.
This builds properly under MinGW's gcc GNU c compiler also widely used in
Linux.

Build environments and source code are provided with all the above.

SubDirectories:

These have changed for BMP2SHR Version 2.0.

bmp - I no longer provide all the BMPs that I have used to prepare the Demos
and Documentation. A small number have been placed in this sub-directory to
keep from cluttering-up the main directory. Serious users of BMP2SHR are
unlikely to want my BMPs anyway so I see no point in making this
distribution any larger than it already is for the sake of providing the
source of the graphics content for the likes of demos and documentation,
since BMP2SHR's
finished output is already included with the demos and docs.

bmp2shr - Source code and build environments for BMP2SHR's various target
executables distributed in the main directory and noted above. See the
documentation also noted above for more details on what you can do with
these. See the source code and source code comments, etc. to find-out more
about how the implementation works. This will likely only be of interest to
programmers.

code - This sub-directory contains the Aztec C65 Version 3.2b source code
and AppleX build environment for some of the Apple II programs included on
the demo disks. In fact the main B2S directory is designed to be "unzipped"
below the AppleX\PROGRAMS directory on your own AppleX installation. This
will provide you with the ability to compile the AztecC65 programs included.

disks - Disk Images of demos etc. in 2mg format. Note that I have provided
copies of 4 Versions of an 8 bit SHR viewer by Ron Mercer called SHRView as
well as my own demo viewers in Aztec C65. Ron's program is distributed as
ShareWare. Recent attempts to contact Ron to register my own copy have
failed. Aside from that, since SHRView loads Brooks Format SHR files as well
as the PIC and PNT formats that my demo loaders also load, I am using Ron's
viewer for my slideshows of some of BMP2SHR's conversions.

Read the SHRView docs (on disk) for more info about SHRView. For that
matter, review the contents of these disks (using a disk explorer like
CiderPress) for more info about any of them.

docs - The User Manual and Tutorial, and other related documents live here.
If these documents do not give you all the information that you need to use
BMP2SHR, they will certainly provide a starting point. There are limits as
to how much information should be included in a distribution like this. I
have many more related documents which are available on request as time
permits, if this is not enough, and if Internet searches etc. are not giving
you the extra info you need.

I hope you enjoy using BMP2SHR. Please distribute what you have here freely
and in its entirety if possible. BMP2SHR was written for fun and is free for
all to use.

All the Best,

Bill Buckels
bbuc...@mts.net
February, 2014

[Bill Buckels]

Bill Buckels" <bbuc...@mts.net> wrote:

>Announcing: BMP2SHR Version 2.0 - Convert BMP's to SHR and VOC files and
>more...

>Download: http://www.aztecmuseum.ca/extras/B2S.zip
>User's Manual (included in the above):
>http://www.aztecmuseum.ca/extras/bmp2shr.pdf
>Tutorial (included in the above):
>http://www.aztecmuseum.ca/extras/bmp2shrTutorial.pdf

BMP2SHR is a command line utility to convert BMP files to Apple IIgs SHR

Files. I am offering a reward to anyone brave enough to download this
utility and use it to convert some (a minimum of 10) of their own BMP
Graphics using BMP2SHR. Submissions must be received by March 31st, 2014.

If you feel like participating, and meet the conditions listed below, you
will receive a single user licence for my ClipShop Utility downloadable from
the following link:

http://www.clipshop.ca

Here are my conditions:

1. Graphics must be different than what I provide in the content of BMP2SHR

2. Graphics must be a mix of "photos" and "artwork". They do not need to be
your own photos or artwork... but they should be of reasonable quality,
comparable (or better) to the images that I provide with all of this.

3. 10 (or more) Converted Graphics must be placed on a blank 2mg disk image,
and originating BMPs in reproducible format must be included, zipped-up
together, and emailed to me. Please also indicate if I have your permission
to use them and what you want me to use them for, attributions, etc. Or if
you want me just to look at them and then delete them from existence at my
end.

4. You must send me your First and Last Name and a valid email address. This
will be used for your ClipShop registration.

My motives for doing this aren't to promote ClipShop for profit. That ship
sailed a long time ago. The number of users who have registered ClipShop
could be counted on my toes with some left over.

Alternately, if you don't want to participate in this contest, if you have
contributed to BMP2SHR or to the promotion and well-being of SHR Graphics to
the Apple II community and you still want a ClipShop registration, send me
an email and I'll send you a registration key.

This automatically applies to folks like Antoine, Rob, Jonas, and Alex Lee.
Michael Mahon too.

[Antoine Vignau]

Thanks Bill for your message and program.
I enjoyed reading the manual and discovered the features offered by your program. Wouah! It is really powerful, congratulations!

I wanted to provide you with the smiling girl (the one you provided in 3200-col format) but that is already done :-(

Antoine

[Bill Buckels]

"Antoine Vignau" <antoine...@laposte.net> wrote:
>I wanted to provide you with the smiling girl (the one you provided in
>3200-col format) but that is already done :-(

Hi Antoine,

You provided me with everything that is available including inspiration. Do
you remember where she originally came from? I think I downloaded my copy
from a BBS in the early 90's.

As for my conversion algorithms, they were something I ported from old code
I wrote long ago.

Like you, I agree that error diffusion is not the best solution for
palettes. On most complex images error diffusion introduces too many
additional colors.

One solution that I would like to develop further is to reduce saturation
for first grouping of colors but I could spend years on that:)

Bill

[sicklittlemonkey]

On Wednesday, 19 February 2014 00:12:59 UTC+13, Bill Buckels wrote:
> Do you remember where she originally came from? I think I downloaded my copy
> from a BBS in the early 90's.

It's Len(n)a is it?
http://en.wikipedia.org/wiki/Lenna

She's not exactly smiling I suppose, but this has been classic image processing test data for a long time.

Cheers,
Nick.

[Michael J. Mahon]

"Lena" (Bell Telephone Laboratory)
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[Bill Buckels]

"sicklittlemonkey" <nick.w...@gmail.com> wrote:
>It's Len(n)a is it?

Hi Nick,

No. The image that Antoine and I were discussing is a picture of a girl's
face from an old demo that floated around for years. Brutal Deluxe has the
picture on their convert3200 page to demonstrate the capabilities of
convert3200.

I also used the same image in an old children's program called WorkBook that
I wrote for the IBM-PC in the '90's (I framed it and called it "HUSSY":)

I also used HUSSY and Antoine's Girl256 both in BMP2SHR's doucmentation.
They have slightly different palettes, but I won't get into that right now.
Gorl256 serves to illustrate the excellence of convert3200 over BMP2SHR. If
I took the time to compete with convert3200 I would likely be in an old
folks home before I was done. I am quite abit lazier these days than Antoine
was when he did all this.My strengths are simply my own experience in
mucking with images on the IBM side in those years.

I am happy as heck that you pointed me to Lena or Lenna or whatvere she
calls hereself now. This made a good case study to demonstrate BMP2SHR in
all of its nakedness, somewhat reminiscent of the "Emperor's New Clothes":)

Read about it here:
http://www.aztecmuseum.ca/extras/Lenna.pdf

Download it here:
http://www.aztecmuseum.ca/extras/Lenna.zip

None of this is new to you guys of course. It's not new to me either, but
since I have written a complete suite of command line converters from BMP to
all the Apple II formats, I wanted to make this one my crowning glory, the
ulterior motive being to promote the heck out of what someone can do in
Aztec C65 using my AppleX distribution.

Quite frankly, I was going along nicely with Charlie's Carte-Blanche Mods,
when two things occurred that threw a monkey-wrench into my plans to
continue my 8-bit fantasy:

1. I learned about Brooks mode3200 format and how difficult it is to display
without using efficient low level techniques and a fast Apple II. Thanks
Antoine and Rob.

2. I learned about the horrible cludge called the VOC and its questionable
support. Thank Jonas.

There were other realizations along the way that made me realize that I was
no longer writing an Aztec C Demo... I had reached the limit of what Aztec
C65 was easily capable of. So I just switched gears for a couple of months
and focused on the converter.

If I want to take my programming further on any of this it will either need
to be in assembler or maybe to "man-up" to Orca C and the GS and leave Aztec
C65 as-is.

It's all very informative anyway, so thanks for your SCART info along with
the No-Slot Clock routines etc. That sort of thing has helped me immensely
in my time travelling and diddling.

Now if someone actually uses some of this for themselves I would be thrilled
to hear about it and if not it was still fun. And FWIW I will include this
BMP2SHR thingy as part of the AppleX AztecC65 distribution for the next
release (if I do one perhaps in another 4 years or so).

All the Best,

Bill

[Bill Buckels]

"Michael J. Mahon" <mjm...@aol.com> wrote:
>"Lena" (Bell Telephone Laboratory)
Hi Michael,

Yes, the same company that gave me all my other fun toys. BTW I mentioned
you again in the following:

Read about it here:

http://www.aztecmuseum.ca/extras/Lenna.pdf

Download it here:

http://www.aztecmuseum.ca/extras/Lenna.zip

Also see my notes to Nick. I am hoping that if I keep sucking-up you'll
maybe help me locate a VOC for sale, and maybe even a second-sight VGA:) I
am really quite greedy...

Bill

[Antoine Vignau]

Olivier did the magic-logic of Convert 3200, I did the import/export filters
av

[Bill Buckels]

"Antoine Vignau" <antoine...@laposte.net> wrote:
>Olivier did the magic-logic of Convert 3200, I did the import/export
>filters

Hi Antoine,

I would sometime like to ask Olivier why he rejected accepting 24 bit input
files, and why he didn't want to apply error diffusion. Was this simply a
matter of scoping the project for what was needed at the time?

I realize that at one time the front-ends of these things wanted to accept a
variety of file types. convert3200 is a product, not some little utility
like BMP2SHR, so let's be clear that I understand we are not talking about
the same thing here.

But I am interested in what went on in those minds of yours and Olivier's
and how that ended-up in the internal logic and algorithms.

This wasn't some PC guy like me writing code for a hobby.

With today's tools it is easy to write for results. Little talent is
required comparatively.

Bill

[Olivier Zardini]

Le jeudi 20 février 2014 17:43:32 UTC+1, Bill Buckels a écrit :

> I would like to ask Olivier why he rejected accepting 24 bit input files,

Convert3200 starts as an utility for converting graphics for games. Antoine was working on Tinies at the time and we had the graphic from the Macintosh for static screens in 640*400 256 colors. At the time there was no graphic utility to convert pictures into 3200 colors. The F*ck were distributing the 3200 colors slide show but they never made public their IFF Converter utility.

So we had the 16 color 320*200 graphic from the Atari ST in one hand and the 640*400 256 colors from Macintosh in the other hand. We thought we could do much better than the 16 colors mode and even the 16 palettes conversion from Super Convert was not that good.

The main goal was to process PC files were the most of them were GIF files (also in 256 colors). The true colors ones like JPEG or Targa / TIFF were out of scope because of the complexity of the uncompressing process and the fact that Jpeg was destroying the picture (not useful for games).

At the end, when we moved Convert 3200 to be a generic Graphic conversion tool, the integration of True colors pictures (like BMP) was difficult due to the memory organization we have choosen. It was easier to manipulate pixels color using one single byte than 3 bytes (or 12 bit if the 4096 colors reductions has been done previously). Everything was written in assembly language so we had to deal with memory organization of the 65c816 like bank boundaries (and the 320*200 in 256 colors was fitting well 64 KB).

> and why he didn't want to apply error diffusion. Was this simply a
> matter of scoping the project for what was needed at the time?

The color reduction process in Convert 3200 doesn't use any of the well known picture processing treatment like color quantization, dithering, median cut...

We just apply a basic approach :
- we count the number of color per line (or screen)
- we know that we have to drop down this number to 16 (or less)
- so we have to replace a color (the one we remove) by an exiting one
- we choose the color to remove because :
- it is used by a very few number of pixel (so no one will notice it has been replaced)
- there is another color on the line, which is very close, so we can replace with something 'similar'

So, there is no global analysis or area analysis as we can do in error diffusion. It is basically an algorithm to search / replace 'weak' color.

The error diffusion algorithm was not used just because, at the time, I had no idea it was existing. For a greyscale conversion, Super Convert will do a better job using its error diffusion algorithm than Convert 3200 with its 'replace color' algorithm.

Olivier

[Bill Buckels]

"Olivier Zardini" <olivier...@cooperteam.fr> wrote:
>The true colors ones like JPEG or Targa / TIFF were out of scope because of
>the complexity of the uncompressing process and the fact that Jpeg was
>destroying the picture (not useful for games).

Hi Olivier,

Thanks for the insight. I remember the times. I remember the Amiga and the
IFF format (I once wrote a couple of soundtracks for a Black Belt Systems
Pac Man for their Ham-E Board and our Chamelon Junior product ran on an
Amiga 500... to me it was just a toy though). Nobody shared source code
either... that's for sure!.

C$erve and gifs were indeed state of the art for most PC guys.

Those early jpegs were brutally lossy. I was working with uncompressed 16
bit Targa Images at the time because we were writing kiosk systems (not
games) on the PC and needed True Color. We used Targa Boards for image
capture, but each image was a half-meg in size and quickly filled a
hard-drive of the time to capacity. It took almost 10 seconds to load!

>At the end, when we moved Convert 3200 to be a generic Graphic conversion
>tool, the integration of True colors pictures (like BMP) was difficult due
>to the memory organization we have choosen. It was easier to manipulate
>pixels color using one single byte than 3 bytes (or 12 bit if the 4096
>colors reductions has been done previously).

Well said! When I moved my little utility to version 2.0 I cheated and
downgraded my 24-bit routines to 8 bit palettized routines to share the
algorithms for PIC conversion. Sometimes it isn't worth a complete rewrite
for complicated code.

>Everything was written in assembly language so we had to deal with memory
>organization of the 65c816 like bank boundaries (and the 320*200 in 256
>colors was fitting well 64 KB).

If it ain't broke, don't fix-it!

>The color reduction process in Convert 3200 doesn't use any of the well
>known picture processing treatment like color quantization, dithering,
>median cut...

These were not known to me when I was paid to do graphics. Later I read
about these and understood but had no time for study when I needed to know
more... c'est la vie!

>We just apply a basic approach :
>- we count the number of color per line (or screen)
>- we know that we have to drop down this number to 16 (or less)
>- so we have to replace a color (the one we remove) by an exiting one
>- we choose the color to remove because :
>- it is used by a very few number of pixel (so no one will notice it has
>been replaced)
>- there is another color on the line, which is very close, so we can
>replace with something 'similar'

This is exactly what I do in my little utility. Except that I think you are
a better judge of near color than I am.

>So, there is no global analysis or area analysis as we can do in error
>diffusion. It is basically an algorithm to search / replace 'weak' color.

It appears to me that the skill lies in determining weak colors and then
mapping to a near color.

>The error diffusion algorithm was not used just because, at the time, I had
>no idea it was existing.

I didn't know that then either...

>For a greyscale conversion, Super Convert will do a better job using its
>error diffusion algorithm than Convert 3200 with its 'replace color'
>algorithm.

The potential for using error diffusion today is even greater I think. I
wish I had more time to play with this problem.

Thanks again for affirming that I indeed had a genuine experience with the
same logical problems you and Antoine faced. I did not need to deal with
memory problems, or processor speed, so I have the luxury of coding in C,
yet by comparison convert3200 stands as a remarkable example of the times
with its better palettization.

It makes me appreciate what I have now and I am happy I didn't look at your
code because I had the pleasure of frying my own brain over this only to
come-up with the same basic solution.

Bill

[Charles Richmond]

"Bill Buckels" <bbuc...@mts.net> wrote in message
news:le87fg$1r6$1...@speranza.aioe.org...

> "Olivier Zardini" <olivier...@cooperteam.fr> wrote:
>>The true colors ones like JPEG or Targa / TIFF were out of scope because
>>of
>>the complexity of the uncompressing process and the fact that Jpeg was
>>destroying the picture (not useful for games).
> Hi Olivier,
>
> Thanks for the insight. I remember the times. I remember the Amiga and the
> IFF format (I once wrote a couple of soundtracks for a Black Belt Systems
> Pac Man for their Ham-E Board and our Chamelon Junior product ran on an
> Amiga 500... to me it was just a toy though). Nobody shared source code
> either... that's for sure!.
>

Check out the "Lenna" Wikipedia page:

http://en.wikipedia.org/wiki/Lenna


--

numerist at aquaporin4 dot com

[Marco Verpelli]

I found Lena (or Lenna) also in the demo images of this software: http://wsxyz.net/tohgr.html

By the way anyone of you know if exist a "packer" for DHGR images? I mean for Apple // not GS.

Thank you!

Marco

[gid...@sasktel.net]

SCRUNCH by beagle bros.

I also created my own before I knew that Scrunch existed. My program was a bit smaller and can do both single and double hi-res screens from the same driver. Although the compressed size was pretty much the same, even though my compressed graphics contains a 16 byte header. The 16 byte header held info such as width and height, animation pointers, etc. You could capture and compress any area on the screen. I used it a bit for PS clipart. As far as animation goes, one could capture, as many clips as one wants, different areas of the screen but save them one after another in the file. Then the decompression routine can decompress the clips on the same coordinates of the screen, giving a semblance of animation.

The animation was stuck to one spot on the screen, so I didn't go any farther with it. If you email me, I can send you both on a disk image.

Rob

[Marco Verpelli]

Thank you, I have found SCRUNCH on a Alpha.Plot disk image

Marco

[Marco Verpelli]

... and DOUBLE.SCRUNCH on BeagleGraphic ProDOS.

Marco

[Bill Buckels]

"Marco Verpelli" <mver...@libero.it> wrote:
>By the way anyone of you know if exist a "packer" for DHGR images? I mean
for Apple // not GS.

Marco,

What is wrong with the two DHGR packers that come with Aztec C65's AppleX?

The problem with Beagle Bros. Scrunch is you don't have the code...

More about this later.

Bill

[Marco Verpelli]

There is noting wrong with your code!
I was trying to understand what software (if exist) can read/write ProDOS file type $08.

SCRUNCH work but is not for that kind of file, my research continue...

Marco

[gid...@sasktel.net]

You have a few options


From applesoft and to use with dbl.scrunch the line is

10 D$=CHR$(4)
20 PRINT D$"BLOAD scrunched_graphic_name,A$60FF,T$08"

REM then call the un-scrunch routine
REM with BSAVE add the L parameter


OR just change the file type to $06 (BIN)

OR write your own ML header to load a type $08 file and call scrunch

[gid...@sasktel.net]

I was looking at another decompression routine
the correct applesoft line is

20 PRINT D$"BLOAD scrunched_graphic_name,A$4000,T$08"
30 POKE 0,0: POKE 1,64: CALL 28675

[Steve Nickolas]

On Tue, 25 Feb 2014, Bill Buckels wrote:

> The problem with Beagle Bros. Scrunch is you don't have the code...

I used Scrunch in something, I think it was Donkey Kong P8, by
disassembling it and reorging it. xD It's small and not that complicated.

-uso.

[Marco Verpelli]

The image was from an Apple ///. I also read a technical note about file type $08. Now is all clear for me.
Sorry for bother you all.

Marco

[Bill Buckels]

"Steve Nickolas" <usot...@buric.co> wrote:
>I used Scrunch in something, I think it was Donkey Kong P8, by
>disassembling it and reorging it. xD It's small and not that complicated.

Have you still got your work? I want it and any advice you can offer or
additional analysis. That was really my question... DOUBLR SCRUNCH and
SCRUNCH are very efficient and quick.

If I had a breakdown on exactly what they do algorithmcally I could code a
commandline converter to provide a compatible converter that everyone could
use.

Put me on your waiting list if you don't mind.

Bill

[Steve Nickolas]

On Tue, 25 Feb 2014, Bill Buckels wrote:

Not really much of anything, as I didn't comment it.

I did change the address for the image from 4000 to A700, because I needed
4000-5FFF for something, but A700-B6FF was just used to hold level data
and I could just destroy that and load the correct data immediately after.
So it more or less looks like this...

.org $B807

unpak: lda #<$2000
sta $08
lda #>$2000
sta $09
lda #$FF
sta $F9
lda #$3F
sta $FA
lda #<$A700
sta $FB
lda #>$A700
sta $FC
lda #$07
sta $FD
lda #$77
sta $FE
lda #$0B
sta $FF
cld
lda $08
sta $1B
lda $09
sta $1C
lda $FB
sta $19
lda $FC
sta $1A
@1: ldy #$00
lda ($19), y
cmp #$80
beq @2
cmp #$FF
bne @4
@2: ldy #$01
lda ($19), y
sta $FD
ldy #$00
lda ($19), y
and #$7F
ldy #$00
@3: sta ($1B), y
iny
cpy $FD
bcc @3
clc
lda $19
adc #$02
sta $19
lda $1A
adc #$00
sta $1A
clc
lda $1B
adc $FD
sta $1B
lda $1C
adc #$00
sta $1C
sec
bcs @6 ; ALWAYS
@4: ldy #$00
lda ($19), y
sta ($1B), y
inc $19
bne @5
inc $1A
@5: inc $1B
bne @6
inc $1C
@6: sec
lda $F9
sbc $1B
lda $FA
sbc $1C
bcs @1
rts

It looks like the code is completely relocatable. In my case input is
A700 and output is 2000 but you can see where that is stored.

-uso.

[Bill Buckels]

"Bill Buckels" <bbuc...@mts.net> wrote:
>I am offering a reward to anyone brave enough to download this utility and
>use it to convert some (a minimum of 10) of their own BMP Graphics using
>BMP2SHR. Submissions must be received by March 31st, 2014.

Thus far, only Jonas was brave enough to take advantage of this fine
offer... and easily surpassed any trivial conditions... the clock is ticking
for anyone else who wants to kick the tires on this.

By pushing his own work with SHR images to the limit we discovered a hidden
feature that will be adressed shortly in a minor release along with the
release of a new SHR utility called SuperSat.

In the meantime, as a matter of record we have discovered that if an image
is highly optimized and if the palettes have been created linearly from the
top left of the Image file instead of the bottom left, the optimized palette
cannot be reverse engineered properly the way BMP2SHR now works. Palette
order is important.

This hidden feature is a little more complicated than that but that'll do
for now. That part has been fixed somewhat.

Also, way more than a mere 256 24-bit colors can be crammed into a PIC file
than a 256 color BMP file, since colors are reduced to a bit depth of 4 bits
from 8 bits on conversion to SHR, so optimization techniques that use 4 bits
rather than 8 bits to palettize can potentially yield some pretty amazing
results.

Watch for more on this shortly. I've been working with error diffusion, and
other interesting stuff to do with Brooks conversion the last couple of
months, but with Jonas's work with PIC files looking so promising, it's time
to get this Brooks work out the door and get back to BMP2SHR.

Testing continues...

Bill

[Bill Buckels]

"Bill Buckels" <bbuc...@mts.net> wrote:
>This builds properly under MinGW's gcc GNU c compiler also widely used in
>Linux.
>Build environments and source code are provided with all the above.

If anyone who knows how to run a C compiler and who has OSX and gcc can take
the time to compile BMP2SHR for OSX please email me and I'll send you the
latest source. It has come to my attention that somewhat ironically that at
least one Mac user needs to use DosBOX and the MS-DOS 16 bit version of
BMP2SHR.

Or if anyone can send me a link to an OSX emulator that runs on Windows I'd
be happy to attempt this myself.

Bill

[Oregonian Haruspex]

If you throw it up on Github I'd be delighted to compile it for you.
Thanks.

[Bill Buckels]

"Oregonian Haruspex" wrote:
>If you throw it up on Github I'd be delighted to compile it for you.
>Thanks.

I'd be delighted too...

What targets can you build for? (If I wasn't so frickin lazy I'd put-up my
VM's of Ubuntu and Suse and Mandrake and do this myself, but I seem to be in
the middle of coding the next version with lots of good thoughts from Jonas
setting the bar on this quite abit higher)

Here's what I have so far:

Courtesy of mmphosis:

i686-apple-darwin10
powerpc-apple-darwin8
i686-linux-gnu

They are now available for additional testing and for general use from the
following link:

http://www.aztecmuseum.ca/extras/bmp2shr-gcc.zip

And of course:

MS-DOS version (runs fine in DOSBox but limited to short filenames and
slower)
Win32 Visual Studio Version (bloatware)
MinGW Win32

Download:
http://www.aztecmuseum.ca/extras/B2S.zip

User's Manual (included in the above):
http://www.aztecmuseum.ca/extras/bmp2shr.pdf

Tutorial (included in the above):
http://www.aztecmuseum.ca/extras/bmp2shrTutorial.pdf

Comes with latest source.

I also have a whole load of other utilities for A2 Graphics conversion that
I'd like to get ported to Win32 from MS-DOS and then forward to an
interested party or parties to make available for OSX and Linux.

I obviously can't handle this myself, and I seem to be spending an
inordinate amount of enjoyable time writing documentation, because it seems
to end-up with a litany of new features that I end-up adding and documenting
ad-nausem and iteratively.

The source code is already on my websites distributed with the executables.
That way I can control the bugfixes and stuff without taking time to do
configuration management which is too much like work.

Maintaining the websites is enough for me:)

Bill

[mmphosis]

Hi,

I only did a very simple test using the b2s-i686-apple-darwin10 binary
executable running Mac OS X 10.6.8 (Intel.) I created a makefile for gcc.
I define MINGW when compiling. As noted, I built binary executables for 3
targets...

i686-apple-darwin10
powerpc-apple-darwin8
i686-linux-gnu

Be aware that a "copy" of the C source code file that I used to build the
executables is included in the ZIP file:

http://www.aztecmuseum.ca/extras/bmp2shr-gcc.zip

Assuming you have gcc installed, you can compile the source with the
following command:

gcc -DMINGW -o bmp2shr bmp2shr.c

I just ran this on x86_64-linux-gnu, and it gives some interesting warning
messages.

bmp2shr.c: In function ‘main’:
bmp2shr.c:4941:5: warning: ‘gets’ is deprecated (declared at
/usr/include/stdio.h:638) [-Wdeprecated-declarations]
gets(fname);
^
/tmp/cc31Qxlf.o: In function `main':
bmp2shr.c:(.text+0xd13e): warning: the `gets' function is dangerous and
should not be used.

Of course, you already noted in the documentation that the use of the gets
function is not a good idea.

[Oregonian Haruspex]

I can build for OS X 10.8 and 10.9, Windows XP (possibly) and Ubuntu at
least. Perhaps even iOS!

[Bill Buckels]

"mmphosis" <mmph...@macgui.com> wrote:
>I only did a very simple test using the b2s-i686-apple-darwin10 binary
>executable running Mac OS X 10.6.8 (Intel.)

The utility itself has seen several months of extensive daily testing
including weekends whatever weekends are. Lately Jonas has been kicking the
cr*p out of it right along with me. If it runs it works... unless found to
be otherwise as in any program.

>I created a makefile for gcc. I define MINGW when compiling.

The reason for this define is to pack the structures on one-byte boundaries.
Structure alignment is a big gotcha... Most C programmers know this of
course by the time they get out of the sandbox... everything else is just
Ansi C.

Unless I missed using a typedef somewhere in the code this should be good to
go almost anywhere. That is the hope and dream.

>As noted, I built binary executables for 3 targets...

>i686-apple-darwin10
>powerpc-apple-darwin8
>i686-linux-gnu

This was a nice thing you did.

>Be aware that a "copy" of the C source code file that I used to build the
>executables is included in the ZIP file:

:)

I use version numbers so will increment the version by a revision if
incompatibility issues are found... which I doubt and these utilities are
only 1 source file and dead-dumb simple anyway... not much can go wrong
compared to a non-trivial program.

>http://www.aztecmuseum.ca/extras/bmp2shr-gcc.zip

>I just ran this on x86_64-linux-gnu, and it gives some interesting warning
>messages.

>warning: the `gets' function is dangerous and should not be used.

Deprecated for buffer overflow... In this case it is only used in a user
prompt for an input file if no commmand-line args. I could use getchar and
roll my own input prompt. It would be a bummer if someone entered an input
file name of over 256 characters. I am counting on laziness preventing
someone from doing so. In retrospect, that is more arrogant than usual on my
part.

If someone tries to pipe a BMP file through the utility using stdout the
risk of a core dump etc. also exists. I admit to not worrying about this.
Maybe I need a gcc define to take this out and support a binary pipe
instead. Should I continue to count on Windows users not thinking about
binary pipes? I wonder...

In my Microsoft Win32 MAKEFILE I turn deprecation warnings off. I see some
of the newbies who haven't been around C for 30 years or so are asking why
these functions should be available anymore. Perhaps by the time they
graduate they will understand that they don't run the place; they just work
here like the rest of us.

>Of course, you already noted in the documentation that the use of the gets
>function is not a good idea.

If I did that could be easily missed:)

Thanks again for your help and interest. The attention came as an unexpected
and encouraging shock. Encouraging because it gives me a reason to look at
portability issues and not encouraging because of my laziness. If you are a
PERL fan like I am, you might remember what Larry Wall said about the 3
great virtues of a programmer...

Bill






Bill

[Bill Buckels]

"Bill Buckels" <bbuc...@mts.net> wrote:
>BMP2SHR is a command line utility to convert BMP files to Apple IIgs SHR
>Files. Please see the User's Manual and the Tutorial for information on
>using BMP2SHR.

I will shortly be completed the coding of additional palettization routines
and conversion routines for converting BMP's to the plain old Apple II GS
SHR PIC file.

These routines were missing from the first couple of versions of BMP2SHR
because I focused primarily on verbatim output for PIC files (or close to
verbatim output) and wanted to offer support for the VOC's interlaced mode.
Those were two pretty tall orders. When the Brooks output routines became
unwieldly, I began work on a preprocessor called SuperSat to pepare photos
and true color images for Brooks Conversion.

I coded BMP2SHR to promote all PIC files to Brooks if they could not be
encoded using color reduction and a simple sequential palettization routine.
The Brooks algorihms did not concern themslves with color space; instead
they used a population method of quantization, combined with several other
techniquess to get some pretty fair results without much fiddling.

In the meantime Jonas began work on converting to PIC files. I was working
on SuperSat still with a Brooks focus, but pronounced SuperSat complete a
couple of weeks ago and began to look at Jonas's stuff, which has got
FANTASTIC results, using an iterative approach and a preprocessing script
which he wrote in PHP supporting a utility called ImageMagick.

My work on SuperSat and the HLS color model, combined with problem images
that Jonas produced and forwarded for analysis led me back to the humble PIC
file.

Another programmer in here, Riccardo Grecco, has heavily utilized the same
iterative approach to his carreer in calculating the modeling of electrical
motors using Runge-Kutta methodology (with his Apple II Aztec C version of
part of his simulation). Simply put, Runge-Kutta solves differential
equations using trial methods combined with iteration.

Jonas's palettization also solves palettization and optimization of SHR
images using the same essential techniques and in fact BMP2SHR was almost at
the point where some of what I had learned from being involved with the work
of these two fellows began to conjeal and not simply influence the direction
I had taken from the start. And yes error diffusion and median cut
algorithms are already almost in place through all of this, either in
SuperSat or new in BMP2SHR.

Some basic posterization was already being done in side the program two,
combined with my now-famous-in-my-own mind technique of substituting
original populatistic colors linearly, and the additional hexaconal HLS
methodology was implemented in the new stuff, as well as saturation control.

It boggles the mind (mine at least). Just over the last couple of days I
learned a great lesson from Jonas and coded the thing already: If a
non-trivial and highly optimized preprocessed image is palettized into 16
segmented palettes, and a guy reverse engineers that type of image, by
putting the longest lines into a PIC file first (line order rather than
sequential first-fit) it is easier to fit the smallest number of line colors
into a palette last of all. I smacked my forehead and coded the thing with
clarity; a rare moment.

There is much more to tell about all of this but there are 3 main messages
here:

1. I have Jonas's scripts. His PIC files are attrociously good. This is art
now folks! I am looking for time before summer to get into Imagemagick's API
myself, to see what kind of production for not only PIC's butter graphics
for the lesser Apple II modes can be accomplished.

In the meantime, not to take away from his work to this point, I hope he
gets some of this out to you before I start my Imagemagick work... I hope he
will... it's too good to keep from everyone:)

2. Riccardo is busy with his work with educating young minds. But he has the
math background to build a real colorspace model based on CIELUV and color
preception and apply it all to conversion to Apple II graphics formats. I
hope he turns sideways from his other other job of redoing his thesis on the
Apple II to look at things like computational errors that occur in HLS
between the Cyan and Blue scales... it's staggering to me that this model
that has been around since 1963 or thereabouts as an industry standard seems
to have an error in its hexacone of about 800 in 16.7 million that is buried
so deep that it has been on Wikipedia for years, and never been caught (at
least I think I may the first... staggering I tell you... which I discovered
doing the implementation of hue in SuperSat's Hue Channel algorithms).

3. The PIC file quantization in BMP2SHR will with Version 3 and
Doucmentation be available within a week or so... promises promises... but
will offer median cut variations on quanatization, and additional
posterizing that is sorely needed for PIC file output. Not everyone has a
VOC or wants Brooks Images (On fact it is debatable whether everyone wants
SHR at all:)

But for those that appear to, including mmphosis who provided MAC OSX and
Linux builds of BMP2SHR Version 2, Version 3 Windows and MS-DOS builds of
all of this new stuff will soon be available for download from the Aztec C
website and the AppleOldies website.

And that should bring you up to date.

Whoever said Space is the Final Frontier should have included Time, Vapour,
and Color Space. Lightspeed has some interesting reflections when it is
funneled backwards in a hexaconal manner on an Apple II display.

Bill

PS - And when I say Jonas's Imagemagick stuff is good and it's Art, I mean
it. I groan under the weight of it all, but can hardly wait to see what he
dreams-up next week:)

[STYNX]

On Saturday, March 22, 2014 9:17:42 PM UTC+1, Bill Buckels wrote:
> "Bill Buckels" <bbu###@#ts.net> wrote:
> ...

> PS - And when I say Jonas's Imagemagick stuff is good and it's Art, I mean
> it. I groan under the weight of it all, but can hardly wait to see what he
> dreams-up next week:)

Bill, you give me too much credit. I am happy to have helped you to get where you want to go, but my part is small compared to your work. I think that the biggest 'breakthrough' i had was to use ImageMagick for the actual image processing. This tool features a multi pass posterization-process that is art in itself. Im not really happy with my first step of line-selection for each palette. The reduction of the lines into a single value for comparison is only based on (median of all pixels in the line [r+g+b/3] ) and that is not very optimal. But it was easy and gave relatively good results in a short amount of time. As stated, the real Magic is in the tool i used. I just built an interface for it.
http://forum.classic-computing.de/index.php?page=Thread&threadID=5989
(the link is to a german forum, just look at the images ;-)

-Jonas

[Riccardo]

> 2. Riccardo is busy with his work with educating young minds. But he has the
>
> math background to build a real colorspace model based on CIELUV and color
>
> preception and apply it all to conversion to Apple II graphics formats. I
>
> hope he turns sideways from his other other job of redoing his thesis on the
>
> Apple II to look at things like computational errors that occur in HLS
>
> between the Cyan and Blue scales... it's staggering to me that this model
>
> that has been around since 1963 or thereabouts as an industry standard seems
>
> to have an error in its hexacone of about 800 in 16.7 million that is buried
>
> so deep that it has been on Wikipedia for years, and never been caught (at
>
> least I think I may the first... staggering I tell you... which I discovered
>
> doing the implementation of hue in SuperSat's Hue Channel algorithms).
>

I Thanks you, for your consideration,
Just a rapid attempt, i'm completely unprepared in "Colours" and "Imaging" problems matter.
It is non linear equations of space transformation. If need simply to apply equation to transformation model to model, all is already done, this is a good base to start, take a look this C and Matlab codes:

http://www.mathworks.com/matlabcentral/fileexchange/28790-colorspace-transformations

Another thing is, if is need to solve the non-linear equations. In this case is necessary to implement a numerical solution iteration method, like Newton method.
But i can't, now, to deepen this interesting matter.
See soon.

-Ric.

[Bill Buckels]

"Bill Buckels" <bbuc...@mts.net> wrote:
>computational errors that occur in HLS between the Cyan and Blue scales...

Correction: That should have said GREEN and CYAN scales.

Some further detail is in order here for folks who actually know about the
HLS color model...

http://en.wikipedia.org/wiki/HLS_color_space

HLS has less to do with color perception than providing a measurement of
color. It is like mixing a paint formula or printing in the Analog World,
except that in the Analog World, building color is subtractive, starting
with a light or white base and adding tints or ink to make them darker, and
in the Digital World we start with a black screen and add to RGB gun values
to make colors lighter. On a computer screen we can only control colors by
scale the same way we do with paint tones (HUE degrees) and paint shades
(HUE distance aka SATURATION and lightness aka LUMINANCE). But by
definition, a digital scale is fixed to a sample or bit depth and an analog
scale is neither fixed nor linear. Consistent and measured paint shades like
computer colors are fixed when mixed. And what how paint or print responds
to photons depends on what kind of finish has been applied Computer colors
do not absorb photons like unfinished paint nor are they reflective like
gloss finish; Computer screens emit photons like the sun. Whether one paints
a wall, or renders color in an image on an Apple IIgs in SHR mode or on a
Modern computer screen in 2-bit or greater color, achieving white balance
provides a base value, but representing what a color looks like when a cloud
passes overhead on a sunny day, or in the sunset facing east, or on a
moonlit night is beyond the scope of HLS to model without some additional
help.

As a paint mixing formula or a computer color formula, HLS works well enough
for general purpose use.

In image converters and editors like PhotoShop or my SuperSat utility for
preprocessing BMP files destined for conversion to Apple IIgs SHR files with
BMP2SHR, colors in an image can be separated into smaller groups called
channels to perform adjustments and transformations exclusive to the colors
in a particular channel. I don't know or care how PhotoShop calculates its
RGB channels:

http://www.photoshopessentials.com/essentials/rgb/



SuperSat now provides 2 types of channels; RGB and HUE.


HUE uses a polar coordinate system and is conveniently expressed in degrees
but is really a linear measurement. LUMINANCE and SATURATION provide the
other metrics for calculating a color point using the 6 HUE channels which
are really 6 hexaconic sections.

http://en.wikipedia.org/wiki/Hue

HUE and TONE mean the same thing. In paint color, a primary color wheel can
express hue (tone) in12 channels in which case a 12 sided polycone with hue
channels of 3 primary colors of RGB, 3 secondary colors of YCM, and six
intermediate tertiary colors; 12 channels would express hue in 30 degree
segments rather than the 60 degree segments in the 6 HLS channels, or the
120 degree segments in the RGB channels. The measurement is the same idea,
the channels are smaller:

http://www.color-wheel-artist.com/hue.html

My Hue Channel Frequency Calculations and Color Channel Frequency
Calculations for a 24 bit color are based on Frank Preucil's "Color Circle"
Polar Plot:

Please send me private mail if you want the C code for calculating 6 - HUE
channels and 3 - RGB channels. I may also have a calculater for 12 sided
polyconic 12 - TONE channels written by then.

Throughout my testimg the calculation itself showed no error. However a
computational error occurs if an implementation uses a single precision
floating point storage class in the kernel instead of a double precision
storage class, as follows:

x---x

IEEE 754 single-precision binary floating-point format: binary32

Red Hue Bucket = 2796160 possible colors
Yellow Hue Bucket = 2796160 possible colors
Green Hue Bucket = 2796584 possible colors
Cyan Hue Bucket = 2795736 possible colors
Blue Hue Bucket = 2796160 possible colors
Magenta Hue Bucket = 2796160 possible colors

Red Color Bucket = 5592320 possible colors
Green Color Bucket = 5592320 possible colors
Blue Color Bucket = 5592320 possible colors

GreyScale Count (Black, White, and Shades of Grey) = 256

The error between the colors grouped to the GREEN and CYAN is caused by
pecision loss in values coming close to the limits of the single precision
storage class.

x---x

IEEE 754 double-precision binary floating-point format: binary64

Red Hue Bucket = 2796160 possible colors
Yellow Hue Bucket = 2796160 possible colors
Green Hue Bucket = 2796160 possible colors
Cyan Hue Bucket = 2796160 possible colors
Blue Hue Bucket = 2796160 possible colors
Magenta Hue Bucket = 2796160 possible colors

Red Color Bucket = 5592320 possible colors
Green Color Bucket = 5592320 possible colors
Blue Color Bucket = 5592320 possible colors

GreyScale Count (Black, White, and Shades of Grey) = 256

x---x

>which I discovered doing the implementation of hue in SuperSat's Hue

>Channel algorithms...

Correction (sort of): I probably did not discover this computational error
on behalf of the entire planet; only for myself. I also did not discover the
limit of single precion floating point storage class. Like Latin the limit
is fixed.

I discovered the limit of double precision when I was an adult student doing
a strength of materials formulae assignment. My instructor used a pocket
calculator to develop the answers. I did the assignmnet on paper and made
each calculation longhand and in analog.

For every "wrong" answer I proved his calculator "wrong" and got 100% on the
assignment. However he still gave the other students whose wrong answers
matched his wrong answers 100%.

The HLS color model is like that too. So if you use the Polar Plot don't use
floats, use doubles, or you could end-up with the computationally right
wrong answers when the HUE degree calculation in the GREEN CYAN area
reaches the storage class limit and loses precision (or signs itself).

As an interesting aside on HUE degrees, the Window Color Picker uses a Hue
Scale of 0-239 which actually represents increments of 1.5 degrees. Therefor
it is not possible to adjust hue using this to the same accuracy as in a
program that uses 1 degree increments. Whether this matters is much like the
rest of this HLS business.

With a limit of 4096 possible colors on the SHR display, and its other
constraints, and an input of 16.7 million possible colors, results will
vary.

Bill

[Bill Buckels]

"STYNX" <Jonas.Gr...@gmx.de> wrote:
>Bill, you give me too much credit. I am happy to have helped you to get
>where you want to go, but my part is small compared to your work. I think
>that the biggest 'breakthrough' i had was to use ImageMagick for the actual
>image processing. This tool features a multi pass posterization-process
>that is art in itself. Im not really happy with my first step of
>line-selection for each palette. The reduction of the lines into a single
>value for comparison is only based on (median of all pixels in the line
>[r+g+b/3] ) and that is not very optimal.

Whatever the median cut that you use, this is more than I can find has ever
been done for Apple IIgs graphics using modern formalized quantization and
colorspace as a solution.

The posterization loop that you use levers Imagemagick, but like Runge-Kutta
methodology in differential equasions (i.e. Riccardo Grecco's work including
in Aztec C65), your implementation using an iterative process is beautiful
art to me.

In 1977 in Mastery of Engineering, columnist and engineer, Sid Love, wrote
an article called Design Through Timely Iteration (IIRC).

The iteration involves feedback loopbacks. Runge-Kutta is more like a binary
split like the logic we use to traverse a Btree or to split indices in a
data base, or to group colors together using thresholds like in the old
BMP2SHR. I am not certain what colorspace techniques Imagemagick uses for
posterization but they are artful. I agree. More than a simple color cube I
bet.

>But it was easy and gave relatively good results in a short amount of time.
>As stated, the real Magic is in the tool i used. I just built an interface
>for it.

Take the credit for an artful interface. It is creatively done.

>http://forum.classic-computing.de/index.php?page=Thread&threadID=5989
(the link is to a german forum, just look at the images ;-)

Where's the rest of them Jonas? I hope you decide to put them online for
viewing or on disks and make them available. Pure Art!

I'll eventually get a packbytes to you and include it in BMP2SHR so PNT
files can be created, as well as PIC files. Andy put the algorithm up years
ago when he did his tutorial on Genie, but all this takes time:) (Andy
didn't actually put all the code there, but it is trivial to implement. It's
really only a matter of cutting and pasting my other Aztec C stuff together
in reverse order. Some additional rules apply like the bug in the GS Toolbox
unpackbytes, but all this is well documented like Latin thanks to the folks
in csa2).

Bill