Stacktrace when running the script about photoscenary HOT 11 CLOSED

from photoscenary.

$ julia --version
julia version 1.5.3

On Debian Testing

I didn't dump anything...

Update to version 1.6 isn't available yet....
You stated in your goals that you want something easy to use on all platforms... needing to compile the latest version is NOT easy to use... python for example would have been more appropriate for that.

I won't build julia from source... so either we get this working with the older or I can't use it.

from photoscenary.

$ julia --version
julia version 1.5.3

On Debian Testing

I didn't dump anything...

I won't build julia from source... so either we get this working with the older or I can't use it.

Hello,
I have just published an updated version that solves the problem also with version 1.5.4, unfortunately I could not try with that version, but I am 99% sure that it works well and should no longer give the error except the warning which is relative to version.
I hope now that everything is more practical and if you haven't read the manual, I am sending you the link here:
https://wiki.flightgear.org/Julia_photoscenery_generator
I hope it is clear enough, if there are aspects that you do not understand, thank you already in advance and write me that I correct them.

You stated in your goals that you want something easy to use on all platforms... needing to compile the latest version is NOT easy to use... python for example would have been more appropriate for that.

You don't actually have to compile Julia 1.6.1 for Debian, just install Julia via this simple manual:
https://medium.com/coffee-in-a-klein-bottle/install-julia-1-5-on-ubuntu-bb8be4b2571d

Unfortunately Julia is a relatively young language that has undergone intense development in recent years and has produced very different releases (1.5.x is really very different from 1.6.x at compiler level) which have left some distributions, less rapid in updates. , back one release.
I have been using Debian for a long time and I know very well that the Debian flavor you use always lags behind about a year.
However now, with this version, 1.5.4 should be working properly again, while the versions for Windows and Ubuntu 21.4, Arc Linux are definitely with Julia 1.6.1.

So, apologizing for the problem, but thanking you for the report that I immediately used to make the correction, I hope you can try the application and let me know if it went well and your observations to allow it to be improved.

Greetings
Adriano

from photoscenary.

Thanks for the quick fix.

I ran into the next issue:

$ time julia photoscenary.jl -t 4 -s 4 -i ybcs -r 5
The actiual Julia is 1.5.3 The current version is correct,
In order to obtain the best performancesy install the 1.6.x or later version

Photoscenary.jl ver: 0.2.3 date: Testing 20210515 System prerequisite test


Photoscenery generator by Julia compilator,
Program for uploading Orthophotos files

Version: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
Copyright: (C) 1999-2021 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC Modules OpenMP(4.5) 
Delegates (built-in): bzlib djvu fftw fontconfig freetype heic jbig jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png tiff webp wmf x xml zlib

ImageMagic is operative!
ERROR: LoadError: ArgumentError: range step cannot be zero
Stacktrace:
 [1] (::Colon)(::Float64, ::Float64, ::Float64) at ./twiceprecision.jl:390
 [2] (::var"#4#6")(::Float64) at ./none:0
 [3] iterate at ./generator.jl:47 [inlined]
 [4] iterate at ./iterators.jl:1068 [inlined]
 [5] iterate at ./iterators.jl:1064 [inlined]
 [6] grow_to!(::Array{Tuple{String,String,Any,Float64,Any,Float64,Int64,Any,Any,Int64,Any},1}, ::Base.Iterators.Flatten{Base.Generator{StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}},var"#4#6"}}) at ./array.jl:747
 [7] _collect at ./array.jl:660 [inlined]
 [8] collect at ./array.jl:624 [inlined]
 [9] coordinateMatrixGenerator(::Float64, ::Float64, ::Float64, ::Float64, ::Bool, ::Nothing, ::Int64) at /owncloud/ortho/photoscenary/photoscenary.jl:360
 [10] main(::Array{String,1}) at /owncloud/ortho/photoscenary/photoscenary.jl:927
 [11] top-level scope at /owncloud/ortho/photoscenary/photoscenary.jl:1027
 [12] include(::Function, ::Module, ::String) at ./Base.jl:380
 [13] include(::Module, ::String) at ./Base.jl:368
 [14] exec_options(::Base.JLOptions) at ./client.jl:296
 [15] _start() at ./client.jl:506
in expression starting at /owncloud/ortho/photoscenary/photoscenary.jl:1027

I'll let you know some feedback on the command line options later...

As for getting a newer version, I try to keep at least my core system on a "stable" version provided by the package manager... I don't want to get into dependency hell. I know that Debian lags behind, which is why I use testing on my PC so it's quite up-to-date. (max lag for most things I use is maybe a month at most)

from photoscenary.

Thanks for the quick fix.

I ran into the next issue:

$ time julia photoscenary.jl -t 4 -s 4 -i ybcs -r 5

Hello,

the problem is that you have to write the command like this:

julia -t 4 photoscenary.jl -s 4 -i ybcs -r 5

-t inserted after Julia activates parallel threads, while -t after photoscenary.jl is equivalent to --tile and allows you to get the coordinates from the tile id that you can get from FGFS or the FGFS scenario manager.

Having made this mistake, I add a check as actually -t is ambiguous, as you entered -i which has the same meaning.

Thanks for collaboration!

from photoscenary.

Works, thanks...
I've noticed issues with paths tho:
1st: If I try --path ../test it tries to write to /home/test/Orthophotos instead of the test directory which is located in the parent dir of where I currently am.
2nd: The path in the log output is given as path: ../e140s20/e145s18/5329469.dds where ../ indicates a relative path while I needed to give an absolute path due to issue 1.

oh... and which compression do you use? the files seem to be smaller than the one I've created with dxt1

from photoscenary.

Next issue: I run with -i ybcs -r 5 looking at the map this should download 4 tiles as any outer tile border of those 4 tiles is more than 5nm from the airport position away
But it downloaded a total of 20 tiles.

from photoscenary.

Works, thanks...
I've noticed issues with paths tho:
1st: If I try --path ../test it tries to write to /home/test/Orthophotos instead of the test directory which is located in the parent dir of where I currently am.
2nd: The path in the log output is given as path: ../e140s20/e145s18/5329469.dds where ../ indicates a relative path while I needed to give an absolute path due to issue 1.

oh... and which compression do you use? the files seem to be smaller than the one I've created with dxt1

Thi is the imagemagick parameters:
magick convert $imageWithPathTypePNG -define dds:mipmaps=0 -define dds:compression=dxt1 $imageWithPathTypeDDS

I have done various tests to understand which is the best compression and I have found this combination. I think part of the problem is how the .png file is generated which in Julia is generated according to the default settings with the function:
Images.save(imageWithPathTypePNG, imageMatrix)
In fact, I do what the old Python application does as well, which is to mount the mosaic of images on a matrix in RGB format {N0f8} which means that each pixel is a three-byte RGB in 8-bit unsigned integer format. This already acts as a compression factor (I think) as a 3x2 Byte RGB format is often used.

from photoscenary.

Next issue: I run with -i ybcs -r 5 looking at the map this should download 4 tiles as any outer tile border of those 4 tiles is more than 5nm from the airport position away
But it downloaded a total of 20 tiles.

In fact I am not intentionally precise, simply the radius is the minimum dimension within which to select tiles. This means that I will have some more tiles. This is more evident for small tiles. The area is then square in shape and this is always to have a certain abundance useful to avoid creating too limited areas.
However, if it seems useful to you, it is possible to have a reduction of the definition of the image in the most external (farther) areas with the option: --sdwn ("Down size with distance") that you find at this link as a description: --sdwn

from photoscenary.

from photoscenary.

magick convert $imageWithPathTypePNG -define dds:mipmaps=0 -define dds:compression=dxt1 $imageWithPathTypeDDS

okay, I generate mipmaps... that explains it.

The area is then square in shape and this is always to have a certain abundance useful to avoid creating too limited areas.
However, if it seems useful to you, it is possible to have a reduction of the definition of the image in the most external (farther) areas with the option: --sdwn ("Down size with distance") that you find at this link as a description: --sdwn

I'd have expected a square, 2x2 tiles. --sdwn isn't exactly want I want... as I just would want to download the airport in high res...
I don't mind about the rest has I have already a low res scenery downloaded which covers the rest.

from photoscenary.