On 26.04.10 19:34, Warp wrote:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 26.04.2010 15:01, schrieb Warp:
>>> Slime<fak### [at] emailaddress>   wrote:
>>>> I don't think the default file type should be one that uses lossy
>>>> compression.
>>>
>>>     I didn't know that POV-Ray even supported lossy formats as output...
>
>> Contrary to rumors, POV-Ray can output JPEG.
>
>    Is that new in POV-Ray 3.7? How do you fine-tune the compression options?

It has been there in 3.6 as well, but was simply inaccessible from the 
command line (but would have been accessible i.e. for special rendering of 
insert menus from inside POV-Ray, though this was not done). In 3.7 general 
access was added.

	Thorsten

Post a reply to this message

On 26.04.10 00:16, clipka wrote:
> Am 25.04.2010 23:20, schrieb Alain:

>>> How about changing the default output file type for both Windows and
>>> Unix version to PNG?
>>
>> Why not for all versions?
>
> With me having not much of an idea about Macs anyway, I pass that
> question on to any Mac experts listening right now...

PNG is the system's preferred file format in Mac OS X.

	Thorsten

Post a reply to this message

Jim Holsenback <jho### [at] povrayorg> wrote:
> >   Is that new in POV-Ray 3.7? How do you fine-tune the compression options?
> > 
> http://wiki.povray.org/content/Documentation:Reference_Section_1.1#Output_File_Type

  Thanks.

-- 
                                                          - Warp

Post a reply to this message

On 4/25/2010 4:44 AM, clipka wrote:
> How about changing the default output file type for both Windows and
> Unix version to PNG?

Another vote for PNG. That's the format I always go to for POV.

-- 
~Mike

Post a reply to this message

Am 26.04.2010 19:34, schrieb Warp:

>> Contrary to rumors, POV-Ray can output JPEG.
>
>    Is that new in POV-Ray 3.7? How do you fine-tune the compression options?

No, it has just been undocumented - for good reason: POV-Ray 3.6 was 
able to generate JPEG output as well, but the quality was terrible and 
couldn't be changed.

With 3.7, compression is set with the "Compression=N" INI-file option, 
where N is an integer value from 2 ("horrible") to 100 ("top quality"). 
A value of either 0 or 1 will select the default (95; 3.6 apparently 
used a value somewhere around 10).

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.

Post a reply to this message

"clipka" <ano### [at] anonymousorg> wrote in message 
news:4bd40f13$1@news.povray.org...
> How about changing the default output file type for both Windows and Unix 
> version to PNG?

Yes please!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 26.04.2010 19:34, schrieb Warp:
>
> >> Contrary to rumors, POV-Ray can output JPEG.

> With 3.7, compression is set with the "Compression=N" INI-file option,
> where N is an integer value from 2 ("horrible") to 100 ("top quality").
> A value of either 0 or 1 will select the default (95; 3.6 apparently
> used a value somewhere around 10).

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.)

How was 95 arrived at for the 3.7 default (vs. 100)? They're so close. 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?

Ken

Post a reply to this message

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