Skip to content

add support for writing geotiff tags, using only a GDL procedure. #1525

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Mar 3, 2023
Merged

add support for writing geotiff tags, using only a GDL procedure. #1525

merged 2 commits into from
Mar 3, 2023

Conversation

GillesDuvert
Copy link
Contributor

Not wanting to mess up with the excellent work from @rexso , I found amusing to check if this could be done only with a GDL procedure. This is the result, adding GEOTIFF=struct to WRITE_TIFF
needs testing.

@GillesDuvert GillesDuvert mentioned this pull request Feb 26, 2023
Closed
@brandy125
Copy link

Thank you very much @GillesDuvert !

While testing it I found the following issues:

  1. There is a TYPO at line 17:
;whiledescription=string,document_name=string,geotiff=structure,$
;                double=double,  do begin

endwhile
; KEYWORD PARAMETERS:
  1. When compiling the procedure it complains about
% STRING is already defined with a conflicting definition.

Because of the keyword "string" appearing twice in the parameters definition:

pro WRITE_TIFF, filename, image, bits_per_sample, $
   red = red, green =  green, blue = blue, $
   compression = compression, description=string, document_name=string, $
   ...
  1. Writing a test Geotiff I got the following error:
GDL> write_tiff,'test.tif',image,geo=geo
% WRITEOFFSETTEDVALUEDOUBLE: Internal error, please report.
% Execution halted at: WRITEOFFSETTEDVALUEDOUBLE   259 gdl/src/pro/utilities/updategeotagsinimage.pro
%                      UPDATEGEOTAGSINIMAGE   457 gdl/src/pro/utilities/updategeotagsinimage.pro
%                      WRITE_TIFF         156 gdl/src/pro/write_tiff.pro
%                      $MAIN$          
GDL>

Could you please review it?
Thanks!

@GillesDuvert
Copy link
Contributor Author

Oh I even did not bother to check WRITE_TIFF, as updategeotagsinimage was a bit challenging.
The 'WRITEOFFSETTEDVALUEDOUBLE: Internal error, please report.' was intentional. So, I need the structure you passed to WRITE_TIFF, as apparently there is something I missed .

@brandy125
Copy link

Here's the structure:

GDL>restore,'geotiff_tag.sav',/v
% Restored variable: GEO.

geotiff_tag.sav.zip

@GillesDuvert
Copy link
Contributor Author

Ah, one works4me:

GDL> restore,file="geotiff_tag.sav" & a=dist(256) & write_tiff,"toto.tiff",a,geo=geo
GDL> 
$ exiftool -D -G -a -u -U -f toto.tiff 
[ExifTool]          - ExifTool Version Number         : 12.00
[ExifTool]          - Warning                         : Suspicious IFD0 offset for PixelScale
[ExifTool]          - Warning                         : Suspicious IFD0 offset for ModelTiePoint
[File]              - File Name                       : toto.tiff
[File]              - Directory                       : .
[File]              - File Size                       : 65 kB
[File]              - File Modification Date/Time     : 2023:02:27 19:49:34+01:00
[File]              - File Access Date/Time           : 2023:02:27 19:49:34+01:00
[File]              - File Inode Change Date/Time     : 2023:02:27 19:49:34+01:00
[File]              - File Permissions                : rw-rw-r--
[File]              - File Type                       : TIFF
[File]              - File Type Extension             : tif
[File]              - MIME Type                       : image/tiff
[File]              - Exif Byte Order                 : Little-endian (Intel, II)
[EXIF]            256 Image Width                     : 256
[EXIF]            257 Image Height                    : 256
[EXIF]            258 Bits Per Sample                 : 8
[EXIF]            259 Compression                     : Uncompressed
[EXIF]            262 Photometric Interpretation      : BlackIsZero
[EXIF]            266 Fill Order                      : Normal
[EXIF]            273 Strip Offsets                   : 8
[EXIF]            274 Orientation                     : Horizontal (normal)
[EXIF]            277 Samples Per Pixel               : 1
[EXIF]            278 Rows Per Strip                  : 256
[EXIF]            279 Strip Byte Counts               : 65536
[EXIF]            284 Planar Configuration            : Chunky
[EXIF]            297 Page Number                     : 0 1
[EXIF]            318 White Point                     : 0.3127000034 0.3289999962
[EXIF]            319 Primary Chromaticities          : 0.6399999857 0.3300000131 0.3000000119 0.6000000238 0.150000006 0.05999999866
[GeoTiff]           1 Geo Tiff Version                : 1.1.2
[GeoTiff]        1024 GT Model Type                   : Projected
[GeoTiff]        1025 GT Raster Type                  : Pixel Is Area
[GeoTiff]        2050 Geog Geodetic Datum             : WGS84
[GeoTiff]        2056 Geog Ellipsoid                  : WGS 84
[GeoTiff]        3072 Projected CS Type               : WGS84 UTM zone 23S
[GeoTiff]        3073 PCS Citation                    : Christians Text
[GeoTiff]        3076 Proj Linear Units               : Linear Meter
[GeoTiff]        3080 Proj Nat Origin Long            : -45
[GeoTiff]        3081 Proj Nat Origin Lat             : -45
[GeoTiff]        3082 Proj False Easting              : -45
[GeoTiff]        3083 Proj False Northing             : -45
[GeoTiff]        3092 Proj Scale At Nat Origin        : -45
[Composite]         - Image Size                      : 256x256
[Composite]         - Megapixels                      : 0.066

@brandy125
Copy link

brandy125 commented Feb 27, 2023 via email

@GillesDuvert
Copy link
Contributor Author

This looks like a padding error

@GillesDuvert
Copy link
Contributor Author

should pass now

@GillesDuvert GillesDuvert merged commit b11eb3f into gnudatalanguage:master Mar 3, 2023
@brandy125
Copy link

Hi @GillesDuvert today I tested the new write_tiff procedure and I think we are on the right way.

I have the following remarks:

  1. The image is written upside down by default
  2. A single band float image is written as a 3 band byte array

How complicated is it to implement the float keyword to write a float array as a single band float image?
Thanks already for your help!

@GillesDuvert
Copy link
Contributor Author

In fact I'm working on a full-fledged TIFF_WRITE, as it is quite simple to make a TIFF file in GDL. Besides, ImageMagick does not permit to write all supported options, like Float,Complex etc. Stay tuned.

@brandy125
Copy link

brandy125 commented Mar 10, 2023 via email

@GillesDuvert
Copy link
Contributor Author

"The image is written upside down by default"

IDL test of: window,xsize=256,ysize=256 & plot,dist(20)&a=tvrd()&write_tiff,'idl.tiff',a
and IDL> $display idl.tiff
'display' plots the image upside-down.
This probably because of this IDL note

@brandy125
Copy link

brandy125 commented Mar 11, 2023 via email

@brandy125
Copy link

brandy125 commented May 16, 2023 •
edited
Loading

@GillesDuvert how is the actual status of write_tiff?

For me the images still are written upside down and I get a crash when I execute the write_tiff command twice. Could you please test?

Example that shows that the image is written upside down:

GDL> a=read_tiff('test_in.tif',geo=geo)
GDL> help,a
A               FLOAT     = Array[500, 500]
GDL> write_tiff,'test_out.tif',a,geo=geo,/float

If you open both Geotiffs you will see that the test_out.tif is upside down.
What is strange and what I do now like is that the command write_tiff changes the order in which the image is displayed on the screen without changing the !order system variable.

Look at this:

GDL> a=read_tiff('test_in.tif',geo=geo)
GDL> tv,bytscl(a,0,1e8)
GDL>print,!order
     0
GDL> write_tiff,'test.tif',a,geo=geo,/float
GDL> tv,bytscl(a,0,1e8)     ; <--- this command displays the image upside down
GDL>print,!order
     0

Example that shows the crash when executing the write_tiff command twice:

GDL> geo={MODELPIXELSCALETAG:[1d0,1d0,0d0],MODELTIEPOINTTAG:dblarr(6)}
GDL> write_tiff,'test.tif',float(dist(100)),geo=geo,/float
GDL> write_tiff,'test.tif',float(dist(100)),geo=geo,/float
% WRITEASIMPLETAG: Variable is undefined: I
% Error occurred at: WRITEASIMPLETAG    227 /usr/local/share/gnudatalanguage/lib/utilities/updategeotagsinimage.pro
%                    WRITE_TIFF         404 /usr/local/share/gnudatalanguage/lib/write_tiff.pro
%                    $MAIN$          
% Execution halted at: $MAIN$          
GDL>

Thanks for any help!

@GillesDuvert
Copy link
Contributor Author

@brandy125 👍 all those bugs must be cured, and should be reported in the testsuite.
!order is apparently not taken into account in any of the read* and write* procedures (personnaly I was not aware of this system variable)

@GillesDuvert GillesDuvert mentioned this pull request May 17, 2023
Closed
@GillesDuvert
Copy link
Contributor Author

@brandy125 For the record, !order has no effect on reading/writing images. It just has an effect on tv, tvscl and tvrd, and GDL is OK in this respect.

@brandy125
Copy link

I know this. Maybe I did not express myself well.
Now that I am reading my post again I see a typo that maybe confused.

I wrote:

What is strange and what I do now like is that the command write_tiff changes the order in which the image is displayed on the screen without changing the !order system variable.

Instead I wanted to say:

...what I do not like...

So if you execute this command:

GDL> a=read_tiff('test_in.tif',geo=geo)
GDL> tv,bytscl(a,0,1e8)

The image was displayed in the correct order

GDL>print,!order
     0

The !order variable is 0 as it should be

GDL> write_tiff,'test.tif',a,geo=geo,/float
GDL> tv,bytscl(a,0,1e8)     ; <--- this command displays the image upside down

After the write_tiff command the image will be displayed upside down. This can only happen if the !order variable is 1 now.

GDL>print,!order
     0

The !order variable is still 0, so how can this happen?
What did the write_tiff command do so that the image will be displayed upside down now?

@GillesDuvert
Copy link
Contributor Author

hah, but thats easy 😄 : the write_tiff procedure contained calls to reverse() that affected the passed array and not a local copy.
I have removed the reverse() in the new version #1592 so this should be solved also!

@brandy125
Copy link

Nice, I just tested and it works fine now! Thanks!

If you can resolve the issue with the crash when executing write_tiff two times then for me everything is fine.

GDL> geo={MODELPIXELSCALETAG:[1d0,1d0,0d0],MODELTIEPOINTTAG:dblarr(6)}
GDL> write_tiff,'test.tif',float(dist(100)),geo=geo,/float
GDL> write_tiff,'test.tif',float(dist(100)),geo=geo,/float
% WRITEASIMPLETAG: Variable is undefined: I
% Error occurred at: WRITEASIMPLETAG    227 /usr/local/share/gnudatalanguage/lib/utilities/updategeotagsinimage.pro
%                    WRITE_TIFF         404 /usr/local/share/gnudatalanguage/lib/write_tiff.pro
%                    $MAIN$          
% Execution halted at: $MAIN$          
GDL>

What could be the problem here? The crash happens with any geotiff. When executing the write_tiff command two times it crashes.

@brandy125
Copy link

Sorry, forget the above post. Everything works fine now.
@GillesDuvert many thanks to you!

@brandy125
Copy link

brandy125 commented May 25, 2023 •
edited
Loading

BTW, this new version introduced a bug. Should I open a new issue for it?

The following program does not compile because of the "$"

pro testme
	for i=0,1 do begin  $
		print,i
	endfor
end

@GillesDuvert
Copy link
Contributor Author

OK, this is related to the correction of #52 . Clearly not OK. I open an issue.

@GillesDuvert GillesDuvert deleted the geotifftags branch September 8, 2023 17:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@GillesDuvert @brandy125