Charts II: NGA - 2700 Charts

[LeaseOnLife]

Originally Posted by allanpeda

I see this problem:

convert: unable to open image `7-55-32.jpg'

There is a convert: unable to open image 7-55-31.jpg and 7-55-33.jpg but the intermediate is not there.

yep, ruby script fails too.

[Surveyor]

Originally Posted by allanpeda

I see this problem:

convert: unable to open image `7-55-32.jpg'

There is a convert: unable to open image 7-55-31.jpg and 7-55-33.jpg but the intermediate is not there.

Index of /NGAViewer/52047/TileGroup12
Index of /NGAViewer/52047/TileGroup13

31 and 33 are both plain white with no other colors. You could "make" a 32 by copying 31 or 33 and naming it properly.

[Netsurfer]

Originally Posted by Surveyor

31 and 33 are both plain white with no other colors. You could "make" a 32 by copying 31 or 33 and naming it properly.

Yes, but be aware that they are both 168 x 256 in size and not 256 x 256.
Depending on the way you stitch the images this might be important (or not).

Gunther

[cagney]

You can now upload your chart picture files again.
Full instructions here: NGA Charts Upload Files at OpenCPN.info (English)
You have to use an FTP client, but full instructions are provided.
I just followed them myself, as my old trusted ftp program wasn't quite up to the task. 10 minutes and you can be uploading.
Thanks Netsurfer for all your efforts, in setting up this.

Thomas

[nohal]

Just a note:
No need to upload again what's already sent to my server, we will do the synchronization on server side.

Pavel

[LeaseOnLife]

Originally Posted by cagney

I don't have the original! Also I cropped the original chart containing two inserts after converting. You can always download the original, crop the A insert and use my header. Get the header from the kap file, just copy the text in the beginning. You would have to adjust the pixelcount though.
REF1 starts in lower left corner and then proceed clockwise.

I can't see any point in converting to png the way you suggest. Most likely you will end up with a larger file, with no gain.

Thomas

Thomas

As an exercise, I went thru my current standard procedure

• Downloaded and stitched by ruby script.
• extracted/cropped the chartlet with xnview, saved as png
• resized to 50% and saved as png using nconvert
• calibrated using MapCal
• mc2bsbh to create hdr from CHARTDIR.CAL, renamed hdt to txt
• imgkap -n to create kap with 127 colors
• for the screenshots I uses bsb2png and cropped the thumbnails with xnview

Result: kap file is 7.1MB instead of 3.9MB

but the result in quality is significant. For the 1st picture the original image was reduced to 40%, for the 2nd picture the resize was to 50%, that explains the different size. Despite that, there is significant noise in the 1st, much less in the 2nd.

In my book, I would trade HD space for better quality.

kap file and working files are here:
http://www.4shared.com/folder/Nre2n96r/24375.html

[bcn]

Originally Posted by cagney

You can now upload your chart picture files again.
Full instructions here: NGA Charts Upload Files at OpenCPN.info (English)
You have to use an FTP client, but full instructions are provided.
I just followed them myself, as my old trusted ftp program wasn't quite up to the task. 10 minutes and you can be uploading.
Thanks Netsurfer for all your efforts, in setting up this.

Thomas

52039 to 52143 are uploaded.

As we are in "stand-by" about compressing/creating the kap:s I will start now to download the 53011 - 53133 range.

In our case download/stitch at 75% Q is about 50min/file

Cheers

Hubert

[Surveyor]

I am uploading but it is going to take 95 hours! 17gb @ 52kb/sec

I can mail you dvds!

4 more files I could not grab:
97412
97440
97460
97465

That completes 91004 to 97564!!!

[allanpeda]

BTW, 4shared optionally allows files to be downloaded via bittorrent:

Download from 4shared with BitTorrent clients! | 4shared blog

[LeaseOnLife]

Originally Posted by Surveyor

4 more files I could not grab:
97412
97440
97460
97465

added to my list.

16 of your missing files are here, so far no misses:
http://www.4shared.com/folder/XtRsJgsN/Region-9.html

I hope you grab them and upload them, right? Would be good if complete sets are kept somewhere else than just one server...

[LeaseOnLife]

Compatibility with Raytech and Fugawi, need to create a bsb file for a kap file.

Fugawi can import the kap files we produce via "Maps/Map tools/Import/BSB (Non MapTech)". I was trying to figure out why the import via "Maps/Map tools/Import/BSB-Maptech" doesn't work:

It needs a *.bsb file for a corresponding *.kap file. Sometimes one bsb file is enough for a couple of kap files (see NOAA chart 50_1 and 50_2).

By trials I learned, also Raytech needs this BSB file to import kap files.

I tried to craft my own BSB file with no luck so far. It is just a text file, similar to the kap header. Does someone here know more about the bsb files?

NavPak wrote about a leaked, but incomplete, BSB spec. Where can I get this spec?

Thanks!

Dirk

[cagney]

Originally Posted by bcn

52039 to 52143 are uploaded.

As we are in "stand-by" about compressing/creating the kap:s I will start now to download the 53011 - 53133 range.

In our case download/stitch at 75% Q is about 50min/file

Cheers

Hubert

Note that all downloads must be at 100% Q.
with a command line similar to this.
This is no problem with the ruby script.

dezoomify.py -i /home/thomas/Testing/NGA/Fulldown.txt -l -q 100 -d -o /home/thomas/Testing/NGA/output.jpg

-q must be set to 100, otherwise it defaults to 75!

All uploads must be the "raw" 100% picture where only stitching has been used on the individual tiles.

Thomas

[bcn]

Thomas,

changed the py parameters - sure you have seen the "Output quality over 95% is discouraged due to large filesize without useful quality increase - continue y/n"....

Hubert

[cagney]

Originally Posted by bcn

Thomas,

changed the py parameters - sure you have seen the "Output quality over 95% is discouraged due to large filesize without useful quality increase - continue y/n"....

Hubert

Yes I/we have. Just answer "y". What we are doing is trying to save every bit of available "quality" there is in a jpg.

Thomas

[r.fairman]

I agree the jpgs must be 100 % copies of the files that NGA holds. It is dangerous to archive these files at less that 100% by doing some preprocessing. Our fall back must allways be to be able to go back to the saved .jpgs