Charts

[thatboatguy]

Good stuff guys, I'll give it a shot while we are in Marsh Harbor for a couple days.

Many thanks

George

[HappySeagull]

Originally Posted by jonasaberg

I strongly recommend not using jpg for charts. This is based on how the format stores the data.
jpg is a lossy format. It throws away data during the compression. This is ok for images that change continuously like photographies but not for images with lines, or i.e charts with distinct areas of different color.
In this case it is much better with a bitmapped format such as png, gif, bmp... it keeps all the information in the image.
jpg will get more and more blurry for every transition.

/Jonas

Hi-only commenting for interest' sake-I'm a "tif" man myself (but Map_Cal2 doesn't like tifs!) ..anyways,

My photo app (Faststone or Irfan)tells me it's saving "loss-lessly".I suspect it means that it is at least saving the jpeg at it's original compression...?I've read it's really bad to compress originals further;to check the settings in your favourite photo app before saving!But conversely,that it's a waste of disk to re-save an already-compressed image at less compression....?

And then too,I recall others here have only found certain charts available as jpegs...

I guess the happy mediium would be to save jpg charts in a non-degenerative format right away?... or not?hmmm.

[sinbad7]

I have used compressed .jpg's for a long time without any visible screen degredation.
How else do you compress file size? My end product is a 127 color .png file which produces a very acceptable chart,in fact more dense and focused then the original. Anyway,most suitable bitmaps comes in .jpg.
This process will of course only be done once and not repeatedly as suggested.

See attached chart.
Unalaska-Amukta Isl.kap - 4shared.com - online file sharing and storage - download


Tore

[HappySeagull]

...and my point-and-shoot camera on gives jpegs.It'd be too sad if they faded like old-school photos!Oh well,it's that format bugbear again!

[dacust]

Originally Posted by sinbad7

I have used compressed .jpg's for a long time without any visible screen degredation.
How else do you compress file size? My end product is a 127 color .png file which produces a very acceptable chart,in fact more dense and focused then the original. Anyway,most suitable bitmaps comes in .jpg.
This process will of course only be done once and not repeatedly as suggested.

See attached chart.
Unalaska-Amukta Isl.kap - 4shared.com - online file sharing and storage - download


Tore

OK, here goes.

First, you may well be getting quality charts that look just fine the way you are doing it. So, in your real life situation, what you are doing is fine. However, that doesn't mean the methods you are using are the best. you MAY hit a situation where doing it your way gets worse results. So, for that reason, it's worth discussing what those methods are.

First:

• A .jpg is NOT a bitmap.
• If the original is a .jpg, then fine. Use it. But I would convert it to something lossless (.png, .tif, .bmp) before reducing color depth, etc.
• Compressing a .jpg and then converting it to a .png does not save you any space. The space saved will be based on the final format used. In fact, due to the fuzziness of the .jpg, the resulting .png may actually be slightly larger. Don't confuse compression with color depth or DPI changes.
• Reducing DPI will degrade the image. Especially when not reducing in a cube. It has to dither the pixels to reduce from, say 96-72.
• The fact that a screen can only displyay 72 DPI is not the point. If you reduce the image to 72 then you can show the image at 100% with perfect quality (well, minus the degradation from the conversion). If it is at 96 DPI, you can show the image zoomed in on the screen at 133% and still have perfect quality.

Now, the results of most of the above will produce changes that may or may not be visible to most people's eyes. So you MIGHT not notice any difference at all.

The point is, when doing a process with as many conversions as this, it's best to keep the losses down at each step.

If you always do things in the more-loss methods, then you will never find out when you hit a condition that the lossless way WOULD produce a noticeable improvement.

SO, I try to use the lossless ways as much as possible.

The BEST ways I know to save space in chart creation is to convert to a lossless palette style format first, then:

• Reduce color depth. Open it in a viewer and compare it side by side with the original. Try it at different color depths. Look at the file sizes. Find the lowest color depth that it still looks good.
• Change DPI. Check this out in a viewer as well. Make sure it still looks good at the closest zoom level you plan to view it.

Myself, I have plenty of disk space, so I don't ever change DPI, and I leave color depth rather high. But that's just me.

-dan

[idpnd]

JPEG can be used at a lossless setting (but usually it isn't).

Anyway, if the chart comes in JPEG and you're not recompressing it in jpeg as part of your process, and quality loss is not your fault

[HappySeagull]

Dacust,ipnd,Sinbad7.thanks.Good info,good discussion because
I think the "image" part of chart making and conversion deserves a close look,now that there's these greattools.. (libbsb,map2kap,Map_Cal,mc2bsbh,tiff2kap,GE2KAP,ch artconvert,etc) that can convert images to kap...for me,the first thing is not to lose the overall size of the image and second not to lose its original detail.

A question...why is the choice of colour depth in several of the conversion tools above restricted to 128 colours?(127 being weirder yet1)of course ,16 or 64 colours is fine for charts,128 is,mm, ok for GE..but I think that the store-bought charts all report as 256...and they are really tifs-with-headers,aren't they?

Another question:why does imagemagick (using convert.exe) first convert the input image to a gif before outputting a tif?

[jonasaberg]

...it is interesting how things goes around. A lot of effort went into understand this about a year or two ago. It is all in the beginning of this thread...

About seven pages into the thread it was realized that a tif file can store colours in two ways:
1. As RGB. This kind of mean that every pixel in the image is affiliated with a RGB tripple. So every pixel can have a combination of colours based on how many levels of Red Green and Blue that are used.

2. Using a palette. That is. First a palette is defined with a set number of allowed colours. Could be for example 127. Then every pixel of the image refers to which of these 127 colours that the pixel should have.


A tif file with RGB colours can NOT be used when creating a kap file.

The workaround is to convert the tif file that use RGB coulours to a gif file because gifs can only use a palette. This mean that the RGB colours in the image is converted to a palette when creating the gif.

When the gif file is converted back to a tif file the palette is kept.

So by always passing the "gif" stage we know for sure that the "tif" uses a palette, and then the conversion to kap will work.

Piece of cake, heh! ;-)

/Jonas

[GPS-Marco]

Originally Posted by jonasaberg

...
The workaround is to convert the tif file that use RGB coulours to a gif file because gifs can only use a palette. This mean that the RGB colours in the image is converted to a palette when creating the gif.
...
/Jonas

Actually, passing through a gif format is only a workarond needed to overcame a bug (never corrected) of imagemagik.

In fact if you use other conversion tools (xnview, as example) you can convert an RGB tif to a Palette tif without the need to pass through a gif file.

In KapGen I use nconvert.exe (xnview command line converter) and the command may be simply:

nconvert -colors 64 -out tiff -c 2 -o OutImage.tif InImage.tif

Unfortunately nconvert has a limit: it can only convert to 2^n colours (2,4,8,...,128,256) so, to use the image in libbsb you have to convert to max 64 colours.

Ciao, Marco.

[jonasaberg]

Marco,
You are correct as always.

They key point is of course the need to create a palette based tif for the kap creation.

/Jonas

[HappySeagull]

Originally Posted by GPS-Marco

Actually, passing through a gif format is only a workarond needed to overcame a bug (never corrected) of imagemagik.

In fact if you use other conversion tools (xnview, as example) you can convert an RGB tif to a Palette tif without the need to pass through a gif file.

In KapGen I use nconvert.exe (xnview command line converter) and the command may be simply:

nconvert -colors 64 -out tiff -c 2 -o OutImage.tif InImage.tif

Unfortunately nconvert has a limit: it can only convert to 2^n colours (2,4,8,...,128,256) so, to use the image in libbsb you have to convert to max 64 colours.

Ciao, Marco.

Thanks Jonasaberg and again,Marcos!-the gifs thing has bugged me and it's time-consuming in it's process isn't it?but the results are good and I assume from its popularity that it's command lines are very accessible,that it's library is comprehensive...Still,I devolve to use Irfanview and it's GUI to make tifs.It's not open source so it's off the table for you developers?and other reasons too no doubt..but,for the "user",it has a Custom option for "number of colours" and if I use 128(for Google Earth ),it works perfectly fine in libbsb.It looks a little better than 64.while xnview's 128 colours didn't work-really odd..(doublecheck: I get the histogram for the tif in FSViewer,it confirms 128 colours, if I can trust it!)

Jonasaberg,THAT is a good tip and explain per Palette....I never knew what that was -it might explain trouble I had with FSViewer tifs.A too-well hidden dialogue exists where choices include "RGB_Palette" and "RGB"-in Irfanview,it's not there as such but the tifs work fine)...?
Darn,it's tricky!But I'm keeping notes!

Now,one more question while the people who know are in a mood to talk!-why cannot tif2bsb handle 256 colours?(Pardon me if I missed it..)

[cagney]

[QUOTE=HappySeagull;639543....-why cannot tif2bsb handle 256 colours?...[/QUOTE]

It's a limitation with the original bsb format, that libbsb has to "police".

Thomas

[HappySeagull]

Aah,so!Thanks!...I'm reading the whole thread -the nuggets in here!- but it's hard to sift it per just "images" as you all have done for me here!

[dacust]

Reprinted by permission of the author (me) from the mc2bsb page, just in case you relly want some more in-depth details:

***********************************************

It was discovered that tif2bsb didn't seem to want to work on a tif that was converted from a jpg or bmp. Now, this was annoying. Someone told me from the error, that it was because the tif had been created in RGB format instead of palette format. They explained that a tiff can be either format. If a RGB format (bmp/jpg/etc) was converted to a tiff, evidentally ImageMagick made the tiff RGB as well. So, the suggestion was made to first convert it to a gif, which is ONLY palette format. Since no one yet to come up with a single step way to do it, that's what we do. Convert jpg-gif-tif.

For people that have requested it, here is a longer explanation.

Raster vs. Vector.

There are two basic types of graphics. Raster and vector. Raster images have information for each and every pixel in the image. Vector graphics has information on the objects to be displayed. Like, it may have a definition of a line type of so may pixels wide, and dashed with the solid parts twice as long as the blank parts. Then, it will say to draw that type of line from this x/y position to that x/y position. In other words, a raster graphics has the picture while vector graphics has instructions on how to draw the picture.

RGB vs. Palette images.

For raster graphics, there are two basic ways to store the color of the pixels. RGB (Red/Green/Blue) stores a separate number for each of the colors for the intensity of each. So, a pixel might have 255, 255, 255 which is black. Or 0,0,0 which is white. Or 255,0,0 which is red. So, it has this set of three numbers for each and every pixel for the image. Palette does it different. It has a table of all the colors used. So it may say color 1 is 255,255,255 and color 2 is 0,0,0 and color 3 is 255,0,0. Then, after that table, it just has the color number for each pixel. So, it only stores just one number for each pixel.

Now, I'm not going to go into the advantages and disadvantages of each type, but basically, if you only have a few colors, a palette style graphic will take much less memory. If you have very many colors, a RB image may be smaller.

jpg,bmp,gif,tif, png

All of these are raster image types. The jpg and bmp files are RGB type rasters. The gif is a palette style raster. Now, here's the interesting. A tif or png can be either RGB or palette!

So, now I'll just recap what I said at the very beginning. tif2bsb requires a palette type tif. But Imagemagick convert, when converting from a RGB type image to a tif, will create a RGB type tif. When converting from a palette type image, it will create a palette type tif. So, for it to work for us, we will have to create the tif from a palette type image. Well, when converting from any image to a gif, since gif is only a palette type image, convert will create a palette type gif.

So, now you know. From a jpg, we have to convert to gif first, and then convert that to a tif so we get a palette type tif.

[Gypsy23]

Cagney/Thomas, I am not sure if this is the right thread or who to address, but as you posted on this issue on the Navigation section of the Cruiser's Forum in 2009 and my question is really about OCPN I am starting here. Please refer me on if appropriate.

I found the thread ‘CPM93 Issues’ in the Navigation section. Back in 2009 there was a discussion about whether there were missing charts in the different sets of CM93 which are to be found in the internet. One example given was the lack of detail around Conway Reef (aka Ceva I Ra) between New Caledonia and Fiji. One poster advised that Navionics had good detail and you posted a Google image of the reef, another poster said his 2009 CM93 charts had levels A, C and D. I decided to look at what I have.

The CM93 charts I have are May 2010 (ed2) and I can use them on OCPN and CMap World for Windows (CMWfW) running both programs at the same time.

As various posters have noted, OCPN shows only a ‘Blue Diamond’ in the area of Ceva I Ra and it is clearly only an A level chart. This should make a navigator wary at least. But when the same chart is displayed on CMWfW it shows the Blue Diamond AND a black dot off to the SW of it. Put the cursor on the dot, right click to read Object Information and it tells us ‘Underwater Rock’ – ‘Always Dry’. The L/L is 21d46.5574S 174d30.2781E.

Now, back to OCPN, put the cursor on the L/L above, right click and it reveals the correct Object Information as described above but as previously mentioned, there is NO other marking at this point, even when the CM93 detail is pushed to 5. This means that OCPN is not displaying important obstruction information which is in the chart. Perhaps there are more details on missing charts but surely OCPN should display what is available to it on the A level. As it stands, a navigator could decide to sail south of the Blue Triangle to be safe only to “FIND” the reef!

So the question for me is: how do we know if OCPN is displaying all the detail available to it? Is this a bug or a recognised part of the design?

I am interested to have other’s input and views.
Ray