> For color types 2, 3 and 6, there are three such sequences defining the > unit, base, offset, and scale, one for each of the three color components, > with a null separator after the red "scale" and the green "scale" string. I think we shouldn't allow multiple scaling terms for each of the 3 color channels. With multiple "unit" terms, it would mean that we are essentially storing 3 images in a single PNG image. We should allow a pCAL chunk for RGB images, but the scaling should be constant for each channel. Dave, for your RGB transparency data, do you need 3 scaling factors, or just the ability to scale all 3 channels together? > if base == 0 > scaled_value := offset + scale * normalized_pixel_value > else if base == 1 > scaled_value := offset + scale * e ^ normalized_pixel_value > else > scaled_value := offset + scale * base ^ normalized_pixel_value I'm not sure that I like how this works with the normalized pixel values. I think a far better method would be: scaled_value := base ^ (offset + scale*normalized_pixel_value) The reason for this method is that it doesn't make sense that the exponents be normailzed to [0.0, 1.0] for the exponential case. Doing so destroys any relevance in the data. The proper method of handling is more analagous to the linear case, but instead of just using the calculated value, it is the exponent. Here, logb() means the logarithm using base "base", and m is the grayscale bit depth (1,2,4,8,16) or RGB bit depth (8,16). My method of storing the data would be something like: exponent := logb(exponential_data_value) scale = (max_exponent - min_exponent) offset = min_exponent PNG value := (int)((exponent-offset)*(2^m - 1)/scale) If the data values were already the integer exponents, and reasonably filled [0,2^m-1], you could simply use scale = 1, and offset = 0. However, for exponential data which was in floating point, I think this method would give by far more accurate data handling. The other method gives quite a poor representation of the data, IMHO. To store the full dynamic range (as all PNG images really should try to do). It needs: /* This is so the scaled data takes on the range [1, base], which means the exponents fill the range [0.0, 1.0] */ scale := (max_data - min_data)/(base - 1) offset := min_data - scale exponent := logb((data_value - offset)/scale) PNG value := (int)(exponent*(2^m - 1)) Try using both methods for base=10, data in the range [10e-4,10e5], and m=8. Using my method the data is represented accurately across the entire data range, versus the proposed method which skews the accuracy very much in favour of the larger data values. PNG value my data max error proposed data max error --------- ------- --------- ------------- --------- 0 1e-4 1e-4 1 1.08e-4 4% 100.78 50e6% 2 1.17e-4 4.2% 201.68 50% . . . . . . . . . 254 92194.7 4.2% 99001.2 0.5% 255 1e5 1e5 Note that in my method it is not possible to represent zero as a data value, but any arbitrarily small value is acceptable. Cheers, Andreas. -- Andreas Dilger University of Calgary \ "If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert > >

> if base == 0 > scaled_value := offset + scale * normalized_pixel_value > else if base == 1 > scaled_value := offset + scale * e ^ normalized_pixel_value > else > scaled_value := offset + scale * base ^ normalized_pixel_value > >> > in which "e" is the base of natural logarithms (approximately 2.718282), > and the normalized pixel value is the value of the pixel normalized > to the range [0.0:1.0] by dividing it by the maximum value for the bit > depth, using floating point arithmetic. >

>
> If present, this chunk must appear before the first `IDAT` chunk.
> Only one instance of the `pCAL` chunk is permitted in a PNG stream.
>

>
> ------------------------------------------------------------
> To find out more about the mailing list server, send mail to
> png-list-request@dworkin.wustl.edu
> with the word "help" (and nothing else) in the message body.
>
--
Andreas Dilger University of Calgary \ "If a man ate a pound of pasta and
(403) 220-8792 Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert
------------------------------------------------------------
To find out more about the mailing list server, send mail to
png-list-request@dworkin.wustl.edu
with the word "help" (and nothing else) in the message body.
From owner-png-list@dworkin.wustl.edu Sun Oct 1 04:38:01 1995
Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.6.12/8.6.10) with ESMTP id EAA22243 for