Is there any way to generate a 16-bits per channel(RGBA) PNG file using D3DX11SaveTextureToFile?
Or any version of DirectX, any image library(C++), any image format
I tried to use the sample code here:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb205131(v=vs.85).aspx
and modified the function names to D3D11 version.
The program works perfectly when I set the desc.Format to DXGI_FORMAT_R8G8B8A8_UNORM .
But the D3DX11SaveTextureToFile returns E_FAIL when I changed the desc.Format to DXGI_FORMAT_R16G16B16A16_UNORM .
I've tried to use DevIL (developer's image library) but it doesn't support 16-bits per channel png file.
The only format which can save all texture-formats is D3DX11_IFF_DDS. It seems that D3DX11SaveTextureToFile can't save 16Bit pngs. One possibility is to extract the imagedata of your texture and save it manually with one of the possibilities (e.g. OpenCV or libpng) discussed here: Writing 16 bit uncompressed image using OpenCV.
Related
There's no support TGA format for OpenCV currently.
And I know there's a single header file library named stb_image that allow you to read/write TGA image.
But the use case with OpenCV on the Internet are so few. (more often to see people use it with OpenGL)
The second method I found.
There's a short code included (the answer) in this topic:
Loading a tga/bmp file in C++/OpenGL
Someone use this code to read TGA file into cv::Mat just like the code below.
Tga tgaImg = Tga("/tmp/test.tga");
Mat img(tgaImg.GetHeight(), tgaImg.GetWidth(), CV_8UC4);
memcpy(img.data, tgaImg.GetPixels().data(), tgaImg.GetHeight() * tgaImg.GetWidth() * 4);
But this is only for reading part. I wonder if stb_image can do the same thing like the code above. I mean the image data structure might be different. (not look into them yet)
I would like to ask people who also experience this before. Since DDS/TGA image format are also popular using in game texture, there must be people have already found the way. I mean read/write TGA format in OpenCV code.
Thanks.
For saving opencv image in tga use stbi_write_tga. This function takes pointer to image data as argument, which is img.data in case of cv::Mat type.
UPDATE:
When taking an iOS-created .bmp and using "Save As..." in Photoshop with "Flip row order" unchecked, this .bmp will then work on the Adafruit PyPortal (thanks John Park for this lead). I've searched in iOS and don't find anything that looks like a "Flip row order" command for bmp image data. Is anyone familiar with how to get iOS data into this "unflipped row order" format?
Thanks!
John
--
The 8-bit bmps I'm creating in Swift on an iOS device aren't showing on an Adafruit PyPortal, but when I run the same bmp (or any other 320 x 240 png or jpeg) through an online bmp converter, it then shows on the PyPortal. Both the before and after bmps are readable by Photoshop & Mac Preview and both show as 8-bit "Windows BMP Image" format files. PyPortal requires "a 320 x 240 pixel RGB 16-bit raster graphic in .bmp format" but going down to 8 bit doesn't make a difference. The bmp file that works (the one run through the online converter) shows on my Mac as a 231 KB file, while the bmp that doesn't (the one as created in Swift) shows as 230 KB.
I've put both files in a Google Drive at:
https://drive.google.com/open?id=1DQYes-cJXKm3ue8Z9cACDLEN5bxnnkJc
The one that works (created in Swift, but then run through the bmp converter) is named:
adafruit-log-as-iOS-created-bmp-then-converted-online-shows-in-PyPortal.bmp
And the one that doesn't work (just created in Swift) is named:
adafruit-log-as-iOS-created.bmp
(On Google Drive they both show as 225 KB files
The technique I use to create the bmp in Swift is the one employed when I answered the question at:
How to convert UIImage to BMP and save as Data (not JPG or PNG)
and uses the helpful extension from #vasily-bodnarchuk via:
Convert UIImage to NSData and convert back to UIImage in Swift?
When I run the files through a byte-by-byte comparison engine like https://www.diffnow.com show there are differences between the files.
I'm hopeful someone can quickly size up the difference between the formats of these two bmps and offer insight in getting the Swift code to create something that the Adafruit PyPortal can use.
Thanks to anyone with the stamina to follow this far. Cheers!
I had a similar problem. I ended up editing the file with Paintbrush on the Mac and saving as a .PNG file. Then used python3 Pillow to reformat the image to a bitmap. To make this work you need to:
1) Create a PNG file in Paintbrush ( you can load an existing IOS or OSX bitmap file then save it as a PNG file in Pantbrush.
2) install Pillow:
python3 -m pip install Pillow
3) Write a simple python3 program to convert the image e.g.:
from PIL import Image # note Pillow is a fork of PIL but the Image object is in PIL
Image.open("pngFile.PNG").save("bitmapFile.bmp")
3) Run the program.
This worked for me. Good luck.
This worked for me to edit bitmap files for PyPortal Titano.
For a specific purpose I am trying to convert an AVI video to a kind of Moving JPEG format using OpenCV. In order to do so I read images from the source video, convert them to JPEG using imEncode, and write these JPEG images to the target video.
After several hundreds of frames suddenly the size of the resulting JPEG image nearly doubles. Here's a list of sizes:
68045
68145
68139
67885
67521
67461
67537
67420
67578
67573
67577
67635
67700
67751
127800
127899
127508
127302
126990
126904
Anybody got a clue what's going on here?
By the way: I'm using OpenCV.Net as a wrapper for OpenCV.
Thanks a lot in advance,
Paul
I found the solution. If I explicitly enter the third parameter to imEncode (for JPEG encoding this indicates the quality of the encoding, ranging from 0 to 100) instead of using the default (95) the problem disappears. It's likely this is a bug in OpenCV.Net, but it could also be a bug in OpenCV itself.
Is there anyway (commandline tools) to calculate MD5 hash for .NEF (also .CR2, .TIFF) regardless any metadata, e.g. EXIF, IPTC, XMP and so on?
The MD5 hash should be same once we update any metadata inside the image file.
I searched for a while, the closest solution is:
exiftool test.nef -all= -o - -m | md5
but 'exiftool -all=' still keeps a set of EXIF tags in the output file. The MD5 hash can be changed if I update remaining tags.
ImageMagick has a method for doing exactly this. It is installed on most Linux distros and is available for OSX (ideally via homebrew) and also Windows. There is an escape for the image signature which includes only pixel data and not metadata - you use it like this:
identify -format %# _DSC2007.NEF
feb37d5e9cd16879ee361e7987be7cf018a70dd466d938772dd29bdbb9d16610
I know it does what you want and that the calculated checksum does not change when you modify the metadata on PNG files for example, and I know it does calculate the checksum correctly for CR2 and NEF files. However, I am not in the habit of modifying RAW files such as you have and have not tested it does the right thing in that case - though I would be startled if it didn't! So please test before use.
The reason that there is still some Exif data left is because the image data for a NEF file (and similar TIFF based filetypes) is located within that Exif block. Remove that and you have removed the image data. See ExifTool FAQ 7, which has an example shortcut tag that may help you out.
I assume your intention is to verify the actual image data has not been tampered with.
An alternate approach to stripping the meta-data can be to convert the image to a format that has no metadata.
ImageMagick is a well known open source (Apache 2 license) for image manipulation and conversion. It provides libraries with various language bindings as well as command line tools for various operating systems.
You could try:
convert test.nef bmp:- | md5
This converts test.nef to bmp on stdout and pipes it to md5.
AFAIR bmp has no support for metadata and I'm not sure if ImageMagick even preserves metadata across conversions.
This will only work with single image files (i.e. not multi-image tiff or gif animations). There is also the slight possibility some changes can be made to the image which result in the same conversion because of color space conversions, but these changes would not be visible.
I'm having a proprietary image format SNG( a proprietary format) which is having a countinous array of Image data along with Image meta information in seperate HDR file.
Now I need to convert this SNG format to a Standard TIFF 6.0 Format. So I studied the TIFF format i.e. about its Header, Image File Directories( IFD's) and Stripped Image Data.
Now I have few concerns about this conversion. Please assist me.
SNG Continous Data vs TIFF Stripped Data: Should I convert SNG Data to TIFF as a continous data in one Strip( data load/edit time problem?) OR make logical StripOffsets of the SNG Image data.
SNG Data Header uses only necessary Meta Information, thus while converting the SNG to TIFF, some information can’t be retrieved such as NewSubFileType, Software Tag etc.
So this raises a concern that after conversion whether any missing directory information such as NewSubFileType, Software Tag etc is necessary and sufficient condition for TIFF File.
Encoding of each pixel component of RGB Sample in SNG data:
Here each SNG Image Data Strip per Pixel component is encoded as:
Out^[i] := round( LineBuffer^[i * 3] * **0.072169** + LineBuffer^[i * 3 + 1] * **0.715160** + LineBuffer^[i * 3+ 2]* **0.212671**);
Only way I deduce from it is that each Pixel is represented with 3 RGB component and some coefficient is multiplied with each component to make the SNG Viewer work RGB color information of SNG Image Data. (Developer who earlier work on this left, now i am following the trace :))
Thus while converting this to TIFF, the decoding the same needs to be done. This raises a concern that the how RBG information in TIFF is produced, or better do we need this information?.
Please assist...
Are you able to load this into a standard windows bitmap handle? If so, there are probably a bunch of free and commercial libraries for saving it as TIFF.
The standard for TIFF is libtiff -- it's a C library. Here's a version for Delphi made by an expert in the TIFF format:
http://www.awaresystems.be/imaging/tiff/delphi.html
There seems to be a lot of choices.
I think the approach of
Loading your format into an in-memory standard bitmap (which you need to do to show it, right?)
Using a pre-existing TIFF encoding library to save as TIFF
Will be a lot easier than trying to do a direct format-to-format conversion. The only reasons I wouldn't do it this way are:
The bitmap is too big to keep in memory
The original format is lossy and I will lose more quality in the re-encoding -- but you'd have to be saving in a standard lossy format (JPEG) to save quality.
Disclaimer: I work for Atalasoft.
We make .NET imaging codecs (including TIFF) -- that are a lot easier to use than LibTiff -- you can call them in Delphi through COM. We can convert standard windows bitmaps to TIFF or PDF (or other formats) with a couple of lines of code.
One approach, if you have a Windows application which handles and can print this format, would be to let it do the work for you, and call it to print the file to one of the many available 'printer drivers' which support direct output to TIFF.