Releases: stian-svedenborg/xyuv
v1.1.1 Released
The latest version of XYUV is a pure maintenance release focusing on supporting the latest toolchains.
Highlights:
- Fixed warnings and errors encountered when compiling with the latest versions of G++ and CLANG++.
- Updated RapidJSON dependency to v1.1
- Fixed an error related to image-magick support.
- Added readme section on enabling the integrated libpng and imagemagick support.
XYUV v1.1 Release Candidate 0
This release adds the last feature scheduled for 1.1 in addition to a bugfix.
- Features:
- Added if construct to minicalc.
- Bugfixes:
- Fixed an issue in the filesystem traversal functions on Unix which would fail on some systems due to use of a POSIX extension.
XYUV v1.1 Beta 2
This release expands the tools shipping with XYUV. The xyuv-header utility has grown and become so bloated it is difficult for new users to understand how to use it, therefore I have added two new tools:
- xyuv-encode: Created for encoding images to .hex, .bin, .yuv and .xyuv files.
- xyuv-decode: The inverse of the previous, it also (finally) adds the possibility to decode .xyuv images without knowing the format/size of the image encoded in it.
The future of xyuv-header is somewhat uncertain. I will keep maintaining it for the time being, but it is likely that it will be deprecated in the future, once all the functionality has been broken up into smaller more understandable tools.
Version 1.1 Beta 1
This is another prerelease containing additional bugfixes and improvements, compared to Beta 0,
The only changed behaviour is padding (having a line stride larger than the sum of the block-strides) will now fill the padding with a deterministic poison value, so that subsequently writing the same file will not yield different results.
Previously the contents of the padding contained garbage values.
For a full list of changes, please see: #23
Version 1. Released
Version 1.0 is now released!
Encode/decode arbitrary raw image formats.
- Supports YUV color space
- Supports chroma-subsampling
- Supports RGB<->YUV conversion using arbitrary conversion matrices
- Supports Narrow(studio) and Full color range modes.
- Supports arbitrary Block Order modes.
- Supports splitting samples to read some bits from different addresses (and even planes)
- Supports <= 4 color channels
- Defines a file format that allows you to send raw images that can be trivially decoded by the receiver.
- Adding a xyuv header to your raw image buffer allows you to send it to another engineer who will be able to read the metadata directly from the file, or visualize it without having to be in possession of the format template used to create it.
- All relevant metadata is encoded directly in the file, such as line-stride, plane offsets, block order etc.
- Supports all common image formats as input
- Interfaces to ImageMagick to easily create new raw images from common image formats (or convert raw back to a normal image)
- Supports reading/writing raw buffer dumps (.bin, .yuv, .raw)
- Supports reading/writing hex files (.hex, .dump)
Version 1.1 Beta
Changelog:
- Improved build scripts, linking against imagemagick is now completely optional.
- Added interface to libPNG. (This will be used by xyuv-header by default.)
- Exposed low-level rgb-to-yuv conversion routines in top-level interface.
Source-breakage:
- The imagemagick wrapper class has been moved from include/xyuv/imagemagick to include/xyuv/external
v1.0 Release Candidate 1
This release fixes some bugs and adds a few new features that were requested for v1.0:
Changelog:
- Added hex file support
- Fixed a bug causing the first sample after a continuation sample chain to be skipped.
- Fixed a bug where images of non-square dimensions would be decoded wrongly.
- Added overflow checks to block orders
- Added bt601-full range conversion matrix and improved unit-testing of these.
First release candidate for Version 1.0
After significant testing over the last few months, the library is nearing production quality. I expect there to still be some minor bugs when the library is pushed to it's limits. However, it should now be mostly stable.
Anyone using the library can expect the file format to be stable, and that any files generated from this point onward will remain readable by newer versions of the library. I will also be maintaining backward write support for older versions of the file format.
Have fun.
Assuming no major bugs are found I expect the full release of v1.0 to happen sometime before the summer of 2016.