Sorry this is happening so soon after the last set of releases, but...
Release 0.10.15:
* back-ports a bug fix to TextureSystem (related to reading wrapmodes from
a texture file's header) that had been fixed for some time in 1.0 and later.
Release 1.0.11:
* maketx bug fix: --monochrome-detect would do the wrong thing for
images with alpha.
* maketx bug fix: --constant-color-detect didn't actually do anything.
* maketx --compression now allows you to override the default compression
of the output texture (default is "zip").
And finally, I'm planning to push a final 1.1.0 release branch tomorrow
morning. (Don't worry, if there are bugs, we'll patch it.)
On Nov 5, 2012, at 10:57 PM, Larry Gritz wrote:
> A flurry of releases:
>
> The 0.10 branch has tagged Release-0.10.14, containing an enhancement of
> texture stats, to show tile reads for each MIPmap level in the detailed file
> stats (at the request of the one [as far as I know] commercial user still
> using 0.10).
>
> The stable 1.0 branch tagged Release-1.0.10 with several fixes:
>
> * ImageCache: more graceful handling of the inability to free handles or
> tiles under extreme conditions. Rather than assert when we can't free
> enough to stay within limits, just issue an error and allow the limits
> to be exceeded (hopefully only by a little, and temporarily).
> * ImageCache: Detailed per-file stats now track the number of tile reads
> per MIPmap level.
> * ImageCache attribute "unassociatedalpha" (when nonzero) requests that
> IC images not convert unassociated alpha image to associated alpha.
> * maketx option --ignore-unassoc leaves unassociated alpha data as it is
> (no auto-conversion to associated alpha) and/or ignores the tags for
> an input file that is associated but incorrectly tagged as unassociated
> alpha.
> * oiiotool & info: the --hash command had a bug wherein when applied to
> images there were MIP-mapped, would hash the lowest-res MIP level rather
> than the highest-res. This could result in two different images, if
> they happened to have the same average color, to incorrectly report
> the same SHA-1 hash. Note that this did NOT affect non-MIPmapped images,
> nor did it affect the SHA-1 hashing that occurred in maketx to allow
> the TextureSystem to detect duplicate textures.
>
> And I've also tagged the current master/RB-1.0 as Release-1.1.0-beta4.
> Release of 1.1.0 ("final") is IMMINENT. Let's say that if I have no serious
> bug reports or objections by the end of the week, I will tag and release. At
> that point, although we will certainly fix bugs and maybe add enhancements
> (if they are deemed fairly safe), we will try very hard not to break link
> compatibility or change existing public APIs within the 1.1 branch
> (meanwhile, the new master will be 1.2 in development, subject to riskier
> changes).
>
> So, summary as of today:
>
> master -- consider this within epsilon of 1.1.0, with a non-beta release
> approximately at the end of the week.
>
> RB-1.1 -- identical to master until the end of the week, then they will
> diverge, with 1.1 staying stable and the master subject to instabilities from
> new development or API changes.
>
> RB-1.0 (and various 1.0 releases) -- stable release recommended for
> commercial/production use, but within days we will suggest that 1.1 be the
> production release. We will continue to maintain (i.e. fix important bugs)
> 1.0 as long as people are dependent upon it.
>
> RB-0.10 -- still maintained for the one or two sites using it, but only the
> most critical bug fixes that are urgently needed by those remaining users.
> We encourage everybody else (and in fact them) to get onto 1.1 at their
> earliest convenience.
>
> RB-0.9 and older -- consider these no longer maintained; to the best of our
> knowledge, nobody is depending on them.
>
>
> --
> Larry Gritz
> [email protected]
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
