-------------------- AmigaOS 3.5/3.9 project -------------------------

picture.datatype 43.21 (24.02.1997)

- No longer blows up in environments that offer too few stack
  space.

- Uses BestCModeIDTagList() to find the best matching image
  resolution.

picture.datatype 43.22 (01.03.1997)

- Cleaned up the library initialization code to avoid
  race conditions.

- The IFF-ILBM picture storage code could run forever for very
  narrow pictures, i.e. those smaller than 16 pixels per line.

- Rewrote and simplified the IFF-ILBM picture storage code,
  which due to its legacy was overly convoluted. It was not
  reentrant either (it now is).

picture.datatype 43.23 (11.04.1997)

- Multiview would not display some pictures properly on a
  custom screen. While I fixed this problem it has created
  a new one with Multiview and the P96 software. We'll
  see about that.

- Simplified and cleaned up the picture layout (remapping,
  dithering, etc.) code.

- Removed more confusing and irrelevant dead old code.

- Cleaned up the class library core code again.

picture.datatype 43.24 (19.04.1997)

- Pictures that do not need to be remapped in order to
  display properly on a screen no longer remain blank.
  This fixes a bug introduced in 43.22.

picture.datatype 43.25 (08.06.1997)

- Rewrote the library initialization code (again).

picture.datatype 43.26 (29.06.1997)

- The DTM_WRITEPIXELARRAY and DTM_READPIXELARRAY methods
  did not support the RGBA and ARGB pixel formats
  properly. Fixed.

picture.datatype 43.31 (22.2.1998)

- Major source cleanup and numerous bug fixes. Too
  many to mention here...

picture.datatype 43.32 (24.2.1998)

- Removed more unused variables from the class data area.

- True colour pictures now receive their default colour
  map during the bitmap data allocation process rather
  than during remapping

- Better consistency checking in the V43 read/write
  pixel array methods.

picture.datatype 43.33 (5.3.1998)

- The DTM_FRAMEBOX method did not return a non-zero result
  upon success.

- The V43 picture data setup now properly fills in its
  frame info data.

- In the routine that creates bitmap data from chunky image
  data, a test for CyberGraphX-compatible bitmaps was wired
  the wrong way; this could produce empty bitmaps.

picture.datatype 43.34 (28.5.1998)

- The V43 chunky picture data is now stored in a memory
  buffer which is cleared upon allocation. This means, if
  image data is omitted from the buffer, no random memory
  contents will show in the "gaps" [Gunther Nikl].

picture.datatype 43.35 (30.8.1998)

- Corrected a problem in the mask plane generation code
  which appears to show up only with RTG systems. I
  don't know whether this is a general problem since the
  code was correct when I wrote it and still is with
  the small change I made. Nevertheless the problem
  should be gone now [Allan Odgaard].

picture.datatype 43.36 (3.10.1998)

- As it turns out, the V43 pixel read method did not return
  any data unless the picture storage format (number of
  bytes per pixels) would match the pixel format requested
  in the read message. I enhanced the read code to perform
  "colour expansion" on the source data, i.e. you will
  always be able to read truecolour picture from an image.
  However, you may not read chunky pixel data with 256
  colours from a truecolour picture. I also fixed a bug
  in the chunky pixel read code which would have caused the
  picture data read to consist of a single colour only.
  Note that the V43 read method requires that the original
  picture data is stored in chunky format.

picture.datatype 43.37 (18.11.1998)

- For completeness, the V43 read/write methods now permit
  reading and writing of chunky data. Pictures in hold and
  modify format now read as true colour data through the
  V43 interface. To read properly, however, the data read
  must start at the leftmost point of the picture.

picture.datatype 43.38 (27.11.1998)

- In the V43 method interface, the HAM8 conversion code was
  using the wrong HAM modifier values.

picture.datatype 43.39 (12.12.1998)

- Even more wrong HAM modifier values corrected.

picture.datatype 43.40 (19.12.1998)

- If a picture is no longer in its original format (e.g.
  true colour), the datatype will no longer refuse to
  store its on-screen image in a file or the clipboard.

- When converting chunky pixel data into a bitmap
  the datatype no longer enforces conversion into
  a CyberGraphX native bitmap if a plain and
  regular bitmap (with 1..7 bit planes) would be
  perfectly sufficient [Stephan Rupprecht]. This
  fixes IBrowse, whose navigation buttons can
  otherwise get trashed.

picture.datatype 43.41 (20.12.1998)

- More cleanup work in the code that saves pictures
  to files or to the clipboard. Among other things,
  its memory requirements aren't quite that high
  any more.

picture.datatype 43.42 (10.1.1999)

- Even more cleanup work.

picture.datatype 43.43 (22.1.1999)

- Restricted CyberGraphX bitmap creation calls to
  15 bit and greater.

picture.datatype 43.44 (24.1.1999)

- Cleaned out some more dead and unused code and data
  structures.

- Unified all planar to chunky and chunky to planar
  conversion code.

- The datatype now defaults to destination mode V43,
  which it implicitly always assumed to be set.

- The layout code now adapts HAM and extra
  halfbrite picture data for display on a palette
  mapped screen if this is necessary.

- The V43 read pixel interface now properly returns
  extra halfbrite and HAM data, regardless of where
  the reads start horizontally.

- When laying out a picture for display on a truecolour
  or hicolour screen, the layout process now turns
  the picture into truecolour format.

picture.datatype 43.45 (25.1.1999)

- When laying out the picture for display on a hicolour
  screen, the data will be dithered. There is no longer
  a user configurable option to influence this.

- Removed support for the PromoteHAM environment
  variable.

- Cleaned up the layout and storage routines which now
  both propagate error codes properly.

picture.datatype 43.46 (26.1.1999)

- Corrected the use of the PDTA_Allocated attribute
  in the OM_GET method. It used to return a pointer to memory
  space, which is clearly not what it should do (according
  to the documentation). Now it returns the same as the
  PDTA_NumAlloc attribute.

- The code now watches and handles pen allocation failures
  gracefully instead of ignoring them altogether. There also
  is better error handling code in the dithering routines now.

- Rewrote the task stack swapping code.

picture.datatype 43.47 (26.1.1999)

- Changed the way picture.datatype treats data passed to it
  via the subclass. This makes is possible to restart the
  layout process, provided picture.datatype has not yet
  discarded the source picture data. Note that from now on
  the V43 source mode implicitely sets the PDTA_FreeSourceBitMap
  attribute to TRUE.

- The DTM_REMOVEDTOBJECT and DTM_RELEASEDRAWINFO methods now
  cause the object layout process to be restarted the next
  time it is invoked. Note that the result of the previous
  layout process will stay valid until you restart the
  process.

- The DTM_OBTAINDRAWINFO now returns NULL if the picture
  object has not yet passed the layout process.

- The dithering technique picture.datatype uses for
  palette mapped pictures should now run faster and yield
  better picture quality.

picture.datatype 43.48 (30.1.1999)

- Further cleanup work and data structure changes.

- Further changes to make it possible to reverse the
  results of the layout process.

picture.datatype 43.49 (30.1.1999)

- Implemented Roland Mainz' DTM_OBTAINDRAWINFO method.
  Previously, you had layout the picture object before
  you could successfully invoke this method.

- Reorganized the entire source code, putting the pieces
  back together I came up with when I took the initial
  source code structure apart.

picture.datatype 43.50 (31.1.1999)

- V43 source mode no longer implies setting
  PDTA_FreeSourceBitMap to TRUE.

- The DTM_ASYNCLAYOUT method now responds to the ^C
  signal. In other words, it can be stopped while it
  is in progress.

- Fixed a bug in the OM_SET method which could cause
  chunky image data not to reach the layout stage.
  Its colour tables would not always get allocated.

- The DTM_OBTAINDRAWINFO method now always restarts
  the layout process if the screen to layout to
  differs from the last one used.

- Some palette mapped pictures did not get a transparent
  mask created. Fixed.

- Without CyberGraphX around to translate true colour
  data into well-formed bitmaps, the layout code would
  fail to create palette mapped image data and often
  even missed the chance to use as many colours as the
  display would permit. It now performs much smarter
  in this respect.

picture.datatype 43.51 (7.2.1999)

- Further cleanup work and code polishing.

- The layout process could try to return the source
  bitmap "as is" if there was no further need to remap
  the picture. In some cases this would return NULL
  bitmap pointers due to the fact that chunky V43
  mode picture data had been supplied but no source
  bitmap. Fixed.

picture.datatype 43.52 (18.2.1999)

- The set method did not properly set up the display
  properties for every mode ID passed in.

- Simplified the code that selects the display mode
  properties we don't want when looking for a new
  mode.

- Removed a special case from the display mode
  setup code which was actually taken care of
  already by the main branch of the code.

- Finally found out that DI_AVAIL_NOTWITHGENLOCK actually
  means "this mode is not available because there is a
  genlock connected" rather than "this mode will not
  be available if somebody connects a genlock". This
  caused changes in the mode selection logic.

picture.datatype 43.53 (21.2.1999)

- The mode selection code now handles a special case:
  if a HAM8 mode picture is to be assigned a new display mode,
  the code now checks if there is a HAM8 display mode
  available and not just merely a HAM6 mode.

- The layout process is now invoked every time the
  layout method is entered. No old data is being
  cached.

picture.datatype 43.54 (15.3.1999)

- The picture storage code now uses the "colour map is really
  eight bits wide" flag.

picture.datatype 44.1 (27.3.1999)

- Fixed a bug in the ByteRun1 compressor that went unnoticed
  for the previous 14 years.

picture.datatype 44.2 (11.4.1999)

- The DTM_PRINT method now allows for bitmaps to be printed
  that don't have a colour map attached. This is supported
  only for non-palette mapped pictures (true colour and its
  like) with printer.device V44. I have also added better
  error reporting. The method now fills in the DTA_ErrorLevel
  and DTA_ErrorNumber attributes as passed to the routine
  with the dtPrint message.

picture.datatype 44.3 (20.4.1999)

- Introduced the PDTA_WhichPicture and PDTA_GetNumPictures tags.

picture.datatype 44.4 (22.4.1999)

- Replaced the few environment variable options with real
  control tags.

picture.datatype 44.5 (1.6.1999)

- The V43 pixel read method no longer performs an implicit
  colour space conversion when returning HAM/EHB data for
  8 bytes per output pixel.

picture.datatype 44.6 (6.6.1999)

- The OM_SET method now always sets the error level/error number
  values upon completion of the routine. This happens regardless
  of whether the routine completed successfully or failed. The
  same is done for the DTM_PRINT method.

picture.datatype 44.7 (4.7.1999)

- Clamping code was missing in all the Floyd-Steinberg dithering
  routines, causing some pictures to look "overexposed". Fixed.

picture.datatype 44.8 (19.7.1999)

- Changed the default number of pens to use for dithering to
  a maximum of 125. Default pen allocation precision is now
  at PRECISION_IMAGE.

picture.datatype 44.9 (8.8.1999)

- Now supports printing chunky data via the new PRD_DUMPRPORTTAGS
  printer.device command.

picture.datatype 44.10 (9.8.1999)

- When switching the datatype into V43 mode with eight bits per
  pixel to be used for the picture, the datatype now starts by
  allocating 256 colours for it. The client can of course override
  this setup.

- Chunky greyscale data now affects the default picture colour
  palette. When the first line of greyscale data is written to
  the picture buffer, the datatype will reset the colour palette
  to 256 shades of grey.

picture.datatype 44.11 (17.8.1999)

- PDTM_READPIXELARRAY method was completely and utterly broken.
  Fixed.

picture.datatype 44.12 (21.8.1999)

- One of the reasons why the PDTM_READPIXELARRAY method did not
  work was that the wrong variable was used to store pixel data
  at a specific memory location. As it turned out, the same
  wrong variable error was also present for the planar conversion
  code. Fixed.

- Simplified the PDTM_READPIXELARRAY planar case a bit.

picture.datatype 44.13 (31.8.1999)

- Palette size changes now preserve colours.

picture.datatype 44.14 (7.9.1999)

- Simplified the dithering setup code a bit after discovering that
  "massaging" the first line of data to be used for dithering had
  no impact whatsoever.

- Took out the special "simpler" dithering case used for improving
  the appearance of 24 image data on a 15/16 bit display since it
  did not improve performance as expected.

picture.datatype 44.15 (11.9.1999)

- Added a new tag PDTA_AllocatedPens to obtain a pointer to the
  colour remapping table.

picture.datatype 44.16 (12.9.1999)

- Rewrote the ordered dithering code from scratch.

picture.datatype 44.17 (23.9.1999)

- When printing image data, the picture will be printed using the
  original mode ID and colour palette active before the layout
  process was executed. This fixes HAM picture printing and
  printing of palette mapped images that appeared on a true
  colour screen.

picture.datatype 44.18 (1.10.1999)

- The same problem that caused the picture palette to be trashed
  while printing also affected copying/saving image data. Fixed.

picture.datatype 44.19 (1.10.1999)

- When reading grey scale data from a palette mapped picture with
  the PDTM_READPIXELARRAY method, picture.datatype now performs
  a colour conversion to yield real grey scale data instead of
  returning the original data "as is".

picture.datatype 45.4 (18.10.00)

- changes done by H&P.

- Made a fat-binary for PPC-support.

picture.datatype 45.6 (24.10.00)

- Added new method PDTM_SCALE to scale the pixel data to a new
  size. PDTM_SCALE can only be called between OM_NEW and the first
  GM_LAYOUT.
  The new attribute PDTA_ScaleQuality can be set to 0 for bad quality 
  and high speed or any other value for good quality and low speed.

- Introduced the environment variable PICTUREDTNOPPC for test purposes.
  If it is set to 1, the PPC won't be used for any operation.

picture.datatype 45.7 (02.11.00)

- Again works, if cybergraphics.library is not available (lost in 45.4).

- The powerpc.library will now be opened just before the first ppc-code
  is called (i.e. no longer in LibOpen()). This became necessary, because 
  some subclasses open the picture.datatype within their LibInit()-
  function (i.e. in ramlib context). Opening the powerpc.library in ramlib
  context seems to be a bad idea, besides the stack topic.

picture.datatype 45.8 (20.04.2001)

- all changes were done by Stephan Rupprecht.

- remapping didn't work correctly for pictures using less colors than
  defined by their colormap.

- saving the selected part of a picture object didn't work because
  the wrong modulo was used when the imagedata didn't came from a
  bitmap.

- changed some SetSignal(0,0) to SetSignalPPC(0,0) because WarpUP allows
  to check for SIGBREAKF_CTRL_C via the mirror function (this is internally
  done by WarpUp by patching exec.library/Signal).

picture.datatype 45.9 (01.05.2001)

- dithering an image down to 8bit works faster on the PPC, now (less
  context-switches).

- remapping of palettemapped imagedata (<= 8bit) will be done by the PPC,
  if available.

- reintroduced the environment variable classes/datatypes/picture/DitherHiColour.
  If it is set to 0, it'll disable dithering of 24bit images on 15/16 bit screens.
 
- the memory for the imagedata was cleared via memset(), that was a bit slow...

- all memory that could be write-accessed by the ppc is now properly aligned
  to 32byte boundary.

picture.datatype 45.10 (28.06.2001)

- PDTA_DestMode defaults to PMODE_V42, now. This should fix problems with
  applications that can't handle non-planar/foreign bitmaps (eg FW97).
  Introduced the env variable "classes/datatypes/picture/ForceV43" for
  test purposes. If it is set to 1, PDTA_DestMode will default to PMODE_V43
  again.

picture.datatype 45.11 (??.07.2001)

- posted to the OS3.9 betalist by accident.

picture.datatype 45.12 (11.07.2001)

- recompiled the whole datatype this seems to fix Sinans problem of
  getting corrupted images.
  
- just for testing purpose the datatype has an internal list of all programs
  that support PMODE_V43 even though they don't request this mode
  (MultiView, IPrefs, AmigaGuide, WBStartup++).
  
picture.datatype 45.13 (28.08.2001)

- the env variable "classes/datatypes/picture/ForceV43" holds a list of
  all programs that should be forced to v43 mode, now. The new preferences
  editor should be used to change this variable.

picture.datatype 45.14 (17.02.2002)

- more v42 compatiblity: the bmh_Depth field of the bitmapheader
  structure is now limited to the maximum depth the selected
  destination mode supports (8 for v42 mode).

picture.datatype 45.15 (20.02.2002)

- temporary bitmaps for planar<->chunky are no longer allocated 
  with a depth greater 8 even when the friend bitmap has more
  than 8 bit. This and limiting the allocation depth of the 
  remapped bitmap to 8bit when modev42 is enabled, fixes the problem
  that the AmigaWriter about window contains just a black image when 
  cgx is installed and the image is remapped to a hi-/truecolor screen.

picture.datatype 45.16 (15.03.2002)

- the 45.14 fix could break the saving routine.

picture.datatype 45.17 (19.03.2002)

- the 45.14 fix could also break some subclasses of picture.datatype
  (namely ilbm.datatype v44.9). The bmh_Depth field is now changed
  to 8bit in PDTM_WRITEPIXELARRAY to workaround the problem (yes,
  the v42 API sucks;). Let's hope that this won't break anything
  else...

picture.datatype 45.18 (30.03.2002)

- fixed the corrupt background problem of ImageFX4: the datatype
  returned a non planar bitmap even when PMODE_V42 was requested.
  This didn't work well unless the FORCECHUNKY option of cgx was
  activated. This also seems to fix the Twist2 problem of crashing
  when not configured to v43 mode.

picture.datatype 45.19 (24.04.2002)

- the last fix introduced some enforcer hits because a NULL
  pointer check was missing.

picture.datatype 46.1 (28.9.2002)

- due to the legal state of the v45 sources, I had to take the
  44.19 sources and reimplement all changes done since v45. 
  This version is no mixed-binary (ppc/68k) for obvious reasons;)

-------------------- AmigaOS 3.1.4.(1) project -----------------------

picture.datatype 46.2 (19.11.2017)

- Added utility.library stub functions again.

- Aligned library bases to long-word boundaries.
- Minor rework of some files to make it compilable with SAS again.
- Replaced the blue noise dithering by a somewhat faster algorithm
  with less divisions in it.

picture.datatype 46.3 (22.11.2017)

- Removed the blue noise algorithm. Does not make any visible difference
  in quality and is just slow.
  
picture.datatype 46.4 (17.4.2018)

- In case pen allocations fail on palettized screens, the partially
  allocated pens are now released immediately.
  
picture.datatype 46.5 (17.5.2018)

- The picture datatype now attempts to lock semaphores first, and fails
  rendering in case any of the semaphores is not available. This should
  hopefully avoid deadlocks, though it may cause situations where no
  picture is rendered because the required lock is kept by another task.

- The draw method can now also be called if the rastport is not layered,
  it just does not clip then.

picture.datatype 46.6 (20.5.2018)

- Due to a misplaced bracket, the picture datatype did not release an
  essential lock, blocking all rendering after the first render
  instruction.

picture.datatype 46.7 (24.5.2018)

- Even though the datatype was compiled for the 68K, it required at
  least a 68020 and failed if none was there.

picture.datatype 46.8 (29.6.2018)

- The picture scaling algorithm could only upscale, but not downscale.
  Fixed.

- The minimum acceptable stack size is now 6K, and no longer 8K. Otherwise,
  every recursive call of the picture datatype into itself would allocate
  a new 8K stack by itself, which wastes a lot of memory.
  
picture.datatype 46.9 (4.7.2018)

- In case printing is aborted, the picture datatype attempted to send a
  reset sequence to the printer. This, however, does not do any good
  in case the printer is in the middle of a CSI sequence anyhow, and it
  does not any good in case the printer is off-line since it simply
  hangs the datatype. Hence, printing this sequence has been removed.

picture.datatype 46.10 (28.7.2018)

- The stack size check did not work reliable in case a CLI program
  swapped its stack itself.

picture.datatype 46.11 (10.8.2018)

- In case a target screen was given as reference, and a sparse color
  table to be used for rendering, the screen color table was carried
  over incorrectly, and hence target pens were selected incorrectly,
  resulting in a sub-optimal assignment of pens for the remapped
  picture.

picture.datatype 46.12 (25.8.2018)

- The interpretation of ENV:classes/datatypes/picture/forcev43 changed
  in the middle. It used to be a boolean yes/no variable, but it is now
  a list of programs to promote silently to the V43 syntax. As this
  could have created conflicts with left-over settings from older releases,
  a workaround was added to enforce the default promotion rules if the
  variable is "yes" or "no".
  
picture.datatype 46.13 (10.9.2018)

- Fixed another race condition in LibOpen.

-------------------------- AmigaOS 3.2 project -----------------------

picture.datatype 46.14

- In case the view mode selection and the number of colors was set in
  the wrong order, the histogram for remapping was not reallocated,
  though the number of colors stayed beyond the histogram size, causing
  a crash. Now, if the picture datatype has to fall back to a lower depth,
  the number of picture colors is not touched.

picture.datatype 47.1 (5.4.2020)

- Removed the now unused code from this project.

- The PDTA_Mask attribute now is writable for the benefit of
  ilbm.datatype.

picture.datatype 47.2 (12.5.2020)

- now uses Exec memory copy function for WritePixelArray and 
  ReadPixelArray instead of relying on the compiler runtime

picture.datatype 47.3 (14.5.2020)

- Pictures whose source comes in the form of chunky image data instead
  of a standard bitmap can now be scaled up to 65535 times their width
  and height, rather than only 255 times. [Backported from AOS4 V46.2]

- Interpolated upscaling would forget to fill the last few rows of the
  destination picture; now fixed. [Backported from AOS4 V46.2]

- Changing PDTA_NumColors from a non-zero value to a greater one would
  cause reads from unallocated memory, because too much color data was
  being copied internally. Now fixed. [Backported from V52.2]

- The palette allocated for a truecolor picture would always be of 224
  colors, even when a greater number of colors had been specified via
  PDTA_NumColors. This would later cause memory trashing by attempting
  to write color data past the end of the allocated space. Now fixed.
  [Backported from V53.5]

- Fixed the minimal palette initialization for a truecolor picture not
  having an own color table; the four mouse pointer colors were copied
  repeatedly until the end of the color table, and due to the above
  bug, the 32-bit color registers (CRegs/GRegs) could also get trashed
  as a result. [Backported from V53.5]

- The allocation of standard (planar) bitmaps was broken under P96 due
  to a difference in behavior between P96's CyberGraphX emulation and
  the original CyberGraphX. As a result, a hicolor or truecolor bitmap
  could be returned to the client even in legacy V42 mode. Now fixed.
  [Backported from V53.5]

- Performing a layout of a truecolor picture on a truecolor screen in
  legacy V42 mode would incorrectly set PDTA_NumColors to 1 even when
  the picture actually had a larger color table after the layout. Now
  fixed. [Backported from V53.5]

- In case a CLUT (i.e. palette mapped) picture needs to be promoted to
  truecolor format by a layout or scaling process, the depth field of
  its BitMapHeader is no longer changed to a value greater than 8 if
  the client is operating in legacy V42 mode. [Backported from V53.5]

- The "Classes/DataTypes/Picture/DitherHiColour" environment variable
  is no longer read when a truecolor picture undergoes a layout on a
  truecolor screen; now that will only be done when the target screen
  is actually a hicolor one. [Backported from V53.5]

- Added an alternative interpolation method for upscaling which yields
  smoother and more accurate results but is also a little slower. The
  code is currently disabled; it can be enabled at compile time with a
  preprocessor definition change.

- Pictures whose source comes in the form of a standard bitmap in CHIP
  memory couldn't be safely upscaled vertically when the destination's
  width was greater than 1008 pixels. This is due to BitMapScale() not
  supporting "big blits" even on ECS or AGA; attempting such a scaling
  would produce artifacts or even corrupt the memory list.
  This is now solved (except on OCS machines) by calling a replacement
  scaling routine whenever this particular situation is detected.

- Fixed and cleaned up the documentation a little.

picture.datatype 47.4 (14.5.2020)

- amendment to the V43 interface for sub-Datatypes

picture.datatype 47.5 (22.5.2020)

- changed behaviour of direct pixmap access for sub-Datatypes for
  8 Bit inputs. Now the internal map is of the type LUT8 for 8 bit
  inputs instead of GRAY8. It is necessary to write the color map
  in order to complete the input phase for 8 bit types successfully.