I have a stack of images. These images are the IDL output with the .sav extension. I couldn't find a jar file that supports this in imageJ. How do I open these images in ImageJ?
It looks like this is possible using OME Bio-Formats, with a script:
https://docs.openmicroscopy.org/bio-formats/5.9.2/users/idl/index.html?highlight=idl
Edit: this link describes how to read images into IDL, the OP was asking for the opposite.
Related
I have a ID3D11Texture2D and want to write it to disk using literally any picture format (png, bmp, jpeg, ...).
I have already tried to read the docs https://learn.microsoft.com/en-us/windows/win32/api/d3d11/nn-d3d11-id3d11texture2d, which are less than helpful, and i have found an NVIDIA tutorial of how to take individual ID3D11Texture2D and convert them into a video: https://github.com/NVIDIA/video-sdk-samples/tree/master/nvEncDXGIOutputDuplicationSample
However, I dont find anything how to simply write it to disk in any format. I'm sure I'm missing something obvious, any hint would be appreciated.
To experiment, I used https://github.com/NVIDIA/video-sdk-samples/tree/master/nvEncDXGIOutputDuplicationSample, set the frames to capture to 1, and try to write the ID3D11Texture2D to file before encoding to video.
I have a solution for exactly this in the ScreenGrab module which captures a texture (if not already in Map-supporting memory), and then writes it out as a picture using WIC. It handles some edge-cases like "typeless" resources and MSAA as well.
The 'standalone' version is on GitHub here as part of the DirectXTex package:
https://github.com/microsoft/DirectXTex/blob/main/ScreenGrab/ScreenGrab11.h
https://github.com/microsoft/DirectXTex/blob/main/ScreenGrab/ScreenGrab11.cpp
Documentation is here.
ScreenGrab is also included in the DirectX Tool Kit for DX11 and DX12. There's also a basic DX9 version in the DirectXTex package as well.
ScreenGrab can write to any file container supported by WIC. It also has buit-in support for writing DDS files directly without using WIC.
In addition to using ScreenGrab (which is intended as a light-weight screenshot solution), you can also use the DirectTex library to capture a texture and then save it to DDS, HDR, TGA, or any WIC-supported file format.
I like to convert an .jpg or .png file to an .svg format that can be displayed in UIImageView. Is there a way to do this in Objective-C?
You shouldn't use SVG images in Xcode:
it is recommended that you use PNG or JPEG files for most images in your app. Image objects are optimized for reading and displaying both formats, and those formats offer better performance than most other image formats. Because the PNG format is lossless, it is especially recommended for the images you use in your app’s interface.
Also, there's an SVGKit that according to many devs is buggy so use it at your own risk.
SVG is an XML-based vector and in Xcode you can also use vectors but using a PDF format and follow this tutorial.
In a nutshell:
Generate PDFs With the #1x Asset (During compile time it will generate #2 and #3)
Set the Scale Factors to Single Vector:
Drag and Drop Your PDF Into the All, Universal Section
Refer to Your Image by Its Name, Like for any PNG File
[UIImage imageNamed:#”Home”]
Also, stackoverflow (perhaps) related answer
To convert PNG to SVG (Which is a very sensible and valid thing to do) you need an app or library called a "tracer". It will trace the outlines of shapes, gradients, etc and convert them into vector representations.
For simple cases, this is easy for a computer to do; for complex cases (e.g. gradients), this is a very hard AI / Computer-Vision problem and you'd need to spend $$$ on high-end coding solutions and/or find PhD-level research that solves the problem!
A free tracer that does a very good job is built-in to Inkscape (open-source) - google "inkscape trace" for tutorials on how to use it, and to generate a .svg file that you can use. This is a manual process.
To use this in-app, you need to find a tracing library for iOS. The libraries that Inkscape uses are all open-source, so you could try converting them to iOS - they're written in C, so it could be quite easy.
Hi i want to generate tesseract OCR training data file(tessdata). I'm using jTessBoxEditor tool(On Mac Os) for achieving this, but i have no idea how can i use this tool.And further i use the tessdata file in my ios application.
I'm also searching for this i share the links with you
http://vietocr.sourceforge.net/training.html
http://code.google.com/p/tesseract-ocr/wiki/TrainingTesseract3
but i have no luck :( . So please share the links which provide detail/steep by by steep implementation of training file(teasdata file).
Here is the download for the tess files
http://code.google.com/p/tesseract-ocr/downloads/detail?name=tesseract-ocr-setup-3.02.02.exe&can=2&q=
I'm on the same page as you with getting this to work. Here is the tut im using.
http://www.resolveradiologic.com/blog/2013/01/15/training-tesseract/
I have learned that you need a .tif file with a .box file in the same folder to load the boxes.
For Example
testdata.tif
testdata.box
anotherExample.eng.tif
anotherExmaple.eng.box
To create box files easily if you don't know how do this after you download and install the tesseract files.
->Open command prompt and CD to your tesseract file, which is usually in your programfiles/Tesseract-ocr folder
-> Run Box creator tesseract C:\location of the tif file\thetiffile.tif C:\location of the tif file\thetiffile.tif
batch.nochop makebox
and that should spit out the box file you need.
I'm in the process of going through and discovering. I will keep you updated. If you have any other issues let me know and maybe I can help.
You'll have to build or install all the Tesseract training executables first. Then inside jTessBoxEditor, set the appropriate Tesseract Executable location.
I am looking to integrate opening/viewing CBZ/CBR file in iOS6 (A simple viewer like UIWebView that reads PDF file will be fine as well).
Are are there any libraries (Commercial or free) that are available for opening these file types?
Thanks in Advance
CBR files are renamed .rar files and CBZ files are renamed .zip files, so you can look for a solution from there. I've never come across a library file specifically targeted for them, but that might not exclude the possibility of one existing, but as they're just standard compression files renamed to make them more portable between CBR/CBZ readers you should be okay with standard decompression libraries.
The library will spit out a number of image files when the decompression has finished, if you extract one with a standard decompression tool you'll see how they'll be presented.
Those who know C++ may know what I mean by 'unity build':
*.cpp files of a project are all effectively #include-ed into a single supermassive source file following #include directives specified in *.cpp and *.h files
this source file is fed into the compiler
finish! You get the output binary!
Doing things this way means that there are that there are fewer intermediate files (*.o), fewer file reads and disk IO overheads, fewer invocations of the compiler, leading to a better build performance.
My question is, is this possible for Latex at all? I want it because there is a slow post-processing pass that I would like to run over .tex files before building my final .pdf using pdflatex. Currently, it takes around 7 seconds to process my growing list of .tex files. I believe that running this pass over one file is significantly faster. This motivates my question!
To summarize, I want to
'merge' all the .tex files into a supermassive .tex source file by following the \input{} and \include{} macros in each .tex file
feed the supermassive .tex source file into the slow post-processing pass (actually the Ott tex-filter, fyi)
pipe the output straight into pdflatex
finish! I get the output PDF file!
The first step is the problem here. Any ideas welcome. It's best if I don't need to write my own script to do this step!
Many thanks!
A good tool that can handle this is rubber, with the help of its combine module. It will gather all dependencies, and produce a single file ready for consumption.