Blending very large numbers of files
Matthew Gates
I have data for a full sky astronomical catalog which is comprised or
a large number of 256x256 jpeg images.
There is about 50 gig of data in total, at multiple resolutions.
I don't want to make a panorama, but I do want to modify the image
tiles so that blend together more smoothly than they currently do.
Can hugin and/or related tools help with this?
Many thanks,
Matthew Gates
kfj
individual images with nona so that they all fit together nicely. If
you want them all to fit together - so that they could theoretically
be stitched into a panorama - you have to first make up your mind what
projection to use. I think popular choices for the whole sky are
stereographic and fisheye projection. Do you have stellarium?
http://www.stellarium.org
(You may not even want to use your astronomical catalog once you have
it ;-) - there you can have a look at different projections and pick
one you like. Then you'd have to position the images in the output
space. Since they are astronomic images, I suppose you'll have
declination, rectascension and field of view for each of them. A bit
of a dicey issue is lens distortion, though - if your images are
photographs after all. You can only work that one out if you have
reference images for every used resolution. Then you try and match as
many stars on the reference with stars on an image - preferably in a
well-poulated area of the sky, on evenly distributed stars, and
optimize for v, a, b and c. You can create these reference images with
stellarium by doing screen shots when you have the area in question in
view. See also
http://www.johnhpanos.com/starcal.htm
One problem remains, and that is that you can't map a spherical
surface (the sky) to the plane without intoducing distortions
somewhere. So if you want all the tiles to fit smoothly, some of them
will be so warped you won't recognize anything on them (just look at
an equirect's poles). So maybe you'd be better off picking sizeable,
but not too big patches of the sky (like, 15 by 15 degrees) and making
the images inside these patches fit nicely, but leave it at that.
with regards
Kay
Matthew Gates
> individual images with nona so that they all fit together nicely.
No need. They are already fit together nicely. What I'm after is the
blending of edges.
> Do you have stellarium?
>
> http://www.stellarium.org
Yes, I'm a developer on the project :-). The images in question make
up part of a full sky survey which we are trying to add to the
program. The problem is that there are visible edged between tiles:
http://porpoisehead.net/images/dss_blend_needed.jpg
This image shows some of the Northern hemisphere with tiles we have
imported so far. These are only the lowest resolution tiles... as one
zooms in, higher resolution tiles are loaded (several per visible tile
at this lowest resolution. This is somehow similar to how projects
like OpenStreetMap have multires image sets).
If you want to try it out, check out an build the toastImages branch
from launchpad.net.
So many I could have been clearer: I want to feed in pre-distorted
images and get them out with only the color and brightness blending
done.
Thanks
Matthew
kfj
>...
Ha! Pleased to meet you. So I don't have to convince you of
stellarium's merits. Thanks for the nice software!
> The images in question make
> up part of a full sky survey which we are trying to add to the
> program. The problem is that there are visible edged between tiles:
>
> http://porpoisehead.net/images/dss_blend_needed.jpg
tiles were brighter towards one corner, with some colour variation
from blue to reddish thrown in. Hugin's notion of brightness
variations are that they are a function of radial distance from a
point, so it can deal with vignetting, but the data at hand look like
as if there's maybe also a gradient on them, which hugin couldn't deal
with. Mind you, if it can be conceived of as vignetting, it should be
possible, and it doesn't matter if the vignetting is off-center. As
far as the chromatic variations are concerned, I'm more pessimistic.
> This image shows some of the Northern hemisphere with tiles we have
> imported so far. These are only the lowest resolution tiles... as one
> zooms in, higher resolution tiles are loaded (several per visible tile
> at this lowest resolution. This is somehow similar to how projects
> like OpenStreetMap have multires image sets).
Are the images in a place where one could access them, to have a more
in-depth view - and also at the metadata to see how feasible it would
be to take them in en masse and run them through some batch job? If I
could get my hands on some of them, I'd gladly see what I can do to
help you.
> So many I could have been clearer: I want to feed in pre-distorted
> images and get them out with only the color and brightness blending
> done.
with regards
Kay
Matthew Gates
> stellarium's merits. Thanks for the nice software!
:) Thanks.
>> http://porpoisehead.net/images/dss_blend_needed.jpg
>
> Okay, I see now. What sort of distortion is that?
It's a bit complicated, and I don't have all the details, so this
description might need to be amended if we need to probe into it in
more detail.
The DSS tiles are split from large, high resolution photographic
plates which are themselves subject to distortions due to the optical
properties of the telescope used. I can find a detailed description
of the distortion if necessary. It's not a standard barrel distortion
though.
We chop these plate images into slightly overlapping tiles, run them
though some programs which remove the plate specific distortion
preparing them for the toast projection method:
http://www.worldwidetelescope.org/docs/worldwidetelescopeprojectionreference.html
Stellarium reads these tiles, knows about the toast projection and
translates this into sky coordinates "unwrapping" the tiles onto the
sky. Stellarium itself can project the curved sky onto the screen
with multiple methods, but this is not important for processing the
images.
> It looks like the
> tiles were brighter towards one corner, with some colour variation
> from blue to reddish thrown in. Hugin's notion of brightness
> variations are that they are a function of radial distance from a
> point, so it can deal with vignetting, but the data at hand look like
> as if there's maybe also a gradient on them, which hugin couldn't deal
> with. Mind you, if it can be conceived of as vignetting, it should be
> possible, and it doesn't matter if the vignetting is off-center. As
> far as the chromatic variations are concerned, I'm more pessimistic.
There are many factors here. Vignetting is probably a large part of
it. Individual tiles may come from close to or far from the optical
axis of the telescope which was used to create them, so if it's
possible to have the center of the vignetting compensation be far
outside of an individual image, that might work well. The exact way
the vignetting affects the image is probably not quite the same as
with normal camera lenses, but I dare say it is well documented and
details can be found if necessary.
The original plates were taken over a long period of time, so there
will be plate-to-plate variations which are much harder to compensate
for - atmospheric conditions when an individual plate was exposed such
as dust and water vapor in the atmosphere, altitude angle and so on,
scattering of light from bright objects such as the moon and planets
and so on.
>> This image shows some of the Northern hemisphere with tiles we have
>> imported so far. These are only the lowest resolution tiles... as one
>> zooms in, higher resolution tiles are loaded (several per visible tile
>> at this lowest resolution. This is somehow similar to how projects
>> like OpenStreetMap have multires image sets).
>
> ... or Microsoft's HD View.
>
> Are the images in a place where one could access them, to have a more
> in-depth view - and also at the metadata to see how feasible it would
> be to take them in en masse and run them through some batch job? If I
> could get my hands on some of them, I'd gladly see what I can do to
> help you.
The images can be downloaded, but it's hard to know which ones are
adjacent at a given resolution. I will try to research this.
Matthew
kfj
> The DSS tiles are split from large, high resolution photographic
> plates which are themselves subject to distortions due to the optical
> properties of the telescope used. I can find a detailed description
> of the distortion if necessary. It's not a standard barrel distortion
> though.
bit of the distortion. When I, sloppily, said distortion, I meant the
variations in brightness and colour.
> We chop these plate images into slightly overlapping tiles, run them
> though some programs which remove the plate specific distortion
> preparing them for the toast projection method:
>
Excellent projection. I'll post a link to it to this group. maybe
it'll inspire someone to utilize it for panorama output - if MS hasn't
patented it?
> Stellarium reads these tiles, knows about the toast projection and
> translates this into sky coordinates "unwrapping" the tiles onto the
> sky. Stellarium itself can project the curved sky onto the screen
> with multiple methods, but this is not important for processing the
> images.
TOAST projection? This would have warped the initial, probably
concentric, vignetting into a more complex shape. Wouldn't it be a
better idea to do the processing on the source images, before chopping
them up? Do you have access to them at that stage? I am only guessing,
but my feeling is that the image processing needed to make them
blendable nicely could be done without having to take into account
every small detail - it might suffice to define the procedure needed
at a low resolution and then just let it trickle down to higher
resolutions.
If you were to try to model the vignetting on lots of small tiles,
trying to undo an effect at the source image level, you introduce much
more potential error than working on the source images straight away.
But you may get away with figuring out the vignetting and mabe other
problems in the source images by looking at lo-res versions of them
and still come up with parameters suitable to treat them down to the
highest resolution.
> There are many factors here. Vignetting is probably a large part of
> it. Individual tiles may come from close to or far from the optical
> axis of the telescope which was used to create them, so if it's
> possible to have the center of the vignetting compensation be far
> outside of an individual image, that might work well. The exact way
> the vignetting affects the image is probably not quite the same as
> with normal camera lenses, but I dare say it is well documented and
> details can be found if necessary.
Hugin's workflow is
- identify overlaps
- make the images compatible geometrically and photometrically
- blend them nicely
The idea is to transform them so that they become as compatible as
possible and then let the blender decide where precisely the seam
should be put - but ideally, if they overlap, sections that are
covered by two images should look identical on the warped versions of
the two source images. So hugin could help you with making the images
compatible, but it is really quite specialized insofar as it is geared
towards photographs with the usual flaws that photography produces,
which is reflected in the transformations it can perform.
> The original plates were taken over a long period of time, so there
> will be plate-to-plate variations which are much harder to compensate
> for - atmospheric conditions when an individual plate was exposed such
> as dust and water vapor in the atmosphere, altitude angle and so on,
> scattering of light from bright objects such as the moon and planets
> and so on.
authenticity of the individual source images and how much on the
experience of a continuous overall display? If you think, for example,
of google earth, they seem to have chosen to take the satellite images
pretty much as they are and accept that there are discontinuities at
the borders. Maybe it would be acceptable to do that from some level
of resolution - like you could have the lower-resolution tiles more
modified towards a smooth overall display, changing emphasis to
fidelity to the original images as you step up the resolution. The
pyramid approach should give you that option.
Also, you have stellarium as a reference. You could simulate every
tile with stellarium, which should give you an idea about at least
some of the characteristics the image should have at in that area,
like average brightness (just a quick shot, the statistics could be
much more involved). Maybe you could use these data to brighten/darken
the corresponding real tiles.
> The images can be downloaded, but it's hard to know which ones are
> adjacent at a given resolution. I will try to research this.
with regards
Kay
Matthew Gates
>> Stellarium reads these tiles, knows about the toast projection and
>> translates this into sky coordinates "unwrapping" the tiles onto the
>> sky. Stellarium itself can project the curved sky onto the screen
>> with multiple methods, but this is not important for processing the
>> images.
>
> Now I'd like to know if the 256*256 tiles you have are already in
> TOAST projection? This would have warped the initial, probably
> concentric, vignetting into a more complex shape. Wouldn't it be a
> better idea to do the processing on the source images, before chopping
> them up?
That should be possible Creation of the tiles is long and intensive
process, but if we can do it once, we can do it again. I agree that
it makes sense to do the blending first, then chop up the tiles.
> Do you have access to them at that stage? I am only guessing,
Well, we have tarballs with the original plate jpegs split into small
chunks. That's how the data arrived to us after some processing by
another The tarballs contain sub-directories x1 x2 x4 etc. x1 is
the highest res. Don't worry about the rest of the directories, they
are just lower resolution version of the same data.
In x1 you will find the DSS plate split into tiles (64 x 64 = 4096
jpeg files at resolution of 300x300 each - if you were to recombine
them into the DSS plate, it would be a single 19200x19200 image).
There is also one meta-data file per jpg file. The exact contents and
format I am not familiar with, but I can find out.
An example DSS plate .tgz cab be found here:
http://porpoisehead.net/misc/S357.tgz (13 meg)
There are many of these files 1792 of these files - the one above is
the smallest. Total size ~65 gig! I love me some hefty data. :D
> but my feeling is that the image processing needed to make them
> blendable nicely could be done without having to take into account
> every small detail - it might suffice to define the procedure needed
> at a low resolution and then just let it trickle down to higher
> resolutions.
> If you were to try to model the vignetting on lots of small tiles,
> trying to undo an effect at the source image level, you introduce much
> more potential error than working on the source images straight away.
> But you may get away with figuring out the vignetting and mabe other
> problems in the source images by looking at lo-res versions of them
> and still come up with parameters suitable to treat them down to the
> highest resolution.
The x64 directories in the .tgz files might be useful here, as they
are full-plate at low res. We could maybe extract these, experiment
with blending and even stitch them together into a panorama to check
it. 1792 300x300 tiles isn't so bad.
I can do the extraction of this data on the server and create a single
archive file which should be a manageable size.
Pablo d'Angelo
Am 16.12.2010 18:49, schrieb Matthew Gates:
> An example DSS plate .tgz cab be found here:
>
> http://porpoisehead.net/misc/S357.tgz (13 meg)
>
> There are many of these files 1792 of these files - the one above is
> the smallest. Total size ~65 gig! I love me some hefty data. :D
Is there a summary of the "production" process for you data? I assume
the following:
1. You got the tiled DSS plate files from some observatory.
2. You have some software to reproject the tiles into TOAST.
If you want to try the hugin vignetting correction, one needs to know
corresponding pixels between the overlapping plates. There are two
possibilities:
1. Add support for the input image (plate) format to hugin, and write a
script that creates a PTO file from the metadata in the plate files.
Then the standard workfow could be used (on the x64 images). The
corresponding parameters could then be used for radiometric correction
of the individal plates. If we add the toast projection, to panotools,
it would be possible to directly output toast, otherwise its possible to
produce corrected plate images.
2. Keep all the geometry stuff outside hugin and produce a input file
for hugins vig_optimize tool with corresponding pixels within your
software. This should be a simple text file with the following format:
img1_nr img2_nr x1 y1 x2 y2 r1 g1 b1 r2 g2 b2 0 radius_1 radius_2 0
where r,g,b are the respective RGB values and radius is the distance
from the center, divided by the distance to the edge (if I remember
correctly). Together with a fake pto file, this could be feed into
vig_optimize to determine the correction parameters.
Looking at http://porpoisehead.net/images/dss_blend_needed.jpg
I'm a bit sceptical how well it might work with hugins vignetting
correction though. Do you know if the position of the plate in the
telescopes focal plane is available in the metadata? Do you have a
document describing the metadata?
> The x64 directories in the .tgz files might be useful here, as they
> are full-plate at low res. We could maybe extract these, experiment
> with blending and even stitch them together into a panorama to check
> it. 1792 300x300 tiles isn't so bad.
>
> I can do the extraction of this data on the server and create a single
> archive file which should be a manageable size.
For a first experiment, a smaller subset of the mosaic would be
sufficient, maybe a 5x5 grid. For this test, the alignment could be done
in hugin to avoid the steps I have mentioned before. The full data will
be a real challange, even when using the tiny images.
The full mosaic would be much simpler, if we had a "reference image"
that covers the whole mosaic. It only needs to contain the "background"
brightness, not all the stars etc. This would make the "vignetting"
correction much simpler and probably yield a nicer result.
ciao
Pablo
kfj
On 16 Dez., 18:49, Matthew Gates <matthew...@gmail.com> wrote:
> Well, we have tarballs with the original plate jpegs split into small
> chunks. That's how the data arrived to us after some processing by
> another The tarballs contain sub-directories x1 x2 x4 etc. x1 is
> the highest res. Don't worry about the rest of the directories, they
> are just lower resolution version of the same data.
the data correctly, x64 is the lowest resolution and shows the
complete plate, and the other directories offer tiles at various
resolutions, with the highest resolution images contained in x1, where
there are 64*64 =4096 images. The data don't look to me as if they
were suffering from significant vignetting. The background of the
image has a slight reddish tint towards the center in the order of
magnitude of 10 (out of 256), but I don't think that would translate
into such a visible effect as can be seen on your sample stitch image.
So I'm a bit puzzled - is this maybe just one plate where the problem
we're trying to tackle isn't so visible? At any rate, to get an idea
of the overall quality of the data, it would be useful to have a set
of x64 plate images, covering an area of - or even better, the whole
sky. If you have the data uncompressed somewhere you could just lump
them together with a command like (including the appropriate metadata)
tar cvf x64.tar S*/x64/*.jpg S*/x64/*.hhh
The resulting tar file would be smaller than one of the pyramids,
since it would only contain 1792 images, one for each tar ball.
My reasoning here is that any vignette-like effect would be perfectly
visible on the x64 image, the higher-res tiles would not offer too
much extra information for the purpose at hand. The 1792 images at the
lowest resolution would offer an idea of the overall problem and need
for processing and, therefore, be more useful than an arbitrary
pyramid with all resolutions - I suppose the x64 image is nothing but
a compressed composite of the higher-res tiles anyway.
The tiles come with a cornucopia of metadata, most of which exceed my
admittedly narrow astronomic horizon - what I seem to have gleaned,
though, is that the projection is gnomonic and localization of the
individual images should be easy straight from the metadata. What I
need for a trial stitch in hugin (from which we might be able to
derive the vignetting data) is translation of the astronomical
nomenclature in the hhh files into hugin's system. Hugin uses a notion
of roll, pitch and yaw. I suspect roll will be zero for the images,
pitch would refer to the center of the image and be in degrees from
the equator and yaw to the center of the image in degrees from any
reference point on the equator you care for, maybe you could point me
to which of the metadata to touch for the purpose and how to translate
them, if necessary. I suspect the relevant data are in the 'Hour
Angle' and 'Zenith distance' data fields in the hhh file, hour angle
could be translated straight into yaw, and Zenith distance would be
pitch + 90 degrees? I could then extract them from the hhh files.
Alternatively, put small files with the images containing roll, pitch
and yaw in degrees - then I wouldn't have to do the extraction
myself ;-)
> The x64 directories in the .tgz files might be useful here, as they
> are full-plate at low res. We could maybe extract these, experiment
> with blending and even stitch them together into a panorama to check
> it. 1792 300x300 tiles isn't so bad.
>
> I can do the extraction of this data on the server and create a single
> archive file which should be a manageable size.
with regards
Kay
kfj
On 17 Dez., 08:09, Pablo d'Angelo <pablo.dang...@web.de> wrote:
> If you want to try the hugin vignetting correction, one needs to know
> corresponding pixels between the overlapping plates. There are two
> possibilities:
>
> 1. Add support for the input image (plate) format to hugin, and write a
> script that creates a PTO file from the metadata in the plate files.
> Then the standard workfow could be used (on the x64 images). The
> corresponding parameters could then be used for radiometric correction
> of the individal plates. If we add the toast projection, to panotools,
> it would be possible to directly output toast, otherwise its possible to
> produce corrected plate images.
I've had a look at the attached metadata and it does look like it's
all there (wish all the other incoming images were only half as well
documented - these astronomers sure are precise...)
> Looking athttp://porpoisehead.net/images/dss_blend_needed.jpg
> correction though.
> Do you know if the position of the plate in the
> telescopes focal plane is available in the metadata? Do you have a
> document describing the metadata?
time right bang in the middle where the focal point of the mirror is.
Center of image = optical axis, which should be normal to the image
plane. Then leave the plate there for an hour with the telescope
slowly rotating to make up for the earth's rotation, then next plate -
as long as the night lasts and there are no clouds. Matthew, please
correct me if I'm wrong.
> For a first experiment, a smaller subset of the mosaic would be
> sufficient, maybe a 5x5 grid. For this test, the alignment could be done
> in hugin to avoid the steps I have mentioned before. The full data will
> be a real challange, even when using the tiny images.
a measly 161 Megapixels, transfer volume much less since the JPGs are
quite cruelly compressed [this surprises me - I'm almost certain the
true source data would not be JPG and the pyramids at hand are already
a few steps down the processing pipeline...] The real work is writing
the script from the metadata. Also it seems to me that the problems
are more pronounced in some areas than other. Best to have the full
x64 set.
> The full mosaic would be much simpler, if we had a "reference image"
> that covers the whole mosaic. It only needs to contain the "background"
> brightness, not all the stars etc. This would make the "vignetting"
> correction much simpler and probably yield a nicer result.
they are so precisely located, this stitch should come out really
well.
with regards
Kay
Matthew Gates
> The tiles come with a cornucopia of metadata, most of which exceed my
> admittedly narrow astronomic horizon - what I seem to have gleaned,
> though, is that the projection is gnomonic and localization of the
> individual images should be easy straight from the metadata. What I
> need for a trial stitch in hugin (from which we might be able to
> derive the vignetting data) is translation of the astronomical
> nomenclature in the hhh files into hugin's system. Hugin uses a notion
> of roll, pitch and yaw. I suspect roll will be zero for the images,
> pitch would refer to the center of the image and be in degrees from
> the equator and yaw to the center of the image in degrees from any
> reference point on the equator you care for, maybe you could point me
> to which of the metadata to touch for the purpose and how to translate
> them, if necessary. I suspect the relevant data are in the 'Hour
> Angle' and 'Zenith distance' data fields in the hhh file, hour angle
> could be translated straight into yaw, and Zenith distance would be
> pitch + 90 degrees? I could then extract them from the hhh files.
> Alternatively, put small files with the images containing roll, pitch
> and yaw in degrees - then I wouldn't have to do the extraction
> myself ;-)
I hope Fabien will join in the conversation here. He's been dealing
with the processing of these images into the toast projection and so
is much more familiar with this stuff than me.
>> The x64 directories in the .tgz files might be useful here, as they
>> are full-plate at low res. We could maybe extract these, experiment
>> with blending and even stitch them together into a panorama to check
>> it. 1792 300x300 tiles isn't so bad.
>>
>> I can do the extraction of this data on the server and create a single
>> archive file which should be a manageable size.
>
> Sounds very good; I fully agree, hope to see the data soon!
Here's a tarball with the x64 images and their associated meta-data files:
http://porpoisehead.net/misc/dss_low.tar.gz (~11 meg)
I'm assuming the N??? ones are for the Northern hemisphere and the
S??? files are for the Southern hemisphere, but this should become
apparent from the metadata analysis.
Matthew
Fabien
I'm Fabien from Stellarium brought here by Matthew.
> Here's a tarball with the x64 images and their associated meta-data files:
>
> I'm assuming the N??? ones are for the Northern hemisphere and the
> S??? files are for the Southern hemisphere, but this should become
> apparent from the metadata analysis.
So I am not not completely sure what we need as input: I think for
what we need we can make the assumption that the plate projection is
gnomonic. In this case I can extact the lon/lat positions of the 4
corners of each plate. Then what do we need to do with that? Can
the .pto be generated from just that?
Fabien
> Matthew
kfj
On 17 Dez., 15:02, Matthew Gates <matthew...@gmail.com> wrote:
> Here's a tarball with the x64 images and their associated meta-data files:
>
> http://porpoisehead.net/misc/dss_low.tar.gz(~11 meg)
>
result. I'd like to discuss my assumptions about the metadata, while
hugin is having a hard time swallowing a pto file with almost 900
images ;-)
obvious:
- The metadata are organized in 80-character blocks
- The heading 8 characters, followed by a '=' sign, contain the field
name
- next are 30 characters are value, followed by an optional comment
what I extracted:
- I have taken the field CRVAL1 (commented: Rectascension of the
reference pixel)
- And the field CRVAL2 (Declination of same) as yaw and pitch, roll
zero
- I have assumed the hfov to be 6.6266 degrees approximately, but I'm
unsure here:
it's half-guessed, combined from the fields:
PLTSCALE= 67.2000 /Detector: Plate Scale arcsec per
mm
PLTSIZEX= 355.000000000 /Detector: Plate X dimension
mm
and this may well be wrong. please help me with the field of view -
I'm not sure if the whole plate dimension goes into the 300X300 tile
or just some part of it.
- there are the fields CRPIX1 and CRPIX2, each valued 61.0, denoting
the
'X Refernce and Y Refernce Pixel'. Does this mean that the
rectascension and
declination do not refer to the tile center? I need help with that,
as well.
I batch-extracted the metadata with a python script which wrote out
the pto file, the pto goes like
p w2000 h1000 f2
o n"N002_00_00_x64.jpg" w300 h300 f0 v6.626666 r0.0 y15.701600
p83.455875
o n"N003_00_00_x64.jpg" w300 h300 f0 v6.626666 r0.0 y53.398000
p83.397969
...
I did a trial stitch with a subset of about 100 images and it came out
looking plausible, but with stars it's of course hard to tell if the
overlap is right. Currently I asked hugin to do a sample stitch with
the whole northern data and my assumed positions and fovs, this should
take a long while if it succeeds at all. I'll keep you posted, it
would be nice if you could help with the metadata.
with regards
Kay
kfj
On 17 Dez., 17:51, Fabien <fabien.cher...@googlemail.com> wrote:
> Hi,
> I'm Fabien from Stellarium brought here by Matthew.
yours came in
> Yes N stands for North, S for South.
> So I am not not completely sure what we need as input: I think for
> what we need we can make the assumption that the plate projection is
> gnomonic. In this case I can extact the lon/lat positions of the 4
> corners of each plate. Then what do we need to do with that? Can
> the .pto be generated from just that?
assumptions here. For the pto to work, our reference needs to be to
the center of the tile and we need the horizontal field of view. I'll
have to dig into the reference if hugin can take gnomonic source data
- if not, it shouldnt'be too hard to transform to rectilinear, though
every transformation degrades the data. For my trial I've assumed
rectilinear which shouldn't be too far off for an initial test (or
isn't it even the same, come to think of it?). The precise field of
view of the actual 300X300 tile is absolutely crucial to make the
overlap correct. the other issue concerning the precise location of
the refernce point is as crucial - if the reference is to another
point than the center, the RA/Dec values have to be recalculated for
the image center, which shouldn't be too hard. I'd need to know where
(0,0) is, though - bottom left with y up?
Apart from that I see no problems - if hugin can't swallow the lot in
one go, we can just make like two dozen strips and blend them in a
second step - my hugin job is already done warping and the blender is
half done loading the warped tiles.
Once these initial technicalities are dealt with we can proceed to
deal with the real issue, which is the detection and possible removal
of assumed vignetting artefacts.
with regards
Kay
kfj
stitch a reasonable product. this looks fine without any vignetting
correction, which fits well with my initial judgement that the slight
background brightness variations should be hardly noticable in the
output. I have a suspicion about the source of your brightness
variations. I suspect you have not masked out the bright spots that
occur in one corner of every plate. These are often white, sometimes
orange, sometimes mulicoloured, and it is seemingly arbitrary in which
corner they occur. I did a trial stitch where I did not mask them out
and the result looked quite like
http://www.google.com/url?sa=D&q=http://porpoisehead.net/images/dss_blend_needed.jpg&usg=AFQjCNEp9PMwvLRVsiuPw76sGDXRLE9AUw
When I did mask the bright corners out (manually did that for 100
images around the N pole, where is N001, anyway?) the brightness
fluctuations were gone.
Please doublecheck if this is maybe the cause of your problem. Keep in
mind that a multi-resolution blender (like enblend) will produce the
seeming 'bleeding' of bright areas to surrounding areas, so their
effect extends beyond the extent of the bright area.
with regards
Kay