 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi there,
effect that I saw when viewing a couple of animations rendered with
a halo around them. For example when I have a completely black image with
say 10, I except to see a glow-like effect.
I currently fake this effect by rendering an image a couple of times with
different assumed_gamma settings. Afterwards I load those images to
Photoshop, gaussian-blur the images proportional to their gamma-settings
blurred more) and then layer those images into one. This happens to be
quite a job especially with an huge amount of frames for example in an
animation or when you have to render a slow-rendering image very often. So
this is why I a) want to write a little program doing this stuff for me (it
will be written in java as this is the only programming language I know)
and b) want to use Megapovs *.hdr output as then every frame has only to be
rendered once.
This is where my question appears:
something like that http://de.wikipedia.org/wiki/Windows_bitmap (the site
I hope someone can help me with that.
Thanks Roman
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Roman Reiner wrote:
>
> This is where my question appears:
> something like that http://de.wikipedia.org/wiki/Windows_bitmap (the site
The hdr format specification can be found in:
http://radsite.lbl.gov/radiance/refer/filefmts.pdf
a reference implementation on:
http://radsite.lbl.gov/radiance/refer/Notes/picture_format.html
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In a vaccuum, do bright objects generate halos when photographed? It
seems like it would be an effect that requires an atmosphere, although I
admit I know little about how cameras actually work. I suppose that the
bright areas would overexpose adjacent parts of the film?
Skip
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Skip Talbot <Ski### [at] aol com> wrote:
> In a vaccuum, do bright objects generate halos when photographed?
Yes, of course.
There are, naturally, different types of halos. One type is caused by
the properties of the film to which the scene is photographed.
The camera is always calibrated for a certain maximum brightness. This
is done by adjusting the shutter speed and aperture and by the choice of
film type (its ISO value etc).
What happens when something is brighter than what the film can register
under these settings? What happens is that the film gets overexposed at
that part and color-bleeding occurs. It's this color-bleeding which looks
like "halos" around the overbright objects.
Sometimes this effect is even purposedly enhanced by putting a filter
in the lens of the camera which slightly scatters light. This makes
everything look smoother and a bit fuzzier/blurred.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
>
> The hdr format specification can be found in:
>
> http://radsite.lbl.gov/radiance/refer/filefmts.pdf
>
> a reference implementation on:
>
> http://radsite.lbl.gov/radiance/refer/Notes/picture_format.html
>
> Christoph
>
Allthough I couldn't find what i was looking for in those files it pushed me
into the right direction and i finally could find the information elsewhere
on that page. Thanks for that!
Now let's see how good my java-skills are to get this thing to work ;-)
I'll come up with some other image-examples when there are the first
results.
In reference to the other questions on the issue where those halos come from
i have to say that i actually haven't thought very much of that yet. as i
wrote above i'm just trying to simulate an effect that just looks cool and
even more realistic IMHO ;-)
Greetings Roman
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmm. It's getting tricky. Reading works already for uncompressed HDRI's. But
MegaPOV's output isn't uncompressed in most cases ;-) Could someone give me
a hint about the RLE-encoding used by MegaPOV as there seem to be many
variations of this compression method.
The file you linked says
> i don't recommend writing your own routine to decode it -- use what's in color.c.
but as i'm limited to java this doesn't help me very much ;-)
Greetings Roman
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Roman Reiner wrote:
> Hmm. It's getting tricky. Reading works already for uncompressed HDRI's. But
> MegaPOV's output isn't uncompressed in most cases ;-) Could someone give me
> a hint about the RLE-encoding used by MegaPOV as there seem to be many
> variations of this compression method.
No, there is exactly one compression scheme used by MegaPOV for writing
HDR files. It can also read a different older compression though.
> The file you linked says
>
>>i don't recommend writing your own routine to decode it -- use what's in color.c.
>
> but as i'm limited to java this doesn't help me very much ;-)
The file format docs also say the algorithm is descibed in detail in
Chapter II.8 of Graphics Gems II. I doubt however this will be of much
help if translating a few lines of C code into Java is impossible for you.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> No, there is exactly one compression scheme used by MegaPOV for writing
> HDR files. It can also read a different older compression though.
Yes, I meant RLE-compression in general isn't uniform. But MegaPOV's one is.
> The file format docs also say the algorithm is described in detail in
> Chapter II.8 of Graphics Gems II. I doubt however this will be of much
> help if translating a few lines of C code into Java is impossible for you.
Well it's not impossible for me of course (would you stop making fun of me
;-)) but I hoped it would not be necessary and this whole thing gets bigger
than I
expected it to be at first. I didn't expect it would be that difficult just
to load the data stored in those hdr-files into an array which I can *then*
use to start what I was actually planning to program :-)
And when the only possible solution for this problem would be to order an
$77.95 book from the other side of the world then I'd rather surrender ;-)
Thanks allot for your help anyway. I'll see what those c-files finally have
for me. Java and C aren't that far away from each other aren't they :-)
Greetings Roman
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Roman Reiner wrote:
> And when the only possible solution for this problem would be to order an
> $77.95 book from the other side of the world then I'd rather surrender ;-)
Last time I checked, the Graphic Gem book series was widely available in
libraries and via interlibrary loan.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Roman Reiner wrote:
>
>>The file format docs also say the algorithm is described in detail in
>>Chapter II.8 of Graphics Gems II. I doubt however this will be of much
>>help if translating a few lines of C code into Java is impossible for you.
>
>
> Well it's not impossible for me of course (would you stop making fun of me
> ;-))
I am not making fun of anyone - i just gave my assessment on how useful
the cited part would be for you.
Note you were asking specifically for the format of a HDR file. No one
said this would be necessary to do what you want to do.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
