GitLab

Detail:
  * Remove support for pre 'NewLook' 2D templates
  * Correct interactive help messages for square/rectangular sprite output (broken in ChangeFSI-1_63)
  * Distinguish between 4k/32k/64k modes when the output mode is the current mode

Version 1.64. Tagged as 'ChangeFSI-1_64'

Detail:
  The front end adds a new 'PNG output' menu, taking its cues from the Sprite output menu, minus those options that don't make sense for Portable Network Graphics.
  Internally, the image is processed as though a sprite (this is needed because the output window is rendered by the OS and the OS has no built in PNG support) then converted to PNG on the fly during saving.
  The choices file is extended to save/recall the output window settings as appropriate.
Admin:
  Submission for PNG bounty.

Update ChangeFSI's 16bpp output code paths to convert to 4k and 64k sprites (as well as the pre existing 32k RISC OS 3.5 style).
Also, simplify the sprite output dialogue a little by grouping the colours together and the DPI as an option, to halve the number of radio buttons.
If ChangeFSI is run on a kernel without 4k/64k support, those two depths are greyed out in the GUI (since after processing the desktop frontend expects to SpriteOp plot them), however at the command line the 2 new depths are always available (as S12 and S16).

ChangeFSI: Add the conversion code
DesktopFE: Rework dialogue with fewer radio icons, add fading logic

Version 1.63. Tagged as 'ChangeFSI-1_63'

Output formats were only partially described, and supported
* Mention IRLAM output format switch in the CmdBasUse docs, add an example to the tests
* Explain what 'p15' is in CmdBasUse (was only explained in the input formats docs)
* Prefer S15 to S16

Delete support for C15 output. This appears to have been experimental as the resulting output had an embedded comment saying YUV but the data that followed was identical to a P15 RGB image. Also, ChangeFSI refused to load the C15 image it just wrote.
Delete support for S24 output switch. This was an undocumented alias for S32.
Add S15 as a possible output mode and prefer its use for 32k sprites - freeing up S16 for future 64k sprite support (and, logically S12 for 4k sprites).

Retagged as 'ChangeFSI-1_62'

Mention how to release the sprite area when called as a library.
Use TRUE/FALSE for things that are notionally documented as booleans.

Version 1.62. Tagged as 'ChangeFSI-1_62'

Detail:
  Compuserve->CompuServe
Admin:
  From User Guide feedback.

Version 1.61. Tagged as 'ChangeFSI-1_61'

Merged from IJG release 8d1.

Version 1.60. Tagged as 'ChangeFSI-1_60'

source/ChangeFSI: After rounding up the scaled output size, recalculate the div/mul factors so they produce a whole number of pixels instead of falling off the end of the input array and mixing in black.
source/DesktopFE: Remove dead variable "safe%" and change tofitx/tofity to integers.
Minor clarification in CmdBasUse documentation.

Tested with a 100x100 green sprite, scaled by 5:3/5:3 and 3:7/3:7. Fixes ticket #236.

Version 1.59. Tagged as 'ChangeFSI-1_59'

Move 1500 lines of the desktop front end into 'DesktopFE', to help see the distinction.

Detail:
  For fast JPEG decoding, simply call SpriteExtend's JPEG SWIs directly, rather than carry a cutdown version of the core of SpriteExtend.
  The !Run file RMEnsures check for UtilityModule 3.60, so there's always some version of JPEG SWIs available to call. If not, ChangeFSI falls back to decoding JPEGs via PBM files using its disc based copy of djpeg.
Admin:
  Submission for the JPEG bounty.

Version 1.58. Tagged as 'ChangeFSI-1_58'

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'