Why wait for night time?

Discussion forum for Tawbaware's Star Tracer and Image Stacker software

Why wait for night time?

Postby Growing » Sun May 23, 2010 9:51 am

I've actually been experimenting with adding artificial star trails to photographs. I downloaded a database of every visible star (and then some). And I've written some software to create star trails and project them onto equirectangular (easy) or rectilinear (harder but more useful) images.

With my software, I don't even need to wait for sun down. Armed with the knowledge of the time, latitude & longitude, and the orientation of the photograph, it is possible to create matching star-trails. These star-trails can be blended/stacked/masked into the existing panorama to create a "dazzling" scene, free from light pollution, aircraft and hot pixels.

Now my software is very crude (no UI), buggy, and often uses gigabytes of RAM and/or crashes. And the results so far are very far from realistic or artisticly worthwhile. But it is possible.

Which brings me to Max's new software Star Tracer. I haven't yet had the chance to try it out, and the weather here has been permanently overcast, so this is just an observation of the method, not experience.

The Star Tracer software appears to result in a non-realistic uneven brightening of portions of the sky due to horizon twilight and light pollution being rotated and stacked in an arc across the sky.

May I suggest that the application should create a mask of only the stars (identified by small pixel area local increase in brightness) and then rotate only the stars. The night sky (twilight and light pollution) will then remain stationary and at original luminosity, while the stars leave trails over this stationary background. All that is left is to mask out the places where stars should not be visible (through trees, buildings and ground).

It would also be useful for the Star Tracer to output information about the location and orientation of the celestial sphere in a manner that could be:
1) used to create an artificial star chart, or
2) imported back into PTAssembler
Just finding the celestial pole if extremely helpful, and Star Tracer seems to be very adept at that.

Another observation is that the creation of star charts or star trails is actually very fast. There are only say 5000 naked-eye visible stars (or say 15K potentially visible to regular cameras), and the calculation of the star position or path is quite quick. So in the scheme of things when dealing with large panoramas, the star calculations are very fast. The slow part is actually the black bits between the stars (gigapixels of black and kilopixels of white in my star charts). It seems to me to make a lot more sense to draw the star trails onto the final (or near final) image, than to create star charts as input to the entire PTAssembler process (as I have been trying to do).

Anyway, congrats to Max on this exciting new photographic technique. I hope it leads to a resurgence in interest in star trails.

I used to do some on my 5x4 - and it was surprisingly easy. Bulb mode had no difficulty staying open for hours, no hot pixels, and either little reciprocity failure (Provia) or lots (Ilford, Kodak). And no backpanel lights to destroy my nightvision. But I haven't been as keen using a DSLR - it never seemed to be a good match. And nighttime panoramas seemed way out of reach.

Stephen
Growing
 
Posts: 44
Joined: Sat Jan 17, 2009 4:48 am
Location: Newcastle, Australia

Re: Why wait for night time?

Postby maxlyons » Mon May 24, 2010 7:56 pm

Growing wrote:The Star Tracer software appears to result in a non-realistic uneven brightening of portions of the sky due to horizon twilight and light pollution being rotated and stacked in an arc across the sky.


Yes...I don't view the current output from Star Tracer when extending trails to be a "finished product". Rather, I'd describe it as something that can be used as input to a manual blending/editing process.

May I suggest that the application should create a mask of only the stars (identified by small pixel area local increase in brightness) and then rotate only the stars. The night sky (twilight and light pollution) will then remain stationary and at original luminosity, while the stars leave trails over this stationary background. All that is left is to mask out the places where stars should not be visible (through trees, buildings and ground).


I think this is a very worthwhile goal, but quite tricky to implement well! I plan to do some more work in this area, but my initial research suggested that this would take a sufficiently long amount of time to do well that it wasn't worth holding up the current version of Star Tracer. In the meantime, you should be able to create whatever mask you like in an editing program like Photoshop and rotate that image. So, there is at least a semi-automatic workaround currently possible.

It would also be useful for the Star Tracer to output information about the location and orientation of the celestial sphere in a manner that could be:
1) used to create an artificial star chart, or
2) imported back into PTAssembler
Just finding the celestial pole if extremely helpful, and Star Tracer seems to be very adept at that.


Can you explain what sort of output you envision?

Another observation is that the creation of star charts or star trails is actually very fast. There are only say 5000 naked-eye visible stars (or say 15K potentially visible to regular cameras), and the calculation of the star position or path is quite quick. So in the scheme of things when dealing with large panoramas, the star calculations are very fast.


I'm not sure if I fully understand, but, if I do, it sounds like Star Tracer works in a different fashion. Star Tracer doesn't start with an input pixel coordinates and then rotate it to find the output pixel coordinate. Rather, it does the opposite. It starts with an output pixel coordinates, does the "inverse rotation"and figures out what are the input pixel coordinates to sample to create that output pixel. It iterates over every output pixel in the final image one at a time and performs this calculation to find the corresponding input pixel(s) to sample.

Max
maxlyons
 
Posts: 3640
Joined: Fri Jun 20, 2003 8:55 pm
Location: USA

Re: Why wait for night time?

Postby dsp » Mon May 24, 2010 9:15 pm

Growing wrote:

The Star Tracer software appears to result in a non-realistic uneven brightening of portions of the sky due to horizon twilight and light pollution being rotated and stacked in an arc across the sky.

May I suggest that the application should create a mask of only the stars (identified by small pixel area local increase in brightness) and then rotate only the stars. The night sky (twilight and light pollution) will then remain stationary and at original luminosity, while the stars leave trails over this stationary background. All that is left is to mask out the places where stars should not be visible (through trees, buildings and ground).


Stephen


Thresholding of the sky to find stars is pretty easy, even with uneven background, as there are plenty of decent spatially variant segmentation/threshold schemes. The blending become a bit more of an issue, as for long rotations, the stars may rotate onto a background that is brighter than the original star. It is not clear to me if having blend with a lighten mode is the best solution for creating a natural image - I haven't looked at the results. I guess the acid test would be if people think the image looks natural, or if it looks phony!

cheers, Darcy
dsp
 
Posts: 580
Joined: Tue Feb 20, 2007 11:09 am
Location: Hoboken, NJ

Postby Growing » Tue May 25, 2010 4:52 am

The blending become a bit more of an issue, as for long rotations, the stars may rotate onto a background that is brighter than the original star. It is not clear to me if having blend with a lighten mode is the best solution for creating a natural image - I haven't looked at the results. I guess the acid test would be if people think the image looks natural, or if it looks phony!

cheers, Darcy


The star light would be additive to the background. But it is important to be working in the right luminosity space. Pixel values in the input and output images have a strong gamma (usually 2.2), and are not linear. So although the light is additive, you can't just do star A + sky B = output C. If A and B are different, the output C will be very close to max(A,B). If A and B are similar, C will be max(A,B) + delta D, or very close to both A and B.

There was a widely publicised article recently Gamma error in picture scaling that highlights a bug in many image processing applications where arithmetic is done on gamma-compressed pixels, rather than in a linear space.

So to reference your problem where star trails rotate over a brightening twilight sky, then:
1) Where the star is brighter than the sky, the star trail remains at a fixed brightness
2) Where the star is dimmer than the sky, then the star trail "disappears"
3) Where the star trail and sky are similar in brightness, there is a slight increase in the star trail brightness.

The maths is a simple Star A + Sky B = Output C, but this has to be done in a linear space (the input images need to be "un-gamma-ed").

Stephen
Growing
 
Posts: 44
Joined: Sat Jan 17, 2009 4:48 am
Location: Newcastle, Australia

Postby Growing » Tue May 25, 2010 5:55 am

Can you explain what sort of output you envision?


Well StarTracer seems to have excellent smarts for detecting the celestial pole given only a small amount of star rotation. In the spirit of "why use one program, when 10 loosely coordinated independently written DOS command line scripts can do the job" :-), I was considering the possibility of using StarTracer as input to other scripts that eventually feed into PTAssember.

So what I am looking for is to obtain from StarTracer some coordinates (eg roll, pitch, yaw) that locate the celestial pole relative to the roll, pitch & yaw of the input images to PTAssembler.

Having looked closer at StarTracer, this may be more difficult than I anticipated, since StarTracer:
1) Works on 1 image at a time (not a set of images like PTAssembler).
2) The celestial pole may be outside the input image (and may be unrepresentable depending upon the lens projection).
3) StarTracer appears to be designed to come after PTAssembler in the workflow, and not before.

I'm not sure if I fully understand, but, if I do, it sounds like Star Tracer works in a different fashion. Star Tracer doesn't start with an input pixel coordinates and then rotate it to find the output pixel coordinate. Rather, it does the opposite. It starts with an output pixel coordinates, does the "inverse rotation"and figures out what are the input pixel coordinates to sample to create that output pixel. It iterates over every output pixel in the final image one at a time and performs this calculation to find the corresponding input pixel(s) to sample.


I misunderstood StarTracer's internal operations.

What I anticipated (based on your earlier hints), was an extension to PTAssembler, that operated after input image alignment, and before final image rendering.

But StarTracer appears be a utility best suited to make star trails on a single rectilinear image (uncropped, but possibly stacked). In the case of panoramas, it can use the output of PTAssembler, but this has some limitations:

1) The choice of input projections is very limited in StarTracer compared to PTAssembler.

2) Great care needs to be taken to correctly set FOV, and a-b-c-d-e of the PTAssembler output. Presumably one would aim for zero distortion in the PTAssembler output, but d&e are affected by cropping, which also affects FOV.

3) StarTracer appears to produce the same projection as output as it was given as input.

4) StarTracer cannot use "out-of-frame" input to produce "in-frame" output. For example stars that are out of view cannot rotate into view during the star trail creation.

5) If the desired final image projection is something more advanced than rectilinear/cylindrical/equirectangular, then the output needs to be fed back into PTAssembler. PTAssembler is best suited to using rectilinear images as input (for example, input images need to be all the same projection). But rectilinear images have severely limited FOV. But by using cylindrical or equirectangular images in StarTracer, then the star trails cannot be added back into the PTAssembler pano along with the original camera images.

If instead StarTracer were available inside PTAssembler, it would seem to me to simplify the process of creating panoramic star trails:

1) All input images can remain rectilinear (or any PTAssembler acceptable inputs).

2) The determination of the celestial pole is done once, and applies to all input images.

3) Stars outside the final image crop can freely rotate into view.

4) There is no limitation on output projection. Nor is it required to precisely know the output projection parameters (a-b-c-d-e & FOV).

5) The determination of FOV and input image distortion can be much better calculated by PTAssembler using camera images than StarTracer using images after much manipulation and reprojection.

Presumably it would offer a choice of separate image and star-trail output images (precisely aligned) allowing for final tweaking and masking in PhotoShop, or a single combined image (with an additional star/ground mask step required).

I guess I had my heart set on a tool for creating panoramic star trails (something that was previously impossible), rather than single image star trails (something that was once easy but time consuming on film, but now is just awkward with DSLRs).

Stephen
Growing
 
Posts: 44
Joined: Sat Jan 17, 2009 4:48 am
Location: Newcastle, Australia

Postby dsp » Tue May 25, 2010 9:11 am

Growing wrote:
If A and B are different, the output C will be very close to max(A,B). If A and B are similar, C will be max(A,B) + delta D, or very close to both A and B.

Stephen


This is essentially a lighten blend mode with a little biased dither around when A~B. I just haven't thought enough about what I expect to perceive when the star and background sky are similar in overall luminous intensity, but the color is different. I guess it also depends of the rendered scene's apparent absolute intensity (think photopic vs scotopic vision). In truth, these things probably are not important since star trail scenes aren't exactly the natural scene that people register when looking at the sky...
best regards, Darcy
dsp
 
Posts: 580
Joined: Tue Feb 20, 2007 11:09 am
Location: Hoboken, NJ


Return to Star Tracer and Image Stacker

Who is online

Users browsing this forum: No registered users and 0 guests

cron