|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <nom### [at] nomailcom> wrote:
> "Charles C" <nomail@nomail> wrote in message
> news:web.4ac9720b3f8a411cac4259f0@news.povray.org...
> > I'd never heard of "+fj"! It's always seemed missing even if jpeg is a
> > better
> > distribution format than a "mastering" format. I can imagine there being
> > some
> > rare uses. That said, I have to agree with Trevor's comment. :)
> >
>
> Well, yes and no. JPEG is a lossy format (it's designed that way), but I
> find it by far and away the most convenient when working on graphics
> destined for web pages. Any implication that it's not a worthy format to be
> supported by POV-Ray makes me a tad nervous. I think it should find its way
> into the documentation, with a warning that it's not a loss-free format and
> that the results will unavoidably contain JPEG artifacts. People could then
> simply use another format for any process that requires some sort of top
> quality master.
>
> Regards,
> Chris B.
Sorry, no anxiety intended. ;) I agree JPEG output is a good option to have
available. One feature which could make it even better would be a quality
option. For example "+fjxx" where "xx" is a numeric quality level similar to
what you can enter when saving a JPEG in GIMP.
(Disclaimer: I don't know just how quick or easy this would be to implement, and
I imagine it would be of relatively low priority compared to other things.)
I think depending on the content of an image, JPEG can be more distracting than
at other times. For instance, I tried +fj on a test render with very simple
textures, some fine detail and a blue sky sphere. It looked bad. I suspect
the more a rendering looks like a photo (i.e. no shortage of detail so you're
not staring at one little spot which you can't see clearly), the less
distracting JPEG artifacts might be for a given compression level.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris B schrieb:
>
> Well, yes and no. JPEG is a lossy format (it's designed that way), but I
> find it by far and away the most convenient when working on graphics
> destined for web pages. Any implication that it's not a worthy format to
> be supported by POV-Ray makes me a tad nervous. I think it should find
> its way into the documentation, with a warning that it's not a loss-free
> format and that the results will unavoidably contain JPEG artifacts.
> People could then simply use another format for any process that
> requires some sort of top quality master.
I think the rationale behind deliberately hiding this feature is that
for it to come anywhere close to being /useful/, some more work would
need to be invested; the default quality would have to be increased, and
ideally a quality parameter would have to be added.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> "Chris B" <nom### [at] nomailcom> wrote:
>> "Charles C" <nomail@nomail> wrote in message
>> news:web.4ac9720b3f8a411cac4259f0@news.povray.org...
>>> I'd never heard of "+fj"! It's always seemed missing even if jpeg is a
>>> better
>>> distribution format than a "mastering" format. I can imagine there being
>>> some
>>> rare uses. That said, I have to agree with Trevor's comment. :)
>>>
>> Well, yes and no. JPEG is a lossy format (it's designed that way), but I
>> find it by far and away the most convenient when working on graphics
>> destined for web pages. Any implication that it's not a worthy format to be
>> supported by POV-Ray makes me a tad nervous. I think it should find its way
>> into the documentation, with a warning that it's not a loss-free format and
>> that the results will unavoidably contain JPEG artifacts. People could then
>> simply use another format for any process that requires some sort of top
>> quality master.
>>
>> Regards,
>> Chris B.
>
> Sorry, no anxiety intended. ;) I agree JPEG output is a good option to have
> available. One feature which could make it even better would be a quality
> option. For example "+fjxx" where "xx" is a numeric quality level similar to
> what you can enter when saving a JPEG in GIMP.
>
> (Disclaimer: I don't know just how quick or easy this would be to implement, and
> I imagine it would be of relatively low priority compared to other things.)
>
> I think depending on the content of an image, JPEG can be more distracting than
> at other times. For instance, I tried +fj on a test render with very simple
> textures, some fine detail and a blue sky sphere. It looked bad. I suspect
> the more a rendering looks like a photo (i.e. no shortage of detail so you're
> not staring at one little spot which you can't see clearly), the less
> distracting JPEG artifacts might be for a given compression level.
>
> Charles
>
>
>
Also, using AA can greatly help.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <ano### [at] anonymousorg> wrote in message
news:4aca85a1$1@news.povray.org...
> Chris B schrieb:
>>
>> Well, yes and no. JPEG is a lossy format (it's designed that way), but I
>> find it by far and away the most convenient when working on graphics
>> destined for web pages. Any implication that it's not a worthy format to
>> be supported by POV-Ray makes me a tad nervous. I think it should find
>> its way into the documentation, with a warning that it's not a loss-free
>> format and that the results will unavoidably contain JPEG artifacts.
>> People could then simply use another format for any process that requires
>> some sort of top quality master.
>
> I think the rationale behind deliberately hiding this feature is that for
> it to come anywhere close to being /useful/, some more work would need to
> be invested; the default quality would have to be increased, and ideally a
> quality parameter would have to be added.
Ahh! Well I first learned about it on these newsgroups years ago, so I don't
think I've let a secret slip that wasn't already out there.
I don't know the POV source, d'you think that would be a big
investment/change? Is the JPEG compression just a standard codec library
call at the end of the render?
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris B schrieb:
> I don't know the POV source, d'you think that would be a big
> investment/change? Is the JPEG compression just a standard codec
> library call at the end of the render?
I... um.... well, I guess it is.
(*browses though the code*)
Ehm... yup - the change would be minimal indeed... unless you were
hoping for an effort lower than zero :-)
Fun facts to know: There already /is/ a JPEG compression quality
parameter in POV-Ray, at least with 3.7.0.beta.34. Setting the .ini file
parameter "Compression" to any integer value from 2 to 100 should do the
job. Theoretically. Didn't test, just looked at the code.
The parameter is apparently intended to be format-specific; for JPEG,
values 0 (default) and 1 are short-circuited to produce a fairly
high-quality image, while any other value in the range of 2 to 100 is
passsed to the JPEG library as the encoding quality parameter (2 = poor,
100 = maximum quality). Values lower than 0 or higher than 100 are
clipped to the 0..100 range.
Other file formats currently don't use the Compression parameter.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <ano### [at] anonymousorg> wrote in message
news:4ace245f@news.povray.org...
> Chris B schrieb:
>
>> I don't know the POV source, d'you think that would be a big
>> investment/change? Is the JPEG compression just a standard codec library
>> call at the end of the render?
>
> I... um.... well, I guess it is.
>
> (*browses though the code*)
>
> Ehm... yup - the change would be minimal indeed... unless you were hoping
> for an effort lower than zero :-)
Nope! Zero effort is low enough for me :-)
> Fun facts to know: There already /is/ a JPEG compression quality parameter
> in POV-Ray, at least with 3.7.0.beta.34. Setting the .ini file parameter
> "Compression" to any integer value from 2 to 100 should do the job.
> Theoretically. Didn't test, just looked at the code.
Indeed I don't mind a smidgen above zero, so I'll be ok with trying that out
and adding something into the Wiki.
Is there a corresponding command-line option?
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris B schrieb:
> Is there a corresponding command-line option?
Apparently not, only the .INI file option.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Chris B schrieb:
>
> > Is there a corresponding command-line option?
>
> Apparently not, only the .INI file option.
I bet +fjxx could really be handy for somebody wanting to post a test render in
p.b.i.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <nom### [at] nomailcom> wrote in message
news:4ace286b@news.povray.org...
> Indeed I don't mind a smidgen above zero, so I'll be ok with trying that
> out and adding something into the Wiki.
> Is there a corresponding command-line option?
you additions have been merged into the main doc ....
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jim Holsenback" <jho### [at] povrayorg> wrote in message
news:4acf77ce$1@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote in message
> news:4ace286b@news.povray.org...
>> Indeed I don't mind a smidgen above zero, so I'll be ok with trying that
>> out and adding something into the Wiki.
>> Is there a corresponding command-line option?
>
> you additions have been merged into the main doc ....
>
Thanks Jim.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |