From: <ra...@ra...> - 2000-10-30 00:42:19
|
On 29 Oct, Tom Gilbert scribbled: -> * Matt McClanahan (car...@do...) wrote: -> > On Sun, 29 Oct 2000, Tom Gilbert wrote: -> > -> > > * ra...@ra... (ra...@ra...) wrote: -> > > > agreed - the db loader/saver uses "compression" instead of quality as -> > > > its alos lossless - compression is a value 0-9 - just like png (since -> > > > thhis si the compression values zlib accepts) -> > > -> > > Oh. I didn't look at the db loader. So should I revert png to -> > > "compression"? Or do people think it is a good idea to standardise the -> > > loaders somehow (I don't care what we call it but I think it should be -> > > the same for each). -> > -> > Between quality and compression, I imagine compression would be a better -> > term since quality doesn't really apply to the db or png loaders. -> > However, this raises an issue with how the scale for the jpeg loader -> > works. -> > -> > For the png loader, higher number means more compression, but for jpeg's, -> > a higher number means less compression. Reversing the jpeg loader's -> > quality scale will break just as many apps as if the quality tag is -> > changed, so is there a right way to get them to act the same without -> > breaking apps? -> > -> > Matt -> -> Why not change them all to "compression" but leave the existing -> "quality" in the jpeg loader for apps that use it. -> -> I really want a standard for this. I'll commit it in 30 mins if I don't -> get an objection.... that would work best. savers can check multiple properties looking for save compression/quality quality can be 0-100 compression 0-9 saver can convert as it sees fit to what makes sense for the format :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... ra...@en... ra...@li... ra...@zi... |