I'm using LibTIFF with Visual Studio 2012 (C code), 64bit Windows to produce a 16bit grayscale TIF image. I can open the resulting image in a variety of third-party image viewers and they look fine. My problem though is that I only seem able to write XRESOLUTION. The value I write for YRESOLUTION and RESOLUTIONUNIT do not seem to make it into the header.
TIFF* tif = TIFFOpen("c:\local\test.tif", "w");
TIFFSetField(tif, TIFFTAG_IMAGEWIDTH , 2868);
TIFFSetField(tif, TIFFTAG_IMAGELENGTH , 2048);
TIFFSetField(tif, TIFFTAG_BITSPERSAMPLE , 16);
TIFFSetField(tif, TIFFTAG_RESOLUTIONUNIT, RESUNIT_CENTIMETER);
TIFFSetField(tif, TIFFTAG_XRESOLUTION , 115.0);
TIFFSetField(tif, TIFFTAG_YRESOLUTION , 115.0);
(That is all for SetFields.. I'll omit the subsequent loop
and TIFFWriteScanLine calls for clarity, as the resulting
image "looks correct")
When I open the resulting image inside ImageJ (for example) or in AWare Systems AsTiffTagViewer software, I see the following headers described:
ImageWidth (1 Short): 2868
ImageLength (1 Short): 2048
BitsPerSample (1 Short): 16
Compression (1 Short): LZW
Photometric (1 Short): MinIsBlack
StripOffsets (2048 Long): 16, 808, 1584, 2388, 3202, 4053, 4889, 5718,...
Orientation (1 Short): TopLeft
SamplesPerPixel (1 Short): 1
RowsPerStrip (1 Short): 1
StripByteCounts (2048 Long): 792, 776, 804, 814, 851, 836, 829, 855, 830,...
XResolution (1 Rational): 115
0 (0 NoType):
1 (2051838 NoType):
So I can see that XRESOLUTION was written properly, but YRESOLUTION and RESOLUTIONUNIT are missing.
Any idea what I am doing wrong?
EDIT: I tried after using TIFFSetField, to retrieve the values using TIFFGetField. The retrieved values are correct, so it seems that somehow during TIFFClose when things are written out, that they get corrupted.
Thanks!
We determined this was a bug but that we were using an old version of libTiff.
It seems it is currently maintained, 4.0.6 is the latest, which does not have this bug, and can be found here:
http://www.simplesystems.org/libtiff/
Related
I am trying to understand the model architecture of DINO https://arxiv.org/pdf/2203.03605.pdf
These are the last few layers I see when I execute model.children()
Question 1)
In class_embed, (0) is of dimension 256 by 91, and if it's feeding into (1) of class_embed, shouldn't the first dimension be 91?
So, I realize (0) of class_embed is not actually feeding into (1) of class_embed. Could someone explain this to me?
Question 2)
Also, the last layer(2) of MLP (see the first picture which says (5): MLP) has dimension 256 by 4. So, shouldn't the first dimension of class_embed (0) be having a size of 4 ?
Now, when I use a different function to print the layers, I see that the layers shown above are appearing as clubbed. For example, there is only one layer of
Linear(in_features=256, out_features=91, bias=True)]
Why does this function give me a different architecture?
Question 3)
Now, I went on to create a hook for the 3rd last layer.
When I print the size, I am getting 1 by 900 by 256. Shouldn't I be getting something like 1 by 256 by 256 ?
Code to find dimension:
Output:
especially since layer 4 is :
I am using the LibTiff.NET library to load GeoTiff data in C# (inside Unity).
**NOTE - I looked at GDAL also, but faced similar issues as outlined below, and would much prefer to use LibTiff if possible.
I would ultimately like to be able to take a lat/long value and have a function that returns a chunk of pixel data for a 50m area around that point, streamed from a GeoTiff image on disk (not storing whole image in RAM).
I have a test file that is representative of what my software will be given in production.
I am trying to figure out how to read or compute the lat/long extents of the test file image, as I can't find a good tutorial or sample online which contains this functionality.
I can read the width+height of the file in the TiffTags, but many other values that seem critical for computing the extents such as X and Y resolutions are not present.
It also appears like the lat/long extents (or a bounding box) are not present in the tags.
At this point I am led to believe there may be more tags or header data that I am not familiar with because when I load the test file into Caris EasyView I can see a number of properties that I would like to read or compute from the file:
Is it possible to obtain this data using LibTiff?
Or is there a better system I should use? (wrapped GDAL maybe?)
** NOTE: I cannot link the test file due to NDA, plus it's enormous
This is for a 32-bit geotiff:
int width = tiff.GetField(TiffTag.IMAGEWIDTH)[0].ToInt();
int height = tiff.GetField(TiffTag.IMAGELENGTH)[0].ToInt();
int samplesPerPixel = tiff.GetField(TiffTag.SAMPLESPERPIXEL)[0].ToInt();
int bitsPerSample = tiff.GetField(TiffTag.BITSPERSAMPLE)[0].ToInt();
int bytesPerSample = bitsPerSample / 8;
byte[] scanline = new byte[tiff.ScanlineSize()];
float[] scanline32Bit = new float[tiff.ScanlineSize() / 4];//divide by 4 for byte word
FieldValue[] modelTiePointTag = tiff.GetField(TiffTag.GEOTIFF_MODELTIEPOINTTAG);
byte[] modelTransformation = modelTiePointTag[1].GetBytes();
double originLon = BitConverter.ToDouble(modelTransformation, 24);
double originLat = BitConverter.ToDouble(modelTransformation, 32);
FieldValue[] modelPixelScaleTag = tiff.GetField(TiffTag.GEOTIFF_MODELPIXELSCALETAG);
byte[] modelPixelScale = modelPixelScaleTag[1].GetBytes();
double pixPerLong = BitConverter.ToDouble(modelPixelScale, 0);
double pixPerLat = BitConverter.ToDouble(modelPixelScale, 8) * -1;
another question about spectrum calculation in Octave using FFT:
With Audacity I created a .wav file containing white noise, then filtered with a lowpass with fcut = 1kHz, -20dB/decade. The spectrum analysed by Audacity looks as expected (unfortunately I can't post an image since I don't have enough reputation)
Then I analysed the spectrum with Octave using the following code:
pkg load signal %load signal package
graphics_toolkit ("gnuplot") % use gnuplots
close all
clear all
[stereosig, fs,bit] =wavread('noise_stereo.wav'); % load wav
ch1 = stereosig(:,1); % left
ch2 = stereosig(:,2); % right
NFFT = 1024;
NFFT_half = NFFT/2;
X = fft(ch1, NFFT);
freqvect = (1:NFFT_half+1)./NFFT*fs;
figure(1)
X_mag_scaled = abs(X(1:NFFT_half+1)./NFFT_half);
semilogx(freqvect, 20*log10(X_mag_scaled));
grid on
xlabel('Frequency (Hz)')
ylabel('Mag [dB]')
The plot produced by Octave is extremly "unsmooth", the -20dB/decade can not be recognised properly since the difference between two adjacent points can be > 10dB or so. The 1kHz cut off frequency can only be guessed.
Does anybody have an idea how to get a "smooth" spectrum as it is done in Audacity (which I suppose to be a reasonable solution)?
Philippe
I have 64000 small images I want to upload to my website (using existing validation, so no FTP etc). I've created an HTML5 [multiple] type=file input for this a while back to be used for a hundred or hundreds of images. Hundreds is not a problem. The images are batched and sent to the server.
But when I select a folder of ~ 16000 images, the file input's FileList is empty... The onchange event triggers, but the file list is empty. The browser (or file system or OS?) seems to have a problem selecting this many files.
I've created a very small tool to help determine what could be the max: http://jsfiddle.net/rudiedirkx/Ehhk5/1/show/
$inp.onchange = function(e) {
var l = 0, b = 0;
for (var i=0, F=this.files, L=F.length; i<L; i++) {
l += F[i].name.length;
b += F[i].size;
}
$nf.innerHTML += this.files.length + ' files: ' + (b/1000/1000) + ' MB / ' + l + ' chars of filename<br>';
};
All it does is count:
the number of files
the number of characters all file names are combined
the number of MB of total file size
When I try this, I get as very most:
1272 files: 176.053987 MB / 31469 chars of filename
(On 32 & 64 bit Win7, Chrome 26-52)
The next image (which fails) would be:
1273 images, which is not an obvious cut-off
between 176 and 177 MB filesize, also not an obvious cut-off
less than 32000 chars of filenames, also not an obvious cut-off, although it sort-of maybe looks like 32k...
In my calc, 1 MB = 1000^2 Bytes, not 1024^2. (That would be a MiB, but maybe my OS/filesystem/browser disagrees.)
My question would be: why this many files? Why this max? Is it OS dependent or browser dependent? Where do I find the specs for that? Is it JS' fault? Search for "file input max files" et al only results into the [max] attribute, which is irrelevant.
More test results:
In Firefox the max seems to be much higher. At least "2343 files: 310.66553999999996 MB / 60748 chars of filename" (that's all the files I have right here)
In Firefox also: "16686 files: 55.144415 MB / 146224 chars of filename" (much smaller, but more files)
Update
Chrome 52 canary Windows is still 32k of file name
Firefox (44+) Windows is still unlimited
why this many files?
The number of files depends on the number of characters all file names are combined.
Why this max?
In the Windows API, the maximum path length limitation is 256 chars, the Unicode version API is 32,767 chars.
Chrome simply sets the max path length of the Unicode version API, so it's about 32k chars as you observed.
Check this fix: https://code.google.com/p/chromium/issues/detail?id=44068
Firefox dynamically allocates a buffer big enough to hold the size of multiple selected files, which could handle much larger path length.
Check this fix: https://bugzilla.mozilla.org/show_bug.cgi?id=660833
Is it OS dependent or browser dependent?
Both.
Where do I find the specs for that?
For Windows API usage and reference:
http://msdn.microsoft.com/en-us/library/aa365247.aspx (Maximum Path Length Limitation)
http://msdn.microsoft.com/en-us/library/ms646839(VS.85).aspx
Is it JS' fault?
No.
I'm having some trouble understanding how to use KissFFT (1.2.9) correctly. All I am trying to achieve for now is to perform an FFT and then immediately perform an iFFT to reconstruct the original signal again. The code snippet below demonstrates what I'm doing:
void test(short* timeDomainData, int length)
{
// Create the configurations for FFT and iFFT...
kiss_fftr_cfg fftConfiguration = kiss_fftr_alloc( length, 0, NULL, NULL );
kiss_fftr_cfg ifftConfiguration = kiss_fftr_alloc( length, 1, NULL, NULL );
// Allocate space for the FFT results (frequency bins)...
kiss_fft_cpx* fftBins = new kiss_fft_cpx[ length / 2 + 1 ];
// FFT...
kiss_fftr( fftConfiguration, timeDomainData, fftBins );
// iFFT...
kiss_fftri( ifftConfiguration, fftBins, timeDomainData );
}
What I found is that this actually crashes at run-time. I found that by dividing the size by 2 when creating the KissFFT configurations stopped the crashing:
kiss_fftr_cfg fftConfiguration = kiss_fftr_alloc( length / 2, 0, NULL, NULL );
kiss_fftr_cfg ifftConfiguration = kiss_fftr_alloc( length / 2, 1, NULL, NULL );
However, when I play the reconstructed audio data it's mostly silent with the odd crackle.
Can anyone point me in the right direction?
Many thanks,
P
Edit 1: This is how I include the KissFFT header file and define the FIXED_POINT variable:
#define FIXED_POINT 16
#include "kiss_fftr.h"
This ensures that the typedef'd 'kiss_fft_scalar' type is forced to int16_t (short).
Edit 2: The target platform is Android, so I have also added the following to my Android.mk file:
LOCAL_CPPFLAGS += -DFIXED_POINT
I noticed you are sending in shorts. Are you sure you've compiled everything to use int16_t as the DATATYPE? Sometimes a mismatch of preprocessor environments can cause a problem.
Also, the fixed point version scales downward both directions (fwd,inv). So if you expect to reconstruct your signal, you'll want to multiply things by a total of nfft.
I'd recommend multiplying with saturation in two stages.
e.g. if you're doing an FFT+IFFT of size 1024, then multiply by 32 after the FFT, then again by 32 after the IFFT.
I'm not sure about the silence, but if you're getting lots of crackles then it may because you're processing adjacent blocks independently rather than using Overlap-Add, where you effectively cross-fade between each block to get a smoother characteristic.
I'm struggling to do the same thing in Android, haven't got it yet (see here!), but I can see a problem in your code: "fftBins" needs to be "length" size. The reason is that it is the raw transform, not the frequency magnitude/phases... I think? Or have I got it wrong?