Conversions a little grainy at high zoom levels

[jamez70]

Here is a clip from the .tif file:

Here is the same area roughly with 100% quality tiles. Ignore the marker over the airport as this is my app displaying the weather there.

What causes the degradation of the quality? Can it be improved at all?

[N129BZ]

What is the image type being generated? Webp, png, or jpg?

[jamez70]

I've tried webp and png and had the same results

[N129BZ]

I'm looking into this, from what I'm finding its a known issue with gdal. It may relate to some metadata in the GeoTIFF source. Some GeoTIFFs have a device block size value that is not 256 x 256 px. - I'm looking at them using gdalinfo to see what I can find.

[N129BZ]

Here is the metadata from wichita.vrt below. Note the X and Y resolutions. I believe gdal_translate defaults to 256x256, so it maybe has some some negative effect on the resulting tiled images that they're not being translated to the original dimensions. I'm going to experiment with reading the metadata and setting the BLOCKXSIZE and BLOCKYSIZE parameters to match the metadata values:
<Metadata> <MDI key="AREA_OR_POINT">Area</MDI> <MDI key="TIFFTAG_DATETIME">2024:06:11 11:20:03</MDI> <MDI key="TIFFTAG_RESOLUTIONUNIT">2 (pixels/inch)</MDI> <MDI key="TIFFTAG_SOFTWARE">Adobe Photoshop 24.6 (Windows)</MDI> <MDI key="TIFFTAG_XRESOLUTION">300</MDI> <MDI key="TIFFTAG_YRESOLUTION">300</MDI> </Metadata>

[jamez70]

Oh nice! I'd just like to be as good as skyvector or vfrmap is. It actually does look like a downsampling algorithm is causing it because of the way the edges appear

[N129BZ]

jamez70 - please test this new docker image: n129bz/chartmaker:v1.37

I added LZW lossless compression and several more -co options in the gdal_translate, gdalwarp, and gdaladdo commands, as well as upping the default zoomlevel from 1-12 to 1-13 and the default tileimagequality to 100. I think the results are definitely better, but would like a 2nd pair of eyes on this... image should be pushed within an hour.

[jamez70]

I tried but it says
Error response from daemon: manifest for n129bz/chartmaker:v1.37 not found: manifest unknown: manifest unknown

[N129BZ]

Yes, it’s not there yet. I edited the comment and mentioned it’ll be there in an hour.

…

On Aug 20, 2024, at 5:09 PM, jamez70 ***@***.***> wrote: I tried but it says Error response from daemon: manifest for n129bz/chartmaker:v1.37 not found: manifest unknown: manifest unknown — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALK77SCDAQP7N5RAU622FU3ZSO5CLAVCNFSM6AAAAABMYVX5HWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJZHA2DMNZRGQ>. You are receiving this because you were assigned.

[jamez70]

Oh no problem. I'll try it tonight

[N129BZ]

Sorry about the delay, I decided to make the new image from scratch. It's up now

[jamez70]

No big deal. I'll try it later and let you know Jim

…

On Tue, Aug 20, 2024, 7:01 PM Brian Manlove ***@***.***> wrote: Sorry about the delay, I decided to make the new image from scratch. It's up now — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIVBU7EH65FILPDWSS33SDZSPKHDAVCNFSM6AAAAABMYVX5HWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJZHE2TSNJWGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jamez70]

I tried.. It wasn't able to get any image

[N129BZ]

So sorry for the delay. I ended up revamping the logic for dealing with passed arguments. I was using the asterisk as an arg to process all 53 individual area charts and discovered it blew up when running in docker (worked fine in WSL so I never caught that.)

new image is n129bz/chartmaker:v1.38

New values for a passed arg are ALL, SINGLE=X (where X is the chart number) or FULL to process whatever indexes are in the chartprocessindexes array. No passed arg defaults to the prompt for the process you want.

I also re-indexed the vfrindividualcharts array in settings.json to be zero-based like all the other arrays in there. All of the other (hopeful) improvements to image processing are still there from my original v1.36 attempt...

Thanks for your patience and time!!

--Brian

[jamez70]

I totally understand. In the meantime I just updated the git files in 1.37 and I'm running that right now.

…

On Tue, Aug 20, 2024, 9:30 PM Brian Manlove ***@***.***> wrote: So sorry for the delay. I ended up revamping the logic for dealing with passed arguments. I was using the asterisk as an arg to process all 53 individual area charts and discovered it blew up when running in docker (worked fine in WSL so I never caught that.) new image is *n129bz/chartmaker:v1.38* New values for a passed arg are ALL, SINGLE=X (where X is the chart number) or FULL to process whatever indexes are in the chartprocessindexes array. No passed arg defaults to the prompt for the process you want. I also re-indexed the vfrindividualcharts array in settings.json to be zero-based like all the other arrays in there. All of the other (hopeful) improvements to image processing are still there from my original v1.36 attempt... Thanks for your patience and time!! --Brian — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIVBU46E232G2AKZWIZHN3ZSP3SVAVCNFSM6AAAAABMYVX5HWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBQGMZDCNJRGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[N129BZ]

Here's what I got:

[N129BZ]

A little more zoomed:

[N129BZ]

and a little more:

[jamez70]

wow that looks perfect! and I am very impressed! Nice work!

[N129BZ]

The only "gotcha" is bigger db files... I think changing zoom level from 12 to 14 adds a lot of size. Closing issue