GitLab

Detail:
  These 2 specimens are in no way unique.
Admin:
  Not tagged.

Detail:
  Using the IJG8d code for these disc based utilities gains all of the more recent JPEG extensions including arithmetic coding, when ChangeFSI falls back to using djpeg if the SpriteExtend based decoder can't cope.
  Makefile and jconfig.h updated to build on RISC OS.
Admin:
  Submission for the JPEG bounty.

Version 1.57. Tagged as 'ChangeFSI-1_57'

Detail:
  This is a clean import of the reference code from JPEG 8d. One of the terms of use is to be able to show the changes made to the reference copy, so this commit serves as that point.
Admin:
  Tagged as ChangeFSI-Import-IJG8d
  Doesn't build.

Admin:
  Not tagged.

While investigating SprExtend-1_69, tidied up JPEGprint a bit.
Binary unchanged, not tagged.

Sprite type 16 is now accepted as an input format, by defining the appropriate 4:4:4 colour lookup tables.
Type 15 class RGB is handled too with 1/2/4/8/12/15/16/32bpp sprites with and without RGB/BGR reversal.
Other changes:
Tighten up the check for BTPC files, it turns out BTPC 5 also exists but has an incompatible format, so rather than trying to decode them and fail, fail early.
Mention the return code in Documents/CmdBasUse.
Change real variable 'rgb' to integer since it's only holding a flag.

Tested with a variety of special sprites, and a BTPC 5 file.

Version 1.56. Tagged as 'ChangeFSI-1_56'

Sprite type 10 is now accepted as an input format, by defining the appropriate 5:6:5 colour lookup tables.
Sprites with wide masks (8b alpha channels) are now also accepted, though like binary masks the mask is simply ignored. Previously these fell into a signed < 256 trap and were being mistaken for numbered modes which the OS then choked on.
When showing the mode number in the "About this image" dialogue the number is now given in hex if it's not a numbered mode (0-255), this is fractionally more useful than decimal.
Enlarged the "About this image" display fields per the Style Guide.
Corrected the comments in the colour mapping code (lines 6551-6552, 7043-7044).

Version 1.55. Tagged as 'ChangeFSI-1_55'

When the output sprite is calculated to be too big to fit in the upper limit of dynamic area size, ChangeFSI would attempt to create the output to disc in smaller chunks. However, the size required by the sprite header was not accounted for, eg. a 5000x4000 32bpp image would come out as 80000000 exactly.
Fix this by flushing the sprite header (and palette) before spooling out the image.
Tested with a nobbled dynamic area size of 128k, used 8bpp 2000x1000 sprite as test and processed this to
  S32,90,90
  S16,90,90
  28d
  28
  27
to exercise true colour, 256 palette, and bpp < 8.
Note, the desktop front end isn't helped by this as it requires the image to all be in memory at once for the display step, but the CLI version can now output practically unlimited sprite files.

Deleted call to PROCflushoutput in the JPEG/JPEGMONO code path, since addr% is never incremented it never gets called
and the file that is being written to in o% is set type to FF9 at the end anyway. Tested with
  JPEG75
  JPEGMONO75

Made Wimp version check consistent with 2 other occurences elsewhere in the source for the same template-related feature.

Version 1.54. Tagged as 'ChangeFSI-1_54'

ChangeFSI's slightly lapse check of >= 8bpp header vetting for PCX meant it would try to load such files and fail with an EOF error.
* Change header parsing to correctly deduce a 24 or 32bpp PCX is being handled, select the appropriate decoder
* Add a sample 4 plane 8 bit PCX to the tests directory, created with ImageMagick
* Docs updated
Note that is seems highly unlikely from inspection of the code that 5/6/7bpp PCX files will come out the right colour since the PCX file format header only has space for 16 palette entries but ChangeFSI will continue reading off the end of the table into the start of the image data. However, no examples of 5/6/7bpp images could be found in the wild, so let sleeping dogs lie.

Version 1.53. Tagged as 'ChangeFSI-1_53'

Not tagged

Code is loaded in two places using OS_GBPB to help ChangeFSI out, but is then called without flushing the instruction cache, nor has it since StrongARM days.
This seemed to cause a problem where reprocessing a JPEG a second time caused random aborts on an ARMiniX (Cortex-A9).
Thanks to Bob Latham for helping test this change remotely.

Version 1.52. Tagged as 'ChangeFSI-1_52'

Windows 3 style ICO and CUR files are internally very similar to BMP files, so much of the hard work already existed.
As with other multi-frame formats (GIF and Sprite for example) ChangeFSI simply picks the first one it finds in a file, even if there are several offered.
In modifying the BMP importer, ChangeFSI no longer reads off the end of the palette for bitmaps which don't use all 2^bpp entries.
Tested with a variety of icons and bitmaps up to the maximum size allowed 256x256 pixels.
Documents updated.

Version 1.51. Tagged as 'ChangeFSI-1_51'

Fix import of OS/2 BMP files

WinCE is documented on MSDN as creating and displaying 2bpp bitmaps, so we might as well support them.
Also, MSDN states that when the BITMAPINFOHEADER is in use the height is a signed number, with -ve values meaning the scan order is reversed (top down).

Relatedly, the width and height in an OS/2 bitmap are only 16 (unsigned) bits, whereas ChangeFSI was reading in 32 bit values leading to grossly wrong dimensions, plus it uses packed 24 bit palette values not 32 bit like Windows.
Docs updated and info fields made more verbose to report whether it's a Windows or OS/2 BMP.

Now successfully opens all the 'good' bitmaps in BMP Suite http://entropymine.com/jason/bmpsuite/

Version 1.50. Tagged as 'ChangeFSI-1_50'

Fix RLE decompression of 15bpp targa images

In spec 1.0 RLE compressed data was allowed to span multiple scan lines, whereas spec 2.0 said the exact opposite (so that fast lookup tables into scan lines became possible). However, ChangeFSI could only handle RLE decompression where the data exactly decompressed to one line long, otherwise getting stuck in a REPEAT UNTIL loop until overrunning the end of the line buffer.
A new PROCtarga (since it's common to all 5 possible pixel depths) loads lines, and optionally suspends decompression once one line has been fetched to allow continuation on the next line.

A truncating divide when calculating 'step24' meant that 15bpp TGA's only got allocated half the memory they needed, leading to a data abort. Now, 8/15/16/24/32bpp get the right allocation.
Docs updated.

Version 1.49. Not tagged

The targa (TGA) reader had an oddly empty "ELSE" clause in the code that reads palette entries, so while 24b entries worked the 16b and 32b variants didn't. This would typically show an all black image (all palette entries uninitialised).
Tested with some sample 16b images, 32b ones should be right by inspection.

Version 1.49. Tagged as 'ChangeFSI-1_49'

Fix support for 24bpp RLE compressed Sun raster files

The former is merely 24b data on 32b boundaries (the format doesn't support transparency), so this need not be rejected by ChangeFSI.
The latter caused a data abort because the decoder assumed all RLE data could be handled by FN1100 but in the 24bpp case there's 3 times more data than expected so you fall off the end of memory.
Test image for type 3 Sun rasters produced as these seem hard to find.
Now correctly decodes all the sample images at
  http://samples.libav.org/image-samples/sunrast/
Docs updated.

Version 1.48. Tagged as 'ChangeFSI-1_48'

Some of the dialogues used a mixture of 48 & 52 OS unit boxes, changed to 52 OS units to match !ResEd defaults. Nudged some text around where display in the system font meant it overlapped.

Version 1.47. Tagged as 'ChangeFSI-1_47'

PNG spec 1.2, section 4.3, turns out tIME iTXt tEXt zTXt have no ordering constraints. Images with these after the IDATs but before IEND were being rejected, plus it's possible to encounter private ancilliary chunks - so it's safest just to let them all through.
Unexpected critical chunks are now explicitly faulted.

Version 1.46. Tagged as 'ChangeFSI-1_46'

Having selected JPEG output format, you'd get an error clicking on one of the radio icons on the sprite output format window.
Look for BZERO and BSCALE in FITS astronomical image files, rather than subtracting a hardwired 0x8000 - this tended to result in any 16bpp images coming out solid green.
Mirror the FITS image output in the X axis so they're the right way up.

Version 1.45. Tagged as 'ChangeFSI-1_45'

From reading WAP WAE 1.1 spec, tested with some sample images from the internet.
Test image added to 'tests' directory for reference.

Version 1.44. Tagged as 'ChangeFSI-1_44'

Also increased the minimum work area of the uutput window so the up/down adjusters don't get squashed with very small images.

Tested with 174 test PNGs from the PNG test suite.

Version 1.43. Tagged as 'ChangeFSI-1_43'

With small image files ChangeFSI would often report 'Outside file' as its detection code tried to read from around offset 512 within the file - often longer than the image itself. The extent is now checked before attempting to look for signatures that far in.
Other minor changes:
* Removed the need to pass a block of scratch memory to PROCcachesize
* Command line use is in 'CmdBasUse' not 'FSIinfo' within the docs
* Moved flag 666 image parser up into numerical order
* Don't pass an argument to SWI Hourglass_On
* Inline FNfits
* Make the uniform palette function more general rather than hardwired for 256 entries
Tested briefly, still works.

Version 1.42. Tagged as 'ChangeFSI-1_42'

In mappix (2 occurrences) for 48 bit data when step24=6 ChangeFSI relied on the unaligned load rotate, this is now split out for machines that can't do that.
Don't bother looking for jcompmod in ChangeFSI$Dir - it's never been supplied there.
Line 6934: fix stack imbalance.
Rehomed a few comments with the lines to which they refer, added a few comments.
Built, but not tested.

Version 1.41. Tagged as 'ChangeFSI-1_41'

Not all of the formats listed and supported were in the tables.

Detail:
  source/ChangeFSI - Fixed a couple of issues that could prevent low colour (i.e. <=256) output from working in some situations:
  - Fixed bug in default palette reading code that would cause it to try and allocate silly amounts of memory depending on the current mode (e.g. FNdim of 0 bytes if loading 16 colour palette while in 32bpp mode)
  - Reworked colour conversion code so that the pixel index and image base pointer are in two seperate registers instead of being in one. The old code had a habit of failing with an "image too complex" error when producing <256 colour output, because (base%<<(3-dest_log2bpp)) could easily overflow a 32bit int, especially when you consider that a dynamic area is used to store the target image.
Admin:
  Tested on RISC OS 5.21 Iyonix, converting a test image to all the different output colour depths & "special" modes.


Version 1.40. Tagged as 'ChangeFSI-1_40'

ChangeFSI previously only supported global colour tables, but will now look at the local colour table bit too.
Additionally, the info report was looking at the wrong bitfield when describing the log2bpp - always showing 8 (because it was showing the colour table size).

Version 1.39. Tagged as 'ChangeFSI-1_39'

Version 1.38. Tagged as 'ChangeFSI-1_38'

Also
 * Trim out some redundant statements in FNdeducemode which look to have been used when JPEG was in the sprite output dialogue
 * Likewise, fix keyboard navigation in sprite output dialogue to not try to go via the (non existant) JPEG quality writeable
 * Add 'smoothing' to keyboard navigable writeables in processing dialogue
 * Bump up version number reported in Wimp_Initialise to allow interactive help messages on menus to be passed
 * Uncapitalise iconbar menu second words

Version 1.37. Tagged as 'ChangeFSI-1_37'

Version 1.36. Tagged as 'ChangeFSI-1_36'

For earlier history look in the attic at 'ChangeFSI,ffb'.
Makefile adjusted to use StdTools where possible.

Version 1.35. Tagged as 'ChangeFSI-1_35'

* Now does an OS_SynchroniseCodeAreas before jumping to Shell_Job (and back again)
* Removed the attempted Arthur 1.20 support - it was attempting to support this using the 'X' form of XOS_ChangeEnvironment, except that that SWI name wouldn't lookup on Arthur. Doh!

Version 1.34. Tagged as 'ChangeFSI-1_34'

* Working example of using ChangeFSI as a library added
* Note about not freeing memory when worklimit%=0 added to docs
Retagged as ChangeFSI-1_33.

Quite hard to guess what to do when the REM's have been crunched out of the binary otherwise.
Retagged as ChangeFSI-1_33.

* Function 'newropal' was treating palette entries as &00BBGGRR when they are stored as &BBGGRR00, leading to generally wrong colours all round.
* Also, 256 entry palettes were not distinguished from 64 entry palettes, so files from Paint (which seems to prefer 64 entry ones) were generally black due to reading of the end of the palette.
* Added text to the info string stating if the input sprite contained a palette.
* Fixed template buffer overrun when filename is truncated to 12 letters (to formulate a sprite name), the template only reserved 12 letters and hence use of '$' operater in BASIC overran and messed up the border validation.
Tested with a number of 180dpi 'new' format sprites in 8bpp and 4bpp with and without palettes.

Version 1.33. Tagged as 'ChangeFSI-1_33'

During 32 bitting some MRS/MSRs were added, but these don't assemble with the BASIC that is implied by the RMEnsure in !Run.
Changed 25 occurrences to use a macro instead.
Removed attribution from !Run/!Boot copied to the user.
Some dead definitions removed from the makefile.

Version 1.32. Tagged as 'ChangeFSI-1_32'

Version 1.31. Tagged as 'ChangeFSI-1_31'

Before, the candidate JPEG file was prescanned and a decision made as to whether that was too hard for CFSIjpeg to do or not. This lead to duplicated tests when (a little later on at 'WHEN 3700:') the file is prescanned anyway - plus this implictly encoded the capabilities of CFSIjpeg into the BASIC code.
Now, the CFSIjpeg binary is loaded at the first detection of a JPEG file and the scan done up front using its built in routine.
This isn't a performance penalty since the area (jpeg%) was never freed anyway so there is now no need to load it later, which has the additional benefit that it is now possible to detect CFSIjpeg missing and fall back to djpeg rather than reporting an error.
Fixed an 'end of file' error spotted in testing when djpeg fails to produce an output it does actually create a scrap file of zero length which is now checked for too.

Version 1.30. Tagged as 'ChangeFSI-1_30'

Version 1.29. Tagged as 'ChangeFSI-1_29'

Detail:
  Main ChangeFSI program changed to assemble new instructions on ROL OS
  versions without "No such mnemonic" error. Also changed to handle
  _Version: token in messages file.

  Added "stripdepnd Makefile" to !MkClean.

  Makefile locks destination !Sprites and !Sprites22 files, because
  everything else is being locked.

  Makefile altered to use new centalised awkscript to keep version numbers
  updated. (Note that ChangeFSI has a slightly odd makefile, so this
  shouldn't be used as an example of how to modify Makefiles to use the new
  awk version script.)

  Window menu fixed to be style guide compliant.
Admin:
  Requires Library 1.32
  Tested on RiscPC RO402
Notes:
  Changes by James Lampard.

Version 1.28. Tagged as 'ChangeFSI-1_28'