Closed mdsumner closed 5 years ago
Yeah, good point about .png
- I think I was just coping from niftyreg
examples which all use .jpg
s and failed to see that it all works with .png
s as well. I'll convert everything over. Thanks for picking that up! And yes, it would also be good to use VRT files - my thought was that having current invisible return of raster object suffices, but maybe not? Insights appreciated.
Oh maybe, sure thing I'll check. (I may be overly sensitive to the JPEG thing, but it's real, man).
I have this ongoing thing in ceramic, where we seamlessly translate between bbox in longlat to Mercator and vice versa - in a way they are interchangeable, and trivial - but not exactly unless you snap to tiles.
You're not overly sensitive - that's the first time i've done anything via jpg
for lotsa years, so more than happy to be prodded back into the comfortable world of png
.
Your comment re: crs translation is intriguing - do you envision a problem there? The thing I keep in mind throughout this is that any attempts to yield accuracy greater than the width of a pen line on a typical printed map are redundant. Rough rule of thumb would then be an absolute lower limit of like 1m or so.
No, not a problem here - was thinking out aloud, but might be an opportunity here to have a neater longlat->Mercator relationship along with what tiling systems do
My sense is that PNG should be used as the digital reference image, since RNiftyReg isn't format-aware, just using arrays. JPEG is inherently lossy.
Is there something specific though for why .jpg?
Also it wouldn't hurt to create auxiliary VRT files to augment the pdf/jpeg/png (I can do that) - though I see you do put the bb in the image comment.