 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Image maps rendered w/o assumed_gamma in the global_settings look
acceptable. But if you put "assumed_gamma 1" there (as you should,
actually), you're applying Display_Gamma (2.2 by default) which makes image
maps way too bright. Since such output conversion to Display_Gamma is
apparently the right thing to do, the question is what to do with the
images.
The only solution I've been able to discover so far is to load the image
into Photoshop, select "Image --> Mode --> Assign Profile..." and assign a
prifile (a "Generic 2.2" or the so-called "Working RGB", which seems to be
of gamma 2.1 but has the advantage of sparing you conversion questions the
next time you try to load saved image). Then save the image in PNG format
and use that image in the "pigment { image_map { png "my_image.png" }}";
POV-Ray (its libpng) seems to be able to understand stored profile
perfectly. BTW, converting image *pixels* (from current gamma of 2.2 to
gamma 1, so that the implicit inverse conversion by POV-Ray would restore
textures' original outlook) was not even considered, for obvious reasons.
So far so good. But the disadvantages are numerous... First of all, you
cannot use any format except PNG, which would be [almost] OK -- if there
were no need to use JPEG, at times. Although Photoshop seems to be able to
store profiles within jpegs as well, POV-Ray currently cannot pick them up.
Second, if you edit the PNG file with [almost] any program except Photoshop,
kiss your gamma profile goodby.
So, gentlemen, are there any suggestions? As to me, the only feasible
solution I can think of is to add support for "gamma <value>" to the
image_map statement. Relatively simple, and yet should work perfectly.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3e2aad1a@news.povray.org Vadim Sytnikov wrote:
> So, gentlemen, are there any suggestions? As to me, the only feasible
> solution I can think of is to add support for "gamma <value>" to the
> image_map statement.
Maybe also for the heightfield object.
Even nicer would be if we could manipulate images with functions ...
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Vadim Sytnikov" <syt### [at] ru com> schrieb im Newsbeitrag
news:3e2aad1a@news.povray.org...
> Image maps rendered w/o assumed_gamma in the global_settings look
> acceptable. But if you put "assumed_gamma 1" there (as you should,
> actually), you're applying Display_Gamma (2.2 by default) which makes image
> maps way too bright. Since such output conversion to Display_Gamma is
> apparently the right thing to do, the question is what to do with the
> images.
>
This is also my experience.
> The only solution I've been able to discover so far is to load the image
> into Photoshop, select "Image --> Mode --> Assign Profile..." and assign a
> prifile (a "Generic 2.2" or the so-called "Working RGB", which seems to be
> of gamma 2.1 but has the advantage of sparing you conversion questions the
> next time you try to load saved image). Then save the image in PNG format
> and use that image in the "pigment { image_map { png "my_image.png" }}";
> POV-Ray (its libpng) seems to be able to understand stored profile
> perfectly. BTW, converting image *pixels* (from current gamma of 2.2 to
> gamma 1, so that the implicit inverse conversion by POV-Ray would restore
> textures' original outlook) was not even considered, for obvious reasons.
>
To be more exact: Photoshop stores an additional ICC profile to TIFF, PNG,
anf JPG files, but the only program that makes use of the color profiles (that I am
aware) is Photoshop itself. This ICC extension is not documented by Adobe and the
Adobe specification writes that any other application should ignore it. But Photoshop
adds also a 'gamma' chunk to the png file and this is part of the official PNG spec
and
the libpng (and so POV) does use it. The JPG-JFIF header does not support gamma
information.
> So, gentlemen, are there any suggestions? As to me, the only feasible
> solution I can think of is to add support for "gamma <value>" to the
> image_map statement. Relatively simple, and yet should work perfectly.
>
Well, I convert everything to PNG by using my own little piece of software that also
supports gamma information for PNG files.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20 Jan 2003 11:02:24 -0500, ingo <ing### [at] tagpovrayorg> wrote:
> Even nicer would be if we could manipulate images with functions ...
But then you have to wait for (probably) next MegaPOV :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ive" <ive### [at] lilysoftcom> wrote:
> To be more exact: <...>
Thank you for the clarification.
> Well, I convert everything to PNG by using my own little piece of software
that also
> supports gamma information for PNG files.
Currently, I'm forced to do that as well. But I have substatial library of
textures in JPEG format which I would love to use right away... Besides, I
often write (with various own utilities) PPM files (P6) and pick them with
POV-Ray. All in all, I would like not to stick with just PNG.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
> in news:3e2aad1a@news.povray.org Vadim Sytnikov wrote:
>
>
>>So, gentlemen, are there any suggestions? As to me, the only feasible
>>solution I can think of is to add support for "gamma <value>" to the
>>image_map statement.
>
>
> Maybe also for the heightfield object.
>
> Even nicer would be if we could manipulate images with functions ...
Uh, can't you?
I'd think that the information in an image is just so many numbers that
you could convert to a function and manipulate as you would any other
pattern.
Or are you talking about some kind of post-processing for images that
POV-Ray creates? In that case, yes, you'll have to wait until MegaPOV
gets its post-processing filters back, unless you want to feed the image
back into POV-Ray as an image map, point an orthographic camera at it,
and try to manipulate it that way...
-Xplo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
