Ron Parker wrote:

> The point that Warp didn't get around to was that we spent hours trying
> to figure out what's wrong with POV's 16-bpp PNG output, only to discover
> that it's a problem with Photoshop's "stupid retarded" 16-bpp PNG import
> that swaps the byte order.  Worse, it's a problem that's been around for
> more than one major version now.  This is a problem that is not likely
> to go away until Adobe gets off their fat lazy asses and fixes their
> "industry standard" program instead of playing with their buddies at the
> Justice Department.

Well, I recall having problems with 8-bit images around 3.0. I guess since PC's
used index 0 for black and 255 for white and mac's use the opposite, some
programmer there decided to invert the palette on all PC format images read and
written. Of course, to go along with that they had to invert every single pixel in
the image.

That all was fine for reading and writing the same format, but if you read in an
8-bit mac image, then export to PC, the palette got reversed. And if you were
producing content for multimedia productions where only the first 7-bits of the
palette are used and you are completely hosed.

Adobe's response was "oh, you shouldn't be using Photoshop for 8-bit work, use
<insert name of their largest competetor>".

The problem persisted for several dot-releases.


--
Wind the Frog!

Post a reply to this message

On Tue, 11 Sep 2001 09:03:01 -0700, Jon A. Cruz wrote:
>Adobe's response was "oh, you shouldn't be using Photoshop for 8-bit work, use
><insert name of their largest competetor>".

Who they probably now own (Aldus?)

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message