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