when i open a 16 bit image in tiff format, it opens up as a black image. The 16-bit tiff image only opens in the program ImageJ; however, it does not open in Preview. I am wondering what my options are now to view the format in an easier way that does not reduce the resolution than to open ImageJ to view it. Should I convert it to an 8-bit format, but wouldn't I lose data when the format is reduced from 16 to 8 bit? Also, I was thinking about converting the tiff image to jpeg, but would that result in a reduction in resolution?
From the ImageJ wiki's Troubleshooting page:
This problem can arise when 12-bit, 14-bit or 16-bit images are loaded into ImageJ without autoscaling. In that case, the display is scaled to the full 16-bit range (0 - 65535 intensity values), even though the actual data values typically span a much smaller range. For example, on a 12-bit camera, the largest possible intensity value is 4095—but with 0 mapped to black and 65535 mapped to white, 4095 ends up (linearly) mapped to a very very dark gray, nearly invisible to the human eye.
You can fix this by clicking on Image ▶ Adjust ▶ Brightness/Contrast... and hitting the Auto button.
You can verify whether the actual data is there by moving the mouse over the image, and looking at the pixel probe output in the status bar area of the main ImageJ window.
In other words, it is unlikely that your image is actually all 0 values, but rather the display range is probably not set to align with the data range. If your image has intensity values ranging from e.g. 67 to 520, but stored as a 16-bit image (with potential values ranging from 0 to 65535), the default display range is also 0=black, 65535=white, and values in between scaled linearly. So all those values (57 to 520) will appear near black. When you autoscale, it resets the display range to match the data range, making values 67 and below appear black, values 520 and above appear white, and everything in between scaled linearly.
If you use the Bio-Formats plugin to import your images into ImageJ, you can check the "Autoscale" option to ensure this dynamic display range scaling happens automatically.
As for whether to convert to JPEG: JPEG is a lossy compression format, which has its own problems. If you are going to do any quantitative analysis at all, I strongly advise not converting to JPEG. See the Fiji wiki's article on JPEG for more details.
Similarly, converting to 8-bit is fine if you want to merely visualize in another application, but it would generally be wrong to perform quantitative analysis on the down-converted image. Note that when ImageJ converts a 16-bit image as 8-bit (using the Image > Type menu), it "burns in" whatever display range mapping you currently have set in the Brightness/Contrast dialog, making the apparent pixel values into the actual 8-bit pixel values.
Changing from a 16 bit image to an 8 bit image would potentially reduce the contrast but not necessarily the resolution. A reduction in resolution would come from changing the number of pixels. To convert 16bit to 8bit the number of pixels would be the same but the bit depth would change.
The maximum pixel value in a 16 bit unsigned grayscale image would be 2^16-1
The maximum pixel value in an 8 bit unsigned grayscale image would be 2^8-1
One case where the resolution would be affected is if you had a 16 bit image with a bunch of pixels of pixel value x and another bunch of pixels with pixel values x + 1 and converting to an 8 bit image mapped the pixels to the same value 'y' then you would not be able to resolve the two sets of pixels.
If you look at the maximum and minimum pixel values you may well be able to convert to an 8 bit image without loosing any data.
You could perform the conversion and check using various metrics if the information in the 8bit image is reduced. One such metric would be the entropy. This quantity should be the same if you have not lost any data. Note that the converse is not necessarily true i.e. just because the entropy is the same does not mean the data is the same.
If you want some more suggestions on how to validate the conversion and to see if you have lost any data let me know.
Related
I have images of around 2000 X 2000 pixels. The objects that I am trying to identify are of smaller sizes (typically around 100 X 100 pixels), but there are lot of them.
I don't want to resize the input images, apply object detection and rescale the output back to the original size. The reason for this is I have very few images to work with and I would prefer cropping (which would lead to multiple training instances per image) over resizing to smaller size (this would give me 1 input image per original image).
Is there a sophisticated way or cropping and reassembling images for object detection, especially at the time of inference on test images?
For training, I suppose I would just take out the random crops, and use those for training. But for testing, I want to know if there is a specific way of cropping the test image, applying object detection and combining the results back to get the output for the original large image.
I guess using several (I've never tried) networks simultaneously is a choice, for you, using 4*4 (500+50 * 500+50) with respect to each 1*1), then reassembling at the output stage, (probably with NMS at the border since you mentioned the target is dense).
But it's weird.
You know one insight in detection with high resolution images is altering the backbone with "U" shape shortcut, which solves some problems without resize the images. Refer U-Net.
assume we have two rectified photos with known pixel position from stereo cameras and we want to draw the disparity map
what would be the closest pixel if the pixel in the right photo is moving in both direction? I know that the farthest point is the point which has the minimum value if we do q.x -p.x (p is a pixel in the Left photo) so is the maxim value from this is the closest?
Thank you
Disparity maps are usually written with signed values which indicate which direction the pixel moves from one image to the other in the stereo pair. For instance if you have a pixel in the left view at location <100,250> and in the right view the corresponding pixel is at location <115,250> then the disparity map for the left view at location <100,250> would have a value of 15. The disparity map for the right view at location <115,250> would have a value of -15.
Disparity maps can be multi-channel images usually with the x-shift in the first channel and the y-shift in the second channel. If you are looking at high resolution stereo pairs with lots of disparity you might not be able to fit all possible disparity values into an 8-bit image. In the film industry most disparity maps are stored as 16 or 32 bit floating point images.
There is no standard method of scaling disparity and it is generally frowned upon since disparity is meant to describe a "physical/concrete/immutable/etc" property. However, sometimes it is necessary. For instance if you want to record disparity of a large stereo pair in an 8-bit image you will have to scale the values to fit into the 8-bit container. You can do this in many different ways.
One way to scale a disparity map is to take the largest absolute disparity value and divide all values by a factor that will reduce that value to the maximum value in your signed 8-bit world (128). This method is easy to scale back to the original disparity range using a simple multiplier but can obviously lead to a reduction in detail due to the step reduction created by the division. For example, if I have an image with a disparity range of 50 to -200 meaning I have 250 possible disparity values. I can divide all values by 200/128 = 1.5625. This gives me a range of 32 to -128 or 160 possible disparity values. When I scale those value back up using a multiply I get 50 to -200 again but now there are only 160 possible disparity values within that range.
Another method using the above disparity range is to simply shift the range. The total range is 250, our signed 8-bit container can hold 256 values so we subtract 250-128 = 72 from all values which gives us a new range of 122 to -128. This allows us to keep all of the disparity steps and get the exact input image back simply by adding our shift factor back into the image.
Conversely, if you have a disparity map with range -5 to 10. You might want to expand that range to include subpixel disparity values. So you might scale 10 up to 128 and -5 down to -64. This gives a broader range of values but the total number of possible values will change from frame to frame depending on the input disparity range.
The problem with scaling methods is that they can be lossy and each saved image will have a scaling factor/method that needs to be reversed. If each image has a separate scaling factor, then that factor has to be stored with the image. If each image has the same scaling factor then there will be a larger degradation of the data due to the reduction of possible values. This is why it is generally good practice to store disparity maps at higher bit-depths to ensure the integrity of the data.
Does any one know which is going to be better for a browser loading time between these two options:
background-image:url('1by1px.png');
or
background-image:url('10by10px.png');
A 1px by 1px semi transparent png repeated for the div. Or a larger one say 10px by 10px.
There must be some kind of looping that has to be done to display the repeated image in the browser, and so I wondered if the image which is 1px by 1px causes alot of looping to get the image displayed that it may in fact be less speedy than a larger dimensioned image with less looping?
Of course the counter argument is image size is smaller for 1by1 compared to 10by10, but doesn't mean its better to be smaller because looping many times might not scale as good as looping a large image size slightly less often.
Does any know more about which would be better and how browsers handle situations like this?
When not repeating the background image, the time required to render depends on only the final scaled image, not the original one.
The image in a file is compressed as PNG format, but after being loaded by browser, it is in RGBA bitmap format (4 bytes for a pixel). When repeating a background, (let say on Intel x86), the native code of browser would use REP MOVSD to move the bitmap data from RAM to video memory (this is standard sequence, might be different on various implementations of graphics driver or specific GPU).
Assume that the dimensions of the HTML DIV which contains the background would be 100x100.
For the only-1 pixel image: the browser programme has to exec 10 thousand 'REP MOVSD' instructions.
For the 10x10 image: with each repeated image, the browser programme has to exec 'REP MOVSD' only 10 times (1 time calling to 'REP MOVSD' can render 1 pixel line (pixel row) of the image). So in this case, the number of 'REP MOVSD' instructions executed would be only 10x100 times (10 times in 1 image, 100 repeated images). This takes totally 1 thousand 'REP MOVSD'.
Therefore, the final background based on the bigger image would be rendered faster.
More notes:
The above explanation doesn't mean the performance is exactly 10 times better for the 10x10 image. A 'REP MOVSD' (with CX=9999 for example) is only 1 single CPU instruction but still requires 9999x4 bytes to be transfered through data bus. If using 9999 simple 'MOV's, that much of data still have to go thru' data bus, however, CPU has to execute 9998 instructions more. A more clever browser would create a pre-rendered bitmap for the background with replicated images; so each time it needs to transfer to video memory, it needs just only 100 'REP MOVSD' (100 is the number of pixel rows in the final background, assumed above) instead of 10 thousand or 1 thousand.
I agree with Paul answer.
I did few rough test with Google Chrome developer tool recently.
I used different size of semi-transparent png images on top of a background image and use page paint time to see how long do it take to refresh the screen.
Here is the result:
Time to refresh without -webkit-transform hack (rounded):
2x2 image : 65-160ms
10x10 image: 60-150ms
100x100 image: 55-135ms
1000x1000 image: 55-130ms
Time to refresh with -webkit-transform hack (rounded):
2x2 image : 40-120ms
10x10 image: 30-90ms
100x100 image: 30-90ms
1000x1000 image: 30-90ms
Just like what Paul said, bigger image is take shorter time to load(refresh), than smaller image.
But, it seem it is getting less effective after the image getting bigger than 10px. I don't see much difference between 100x100 and 1000x1000.
In my opinion, an huge image won't give you a noticeable result, and it might increase the loading time. So, I think any size around 10 - 100 is good enough for performance and loading time.
But still, different image might have different result, I think you should test your site with page paint time tool in Google Chrome developer tool for accurate result.
I am generating a PDF from HTML using a library, and all the size parameters that I am giving are in pixels. This seems kind of odd. I just googled the internet for A4 size in pixels, and can I just use these values everywhere?
Is this how it should be done? Will the generated PDF look correctly?
Otherwise, do I need to somehow compute the pixel size using information from the screen?
Then, how do PDF's work if they can be sent to others and still look comparatively the same?
PDF internally uses the same graphics model as PostScript. PDF is derived from PostScript. Basically,...
...it uses the very same operators that are available in PostScript, but renames them from being long and fully readable to short 1-, 2- or 3-letter abbreviations;
...however, it strips all features that make PostScript a full-blown programming language;
...and it adds a few new graphics capabilities, such as tranparencies and direct TrueType fonts embedding.
PDF also uses the same basic measurement unit as PostScript: 72 points == 1 inch. You may also use fractions of points. This is the device independent way of stating dimensions.
If you ever use pixels, you can do so. If you do, the absolute size of a graphic object on the display or the printed paper then depends on the current resolution of the display or printer. A square of 72px x 72px is 1inch x 1inch at a 72dpi resolution, but it is 0.1inch x 0.1inch at a 720dpi resolution. Therefore using pixels is a device dependent way of stating dimensions.
A4 dimensions are 'width x height = 595 x 842 pt'.
PDF's inherently a print medium, and its internal coordinates work in terms of 'points' (72pts per inch). The PDF rendering software (Acrobat, FoxIt, Ghostscript, etc...) will query the output device for its DPI rating and internally convert all the point-basec coordinates into device-specific pixel sizes when it comes time to render the PDF for display/print.
You can specify sizes in pixels while building a PDF, certainly. But remember that pixel sizes differ. A 300x300 pixel image will be 1" x 1" square on a 300dpi printer, but 3" by 3" on a 100 dpi monitor.
I sometimes edit my files in GIMP, when I want to edit my pictures and such. When I export for PDF it depends on the quality I need.
I just use this chart (for A4):
Let's say i have a 100000x100000 1 bit (K channel) tiff with a dpi of 2000 and i want to downscale this to a dpi of 200. My resulting image would be 10000x10000 image. Does this mean that every 10 bits in the 1 bit image correspond to 1 pixel in the new image? By the way, i am using libtiff and reading the 1 bit tiff with tiffreadscanline. Thanks!
That means every 100 bits in the 1 bit image correspond to 1 pixel in the new image. You'd need to average the value over 10x10 1bit pixel area. For smoother greyscales, you'd better average over n bits where n is the bit depth of your target pixel, overlying the calculated area partially with neighbor areas (16x16px squares 10x10px apart, so their borders overlay, for a smooth 8-bit grayscale.)
It is important to understand why you want to downscale (because of output medium or because of file size?). As SF pointed out, colors/grayscale are somewhat interchangeable with resolution. If it is only about file size losless/lossy compression is also worth to look at..
The other thing is to understand a bit of the characteristics of your source image. For instance, if the source image is rasterized (as for newspaper images) you may get akward patterns because the dot-matrix is messed up. I have once tried to restore an old news-paper image, and I found it a lot of work. I ended up converting it to gray scale first before enhancing the image.
I suggest to experiment a bit with VIPS or Irfanview to find the best results (i.e. what is the effect of a certain resampling algorithm on your image quality). The reason for these programs (over i.e. Photoshop) is that you can experiment with GUI/command line while being aware of name/parameters of the algorithms behind it. With VIPS you can control most if not all parameters.
[Edit]
TiffDump (supplied with LibTiff binaries) is a valuable source of information. It will tell you about byte ordering etc. What I did was to start with a known image. For instance, LibTIFF.NET comes with many test images, including b&w (some with 0=black, some with 1=black). [/Edit]