Am 26.04.2010 22:29, schrieb Kenneth:

> I always thought that .jpeg compression quality was set within a simpler
> 1-through-10 scale --just those and no in-between values. (That's how my old
> version of Photoshop does it, anyway...which is about the extent of my
> knowledge.)

No, basically the JPEG compression quality is a non-discrete value; from 
what I known, theoretically it should be in the range from 0.0 to 1.0, 
but software may use a pretty arbitrary scale in its UI. POV-Ray uses 
percents, for that matter.

> How was 95 arrived at for the 3.7 default (vs. 100)? They're so close.

Well, someone figured that raytraced images should be stored at pretty 
high quality, and decided that 95% made for a nice trade-off between 
size and quality. (File size does not grow linear with the quality 
value; in a quick test I just did, going from 95% to 100% more than 
doubled the file size.)

 > More
> importantly, can all image-viewing apps decode .jpegs created with such a
> 'fine-scale' 1-to-100 compression choice? I base this question on problems I've
> encountered (in Photoshop again, v5.0): strangely, even within its own 1-to-10
> scale, there are several values that produce an image which isn't viewable in
> some other apps I have. Maybe that's strictly a problem with the older
> Photoshop--but it makes me wonder about the 1-to-100 variation in 3.7. Could the
> 'wrong choice' of a particular interim value produce an image-decoding problem?

I don't think this has anything to do with the compression quality value 
/per se/. Probably it's some bug in Photoshop 5.0's encoder that just 
doesn't show at low compression settings (e.g. an overflow somewhere in 
the math).

(My versions of Photoshop (6.0) happens to use a 0..100% range as well.)

Post a reply to this message

Am 26.04.2010 21:08, schrieb clipka:

> There are still issues though: While IC displays the JPEG output images
> as expected, Windows Explorer preview and Photoshop 6.0 get the RGB
> values wrong way round (i.e. blue displays as red and vice versa). So
> given that IC normally does a pretty good job at JPEGs, POV-Ray must be
> doing something pretty unconventional there.

I guess I found the culprit. Someone apparently misunderstood either the 
libjpeg interface or the vanilla JPEG file format standard.

Post a reply to this message

clipka wrote:
> No, basically the JPEG compression quality is a non-discrete value;

JPEG compression quality isn't even defined as a number. Each 8x8 block on 
the image can pick how much of the quality to throw away. (For example, I 
wrote one compressor way back in the dark ages that would compress a block 
less if the average color was close to skin-tone.)

It's not a number. It's an entire 8x8 matrix for each 8x8 block of the 
image. That said, most programs take the number you give it and translate it 
into an appropriate 8x8 block. The open source library (originally used in 
cjpeg and djpeg) used a 0..100 scale. On this scale, 95..100 give you a 
range of pixels that are usually spot-on, or off by one out of 255 each, but 
a huge change in the size (3x? 10x?) for stepping from 95 to 100.

There's also the possibility of having multiple huffman tables, or an 
optimized huffman table, or a simple huffman table. Nobody does the simple 
huffman table any more, but back when a jpeg compression took ten seconds or 
so, not going thru it twice to recalculate the huffmans was sometimes 
worthwhile.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

> How about changing the default output file type for both Windows and 
> Unix version to PNG?

Yes!

Post a reply to this message

On 26.04.2010 21:08, clipka wrote:
> There are still issues though: While IC displays the JPEG output images
> as expected, Windows Explorer preview and Photoshop 6.0 get the RGB
> values wrong way round (i.e. blue displays as red and vice versa). So
> given that IC normally does a pretty good job at JPEGs, POV-Ray must be
> doing something pretty unconventional there.

In fact IC swabs the red and blue channels (and therefor shows POV-Ray 
jpeg images correctly) BECAUSE POV-Ray is doing it wrong by storing BGR 
instead of RGB.
POV-Ray is the one and only application that I am aware off that does 
not perform the RGB to YCbCr color space transformation but uses the DCT 
directly on RGB, err in this case BGR data. This is perfectly legal for 
jpeg (when done in the right order of channels) but does not make much 
sense because it results in either more pronounced block artifacts or 
larger file size.

My suggestions for writing ray-traced jpeg files would be anyway:
- use YCbCr
- no chroma sub-sampling (to avoid the disappearance of small red or 
blue colored details)
- compression setting of 85%

in my experience (and I did a lot of tests on that matter) this gives 
the best trade-off between quality and file size.


On a different matter: adding the render statistics as a metadata tag to 
PNG would be very nice. And doing the same with OpenEXR even more nice 
as OpenEXR is the format I do use as default file format for all my 
POV-Ray work.

-Ive

Post a reply to this message

Am 27.04.2010 22:19, schrieb Ive:
>> There are still issues though: While IC displays the JPEG output images
>> as expected, Windows Explorer preview and Photoshop 6.0 get the RGB
>> values wrong way round (i.e. blue displays as red and vice versa). So
>> given that IC normally does a pretty good job at JPEGs, POV-Ray must be
>> doing something pretty unconventional there.
>
> In fact IC swabs the red and blue channels (and therefor shows POV-Ray
> jpeg images correctly) BECAUSE POV-Ray is doing it wrong by storing BGR
> instead of RGB.
> POV-Ray is the one and only application that I am aware off that does
> not perform the RGB to YCbCr color space transformation but uses the DCT
> directly on RGB, err in this case BGR data. This is perfectly legal for
> jpeg (when done in the right order of channels) but does not make much
> sense because it results in either more pronounced block artifacts or
> larger file size.

I found out by now about the RGB instead of YCbCr; but isn't RGB invalid 
anyway for JFIF (the JPEG-compressed image file format commonly 
associated with the .jpg extension)? And the files written by POV-Ray 
also don't have a proper JFIF tag at all.

BTW, as a matter of fact, the wrong channel ordering is a 3.7 issue; 
POV-Ray 3.6 at least did it the right way round.

I consider the use of RGB instead of YCbCr a bug (already filed as 
FS#103 ;-)).

> My suggestions for writing ray-traced jpeg files would be anyway:
> - use YCbCr

Submitted to the codebase as change #4956 already ;-)

> - no chroma sub-sampling (to avoid the disappearance of small red or
> blue colored details)

I'm not sure what exactly you mean; do you happen to have a sample 
scene? And can you give me pointers off the top of your head how to set 
this up with jpeglib?

> - compression setting of 85%
>
> in my experience (and I did a lot of tests on that matter) this gives
> the best trade-off between quality and file size.

I'm not sure yet what to make of this. Normally I'd say file output 
should default to high quality; then again, for high quality we'd have 
PNG (or plenty other 24-or-more-bit lossless file formats), so it might 
make sense to go for a default JPEG quality that one might possibly put 
directly on the internets. After all, if you decide to output to JPEG, 
you probably don't want to do any more processing on the image. So in 
the end I'd probably agree with you.

> On a different matter: adding the render statistics as a metadata tag to
> PNG would be very nice. And doing the same with OpenEXR even more nice
> as OpenEXR is the format I do use as default file format for all my
> POV-Ray work.

See FS#64.

Post a reply to this message

Am 27.04.2010 23:05, schrieb clipka:
>> - no chroma sub-sampling (to avoid the disappearance of small red or
>> blue colored details)
>
> I'm not sure what exactly you mean; do you happen to have a sample
> scene? And can you give me pointers off the top of your head how to set
> this up with jpeglib?

Forget about that. Found it, seen the difference. Though it does 
increase file size as well, so maybe a higher-quality setting /with/ 
chroma sub-sampling might do just as fine?

Then again, I guess you have a /bit/ more experience with image file 
formats than I do ;-)

Post a reply to this message

Am 27.04.2010 22:19, schrieb Ive:

> My suggestions for writing ray-traced jpeg files would be anyway:
> - use YCbCr
> - no chroma sub-sampling (to avoid the disappearance of small red or
> blue colored details)
> - compression setting of 85%

Hm... how about enabling/disabling chroma sub-sampling depending on 
compression setting? I just happened to see that in some code found on 
the 'net.

Post a reply to this message

On 27.04.2010 23:05, clipka wrote:
> I found out by now about the RGB instead of YCbCr; but isn't RGB invalid
> anyway for JFIF (the JPEG-compressed image file format commonly
> associated with the .jpg extension)? And the files written by POV-Ray
> also don't have a proper JFIF tag at all.
>
As you say, for a simple jpeg code-stream almost everything is allowed 
and valid, even multi-color-separations with up to 12 channels and 
things like this are even supported by jpeglib 6b. Surely such files are 
not very portable but this is why the JFIF and EXIF extensions have been 
invented for.


>> - no chroma sub-sampling (to avoid the disappearance of small red or
>> blue colored details)
>
> I'm not sure what exactly you mean; do you happen to have a sample
> scene? And can you give me pointers off the top of your head how to set
> this up with jpeglib?
>

Out of my head - done these things much too often ;)

   struct  jpeg_compress_struct cinfo;

   // do a few things... 	

   jpeg_set_defaults(&cinfo);

   // do more things like setting the compression rate...

   if (NO_SUBSAMPLE)
   {
     cinfo.comp_info[0].h_samp_factor = 1;
     cinfo.comp_info[0].v_samp_factor = 1;
   }


someone mentioned the problem already within this thread (and the Golden 
Gate Bridge IIRC) and it has been mentioned multiple times within p.b.i. 
Increasing the compression rate to even 100 does not help at all in this 
cases.
In the early days of jpeg it was quite common to store the 2 chroma 
samples only per each 4x4 pixel block and I think the default setting of 
jpeglib 6b is per each 2x2 pixel block.
Every contemporary and not totally brain dead application should have no 
problems in reading jpeg when subsampling is turned off as shown above.
Note that I'm talking especially about computer generated and/or 
raytraced images and not those made by a digital camera or digitized by 
a flatbed scanner where chroma sub-sampling works as a kind of 
color-noise-reduction filter and this is (beside of making smaller 
files) a nice side effect.


> See FS#64.

I see. But I for one would advocate for adding the whole render 
statistic as a comment tag to PNG and do the same for jpeg, OpenEXR and 
even P(N)M files (where just a simple ascii text before the image 
dimension would do the job).

-Ive

Post a reply to this message

On 27.04.10 23:05, clipka wrote:
> BTW, as a matter of fact, the wrong channel ordering is a 3.7 issue;
> POV-Ray 3.6 at least did it the right way round.
>
> I consider the use of RGB instead of YCbCr a bug (already filed as
> FS#103 ;-)).

No, it isn't a bug. This *really* is intentional behavior! With the correct 
settings in other places (not sure if they are), you can get rid of a lot of 
color bleeding when using sharply ray-traced objects by using RGB.

	Thorsten

Post a reply to this message