Summarization:
Calculations point out in a straight-forward way that: A .BMP picture of 3289 X 4570 X 32bpp takes about 53MB. The picture of same size but 24bpp takes about 43MB, that of 16bpp takes about 28MB. ChemDraw-processed picture file must then be converted from 24bpp to 16bpp in my situation.
Further comparison of the hex data of both files gives more detailed understanding of the difference between ChemDraw-processed picture and the original picture. Specifically, ChemDraw stores "EMF_STRETCHDIBITS" instead of "EMF_STRETCHBLT". It should be added that "EMF_STRETCHDIBITS" can be done by calling StretchDIBits when copying pixels into TMetaFile/TMetaFileCanvas. It should be also noted that pixels for "EMF_STRETCHDIBITS" should be the same as those for "EMF_STRETCHBLT".
Unfortunately, till now I didn't find out how ChemDraw exactly processes and stores pasted pictures. That is to say, I didn't find out why the pixels ChemDraw stored is different from what I can obtain programingly.
PS: I will vote up kind answers regarding this question later because I do not have enough reputation for the moment. Thanks for everybody who has been kind to comment!
＝＝＝
Hi,
Thanks for your time very much!
Say that I have a picture named "sample_original.bmp". The file size is 3289 X 4570, 43MB. Then I do the following to convert it into a .EMF file (Enhanced Windows MetaFile):
Method 1, by making a small in-house Delphi program:
(1) Load the .BMP image file.
(2) Obtain the Canvas of TMetaFile(TMetaFileCanvas)
(3) Call Canvas.Draw to copy the image.
(4) Save to .EMF file, named "sample_original_bmp2emf_method1.emf"
Method 2:
(1) Open the .BMP image file in the mspaint program, choose "select all", and choose "copy".
(2) Open an external program called ChemDraw, create new document, and choose "paste".
(3) Then I choose to save that in the XML-compatible .cdxml format, named "sample_original_bmp2emf_method2.cdxml".
(4) The content of picture (maybe changed or degraded?) is now saved in the sample_original_bmp2emf_method2.cdxml file. The format is Base64-encoded zlib-compressed format.
(5) I can Base64-decode the XML string, zlib-decompress it, and save it into the picture file "sample_original_bmp2emf_method2.emf".
The file size of sample_original_bmp2emf_method2.emf is smaller by 15 MB than sample_original_bmp2emf_method1.emf, but the width & height has been maintained.
Furthermore, if I open "sample_original_bmp2emf_method2.emf" in the mspaint program and save it back into .bmp file format, a warning pops up that transparent information is losing.
Could you help to comment on how to tell the difference "sample_original_bmp2emf_method1.emf" & "sample_original_bmp2emf_method2.emf"? Is the picture smaller because its quality is decreased?
In other words, what changes to my original picture could possibly be made by this external program?
Best wishes,
The files mentioned above can be downloaded in the following url:
http://www.rapidspread.com/file.jsp?id=2ighvzoci8
PS: I believe that Andreas Rejbrand has be kind enough to made his answer and I then gave my comments. But I cannot see those now. Is it supposed to be normal behavior of the system? o_o
You wrote:
Base64-decode the XML string, zlib-decompress it, and save it into the picture file "sample_original_bmp2emf_method2.emf".
So it's definitively NOT an emf file, but some zipped format..
Or it was converted to another format (like vectorial) before converting to XML. In this case, you've less data in the resulting picture than a real bitmap.
Whereas the first method will give you an emf file with a size of only a few bytes bigger than a plain bmp file (i.e. the emf records used to encapsulate the bitmap data).
If you zip the emf file of the first method, I'm quite sure you'll get a file with a smaller size than the false emf obtained by method two.
Why don't you just compare the two images? Open them in a raster editing program and compare the pixels.
Why do you care how big the files are? Surely what's important is whether or not the image is the right one.
Related
Noticed that images sometimes are sliced up in PDFs.
Steps:
insert an image with a high resoultion (3000x1800) into a .docx
use "Microsoft Print to PDF" option of Word to convert to PDF
extracting all images with pdfimages or pymupdf
Result:
Image is sliced horizontally into three images
Questions:
What exactly happens in the in the transition from .docx to pdf (or in generell in the process to pdf) that makes the converter slice it up into three images instead of one?
Do the individuell XObjects of the sliced images contain information which says that these three images belong to originally one?
How do I know how the images are sliced (horizontally / vertically) and what if originally there were two images inserted into the .docx file and both of them are sliced. Can you tell if slice x belongs to original image y or z?
So, as you have found out: because the code which generates the PDF choose to do so.
The technical reasons may be various - it could be that historically there were printers which would only have so much memory, and would need to get limiterd size-images when printing, and someone at some point when writing the PDF export code present in Microsoft Office choose to apply this limit.
Anyway, technically, as put in the comments, an image in a PDF file could be composed of unlimited smaller images collated together.
Now, the second part, and your actual question: to know whether images ibn a PDF file belong together in a single original image one would need a custom extractor tool to check the geometry of all images in the document and find out which images have no margins or boundaries with others - it would not be that hard to do for well behaved files (which we can't know if MS Office generated files are: there are ways to obfuscate image positioning by making it indirectly). The metadata in the image-parts may or may not contain information that would allow one to recompose the original image: it would be up to the code generating the PDF to include this metadata or not - but the geometry can't lie in this case: if the final document presents a single image visually, it is possible to detect that when fetching the images.
I'm kinda new to messing with hex and I'm trying to replace a .PNG inside a file with HxD and I get a "This operation changes the file-size." error. The file I'm replacing it with is definitely smaller so it shouldn't be an issue (right?) but when viewing the PNG hex it has a much larger length than the file I'm trying to replace. I've looked around for help but can't seem to find anything so would be awesome if someone could point me in the right direction, thanks in advance.
That message sounds like you need to add padding to the new file. Best bet would be to use 00 (null)
Figure out the exact size in bytes of the old file, note that down.
Figure out the exact size in bytes of the new file, note that down as well.
calculate the needed padding.
Open your new png file in HxD, go to the edit menu and select Insert Bytes.
Before you type in a number, just below that there are three options, select dec. Then type in the amount of bytes to add.
Leave the fill pattern as 00. When you hit okay the program will warn that you're changing the length of the file, this is okay, that is why you're using the option.
Save your new file using File -> Save As.
screenshot of the Insert Bytes window
You could use HxD to get the sizes of the files, convert the hex offset to a decimal number, or do everything in hex if that suits you.
can anyone help me to save my resulted images by using imwrite
source = 'C:\Y\';
im_number=5;
for i=1:5
image{i}=im2double(imread([source,'Carbon_', num2str(i)],'tif'));
image{i}=double(image{i});
B{i}= Sftfun(image{i});
B{i}=uint32(B{i});
imwrite(B{i},[source,'face_', num2str(i)],'tif');
end
The problem with your code is that you are casting your image to uint32. If you are trying to save your image as a TIF file, you can only save it as 8-bit or 16-bit. Consulting the MATLAB documentation, you can only save with these two bit depths. 32-bit depths are not supported.
Consult the MATLAB documentation for more details: http://www.mathworks.com/help/matlab/ref/imwrite.html
As such, either cast the image as 8-bit or 16-bit (through im2uint8 or im2uint16), or normalize your image so that it goes from [0,1] (through im2double).
I also have some comments about your code that do need fixing for readability:
Do not save your images to a cell array called image. MATLAB has a built-in command called image which takes in a matrix and displays it to the screen for you as an image. Bear in mind this is not the same as imshow. By doing this assignment, you will shadow over the actual image command, and so any scripts that rely on this function will result in an error.
im_number seems to be an unused variable. I'm not sure what its purpose is, but I'd say it's safe to remove this statement as well.
Get rid of the following statement as you are already converting the image to a double type in the previous line:
image{i} = double(image{i});
Aside
It seems that you have asked a similar question here: save tif 32 bit images by using imwrite
This question has already been resolved in that you are not able to save 32-bit images using imwrite. However, someone in this thread has posted a workaround for you to use in MATLAB. Try using that instead of imwrite.
HOw ot compare 3D image files in testcomplete. My application processes some 3D images i want it to be compared with the reference. Image file types are .spt, .vtk, .mdb ,.dcm.
Someone help me.
You can probably use checkpoints for this purpose. For example:
To verify an image displayed on screen, use a region checkpoint.
To verify the actual file that holds the image data, use a file checkpoint.
Well, for DICOM images you could think about converting those into bitmaps and have TestComplete compare the bitmaps. Admitted, there is one additional step that you have to take care of, and this is the choice of a (command line) tool that does the conversion for you. I think IrfanView does the job. Give it a try and post your results.
I have an OpenCV matrix of double (CV_32F) values. I'd like to save it to the disk. I know, I could convert it to an 1-Channel 8-bit IplImage and save it. But that way, I loose precision. Is there a way to save it directly in the 32-bit format, without having to convert it first? It also would be nice, if the resulting file would have an image format, so I can view the result as an image.
You can always save any "object" (CvMat, IplImage, anything..) from OpenCV "as is" by using cvSave() and loading it back with cvLoad(). As to my experience, most floating-point image stuff does not work correctly, I usually save my floating point data this way.
However, you cannot directly view the stored data.
Another possibility we have used frequently is including an own built of OpenEXR. You can easily store full precision floating point images using this library and many third party applications are able to open EXR files. Note that OpenCV includes OpenEXR, if i am not mistaken, but the last time i've tried, saving/loading floating point images did not work correctly. However, you should first try to save an fp image as *.exr, maybe that already does the magic with recent versions.
You could always iterate over the matrix and write it out yourself. If you want it to be viewable as an image, you can use a variant of PPM. I'm not sure what programs would be able to natively read your image format if you use values out of the 0-255 range though.
This is old, but thought I'd throw in my two cents.
If you just want to save float images to disk, and you don't need to view them, you may want to look at Portable Float Map (PFM) image format. Very simple format, just saves floats to disk, no compression, minimal header. You can write your own read/write code for this very quickly. That's what I'm using for HDR research.
As the others pointed out, to "view" float images you need to ask yourself some questions about their contents and how to sensibly scale them back into an 8-bit range you can display on your monitor. You might consider Matlab's image viewer (imshow function) which offers some double scaling functionality.
You might also consider saving to either EXR or HDR format and using Photomatix's built-in HDR image viewer which gives you a little separate window that shows you a real-time tonemapped window around your current cursor position. It's a good way to navigate an HDR or floating point image to get a sense of "what's really there" without tonemapping the whole thing.