I am using Qt and saving a image file out of a QML UI item. Following is what I do
auto screenshot = quick_item->grabToImage();
screenshot->saveToFile("/somepath/filename.jpeg");
// OR sometimes use like png like
screenshot->saveToFile("/somepath/filename.png");
This is works fantastically well on all platforms. I open the file the image is saved as intended.
Now my question is:
I just mentioned .jpeg as file extension while providing the filename as param into saveToFile. This works but, should I need to use QImageWriter to ensure that the image is actually compressed in jpeg/png format ?
What happens when it is a lossy compression like jpeg?
How to control a lossy compression if I want to like in android I can do a image.compress(CompressFormat.JPEG, 80, stream) where 80 is the percentage of quality for Compress ?
You can't do that directly from QQuickItemGrabResult, you have to use QImage::save() for that :
auto screenshot = quick_item->grabToImage();
auto image = screenshot->image();
image.save("/somepath/filename.jpeg", nullptr, 80);
The second parameter of save is the format, but it can be left null and then be guessed based on the filename extension, the third one is the compression quality.
The quality factor has no effect if you use a lossless format like png. You can set it at -1 (the default value), omit the parameter or use a factor that you would use for lossy format.
EDIT: as pointed by #Arsenal, the quality factor maps to compression levels for lossless formats (those that support it). For example in PNG, quality 0 maps to PNG compression level 9 (smallest file size) and 100 to PNG compression level 0 (biggest file size). The default quality for PNG in Qt is 50, mapping to a PNG compression level of 4.
Related
I am using inkscape to change the file type from a pdf to an emf. I noticed when I open the files in corel (to check that it was outputted correctly) that they are different sizes than each other - the pdf is the size I set it to be initially (as you'd expect), while the emf is a plain letter size (8.5 x 11).
If I am only using
inkscape 49.pdf -o 49.emf
on the command line, why is it changing the document size? Is there a way to preserve it? Has any one else had this problem? I've checked the man page for options and I haven't seen an explicit command to preserve page size (though I don't believe I should have to even do).
Thank you so much for your input!
I read my hyperspectral (.raw) file and combine three bands to "gai_out_r" Then I output as following:
writeRaster(gai_out_r,filepath,format="GTiff")
finally I got gai_out_r.tif
But, why Win10 can't display this small tif as the pic that I output the same way from envi--save image as--tif
Two tiffs are displayed by Win10 as following:
Default windows image viewing applications doesn't support Hyperspectral Images-since you are just reading and combining 3 bands from your .raw file, the resulting image will be a hyperspectral image.You need to have separate dedicated softwares to view hypercubes or can view it using spectral-python also.
In sPy, using envi.save_image , will save it as a ENVI type file only. To save it as an rgb image file(readable in windows OS) we need to use other methods.
You are using writeRaster to write to a GTiff (GeoTiff) format file. To write to a standard tif file you can use the tiff method. With writeRaster you could also write to a PNG instead
writeRaster(gai_out_r, "gai.png")
Cause of the issue:
I had a similar issue and recognised that the exported .tif files had a different bit depth than .tif images I could open. The images could not be displayed using common applications, although they were not broken and I could open them in R or QGIS. Hence, the values were coded in a way Windows would not expect.
When you type ?writeRaster() you will find that there are various options when it comes to saving a .tif (or other format) using the raster::writeRaster() function. Click on the links therein to get to the dataType {raster} help site and you'll find there are various integer types to choose from.
Solution (write a Windows-readable GeoTIFF):
I set the following options to make the resulting .tif file readable (note the datatype option):
writeRaster(raster, filename = "/path/to/your/output.tif",
format = "GTiff", datatype = "INT1U")
Note:
I realised your post is from 2 and a half years ago... Anyways, may this answer help others who encounter this problem.
I was told once that code is faster to download than image files. Is this true, or is file size the only factor that matters?
For example, I have an SVG file that is a complex illustration. This SVG file is 3.5mb, after optimization using SVGOMG.
I also rendered the illustration as a PNG file. The PNG version has file size of only 153k, after optimization using ImageOptim.
In this scenario, is it true that an SVG file download is faster because it is code - as opposed to a bitmap? OR is the file size the only factor that determines download speed?
The reason I am considering SVG is to preserve the detail of the illustration.
I am creating a PDF using MigraDoc and have now ran into a little problem. I am using a A4 size image (2480px x 3508px / 96KB in size) as a background for my PDF using the following code:
Dim frame = Section.Headers.FirstPage.AddTextFrame
frame.AddImage("background.png")
frame.WrapFormat.Style = WrapStyle.Through
frame.RelativeHorizontal = RelativeHorizontal.Page
Using this causes the PDF to render around 10 times longer (say 10 seconds) then without or a smaller sized file (say 1 second). Is there anyway to speed this up?
I have tried to not use a frame thinking this could be the problem displaying the image using:
Dim backing As Image = Section.Headers.FirstPage.AddImage("background.png")
But still the same results, the reason I want time cut down is I create up to 1000 of these and this can take a long time at the current speed.
I cant downsize the image any more but I don't see why it should be a problem with the size. If this is the problem and there is no way around it please do let me know.
Maybe it goes faster when you use a JPEG file (if that is an option).
JPEG files are copied into the PDF as they are. PNGs and other formats have to be converted into "PDF images".
You can use pages from PDF files just like images. This is another option you can try: once create a PDF with your background image, and create all other files with that PDF instead of the PNG (if JPEG is not appropriate for your image).
There are two builds of MigraDoc: one using GDI+, one using WPF. You could try both to see if that makes a difference.
BTW: Images can be positioned like TextFrames, so there is no need to put an Image into a TextFrame.
I have some swf files generated with Adobe Flash.
Does anybody know how can I decompress their headers in QT?
I need their size (width and height) , frame rate and frame count.
Thanks
It's not documented if qUncompress requires that all compressed data to be in the QByteArray to decompress it. From the wording of it, it seems to imply that. I would imagine loading some large SWF into memory just to get a few bytes in the header is not practical.
If you can live with loading the whole file into memory, just load the file starting at offset 4 into a QByteArray and flip the byte order of the 1st 4 (SWF is little-endian and qUncompress requires the length to be in big-endian). Subtract 4 from the flipped 32-bit integer. Then call qUncompress.
If loading the whole file is not ideal, you may be better off use the stream functions in zlib directly. That allows you to decompress data piece by piece.