I want to cut this hemisphere:
my code is:
difference() {
import("../kupol.stl");
translate([-150,-1,-1]) cube(500);
}
at preview result is ok:
but after rendering (F6 key) I received an empty object:
Rendering was finished without any errors:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 15
Geometry cache size in bytes: 3178728
CGAL Polyhedrons in cache: 12
CGAL cache size in bytes: 0
Total rendering time: 0 hours, 0 minutes, 0 seconds
Rendering finished.
I'm using OpenSCAD version 2015.03-2 at Windows 7 64bit machine.
Here is detailed information about my build and here is stl with hemisphere which I need to cut.
What am I doing wrong?
The STL has probably some problems. Make sure it's manifold (which can be checked with most mesh editors, e.g. MeshLab, Blender, Netfabb).
Also have a look at the FAQ which explains an additional issue that can cause OpenSCAD to have problems with the STL (Zero-Faces = Triangles that have no area).
Related
Per https://stackoverflow.com/a/17822099/1639359 using resample=PIL.Image.BICUBIC should retain quality through rotation. This question is follow up from my comment on the above answer that it is not working for me.
What version of Python and PIL do we have:
import sys
print(sys.version)
3.7.3 (default, Mar 27 2019, 22:11:17)
[GCC 7.3.0]
import PIL
import PIL.Image
print(PIL.__version__)
print(PIL.Image.__version__)
6.2.1
6.2.1
Open our test image, and save it. Notice the loss of quality; saved file is much smaller than original:
img = PIL.Image.open('test_image.jpg')
holdexif = img.info['exif']
img.save('testsave.jpg',"jpeg",exif=holdexif)
%ls -l 'test_image.jpg'
%ls -l 'testsave.jpg'
-rwxrwxrwx 1 dino dino 1926859 Dec 24 21:28 test_image.jpg*
-rwxrwxrwx 1 dino dino 452343 Dec 27 13:16 testsave.jpg*
Per Determining JPG quality in Python (PIL) setting quality='keep' prevents the loss of quality on save:
img.save('testsave.jpg',"jpeg",exif=holdexif,quality='keep')
%ls -l 'test_image.jpg'
%ls -l 'testsave.jpg'
-rwxrwxrwx 1 dino dino 1926859 Dec 24 21:28 test_image.jpg*
-rwxrwxrwx 1 dino dino 1926911 Dec 27 13:16 testsave.jpg*
If we rotate the image, two things happen:
img.format disappears
quality is reduced significantly (even though we use resample=PIL.Image.BICUBIC)
print(img.format)
JPEG
rotated_img = img.rotate(-90,resample=PIL.Image.BICUBIC,expand=True)
print(img.format)
print(rotated_img.format)
JPEG
None
Saving the rotated file shows the loss of quality:
rotated_img.format="JPEG" # quality='keep' will raise exception if format != 'JPEG'
rotated_img.save('testsave.jpg',"jpeg",exif=holdexif,quality='keep')
%ls -l 'test_image.jpg'
%ls -l 'testsave.jpg'
-rwxrwxrwx 1 dino dino 1926859 Dec 24 21:28 test_image.jpg*
-rwxrwxrwx 1 dino dino 450997 Dec 27 13:16 testsave.jpg*
Questions:
1. What, if anything, am I doing wrong?
2. Why does img.format disappear on rotate? What else is disappearing?
3. And, just as an aside, is there another way to detect the loss of quality (I only know to save the file and see that it is much smaller).
After #MarkRansom 's comments, I would like to add some color to my question: Although I have been coding for many years, I only last week began playing with images. Without a doubt my knowledge of image processing is minimal at best, with significant gaps and misunderstandings about how things work.
That said, from a coding perspective, I would expect that a method on an object would do pretty much only what that method suggests, with no side effects. For example, I would expect rotate() only to rotate the image, and not clear out meta data at the same time. Even if, let's say for efficiency sake, the default behavior for the PIL package is to always drop the meta data, I would hope there would be an option (either global, or on a per-method basis) for something like preserve_metadata=True
Regarding "the only good way to judge quality" being "to look at the images themselves," I can certainly understand that being the case on an absolute basis. However on a relative basis, most notably when comparing the "same" image before and after some processing, it seems to me there could be ways to physically measure, or at least estimate, the difference in quality before and after the processing. (Of course, I don't yet know enough about images to know what the best method of doing that would be; thus part of the reason for my question). It also seems to me (at least from my beginner perspective) that very often people would want to do whatever processing that want to do with little or no loss of quality at the same time. Thanks for your patience and help filling in my knowledge gaps, and with the answers.
In general, any image rotation is going to result in a loss of image quality simply because the output requires an interpolation of the input for pixels that don't map 1:1 from input to output. For rotations of multiples of 90 degrees, it's possible to get a 1:1 mapping and do a lossless rotation. It's not clear if PIL/Pillow is smart enough to do that, but it might. Your example rotates by -90 degrees so you could luck out.
The metadata is being lost because rotate generates a new image, it doesn't modify the existing one. It's not easy to determine which metadata might be relevant for the new image, so the safest course of action is to simply not copy any of it. As you've discovered, it's possible to manually copy anything you think is important. I don't think there's an option to automatically copy anything.
As noted in the comments, using file size as a judge of image quality is a very poor metric. A smaller size is suggestive of poorer quality, but it doesn't have to be so; the whole premise of JPEG compression is that some image degradations simply won't be visible in normal viewing. A visual comparison is the ultimate test. If you must have an automated comparison there are methods to do so, but I don't think any have emerged as the undisputed best way to compare.
You rotated the image, which creates a new generic image. There is no 'keep' in this instance. When saving to JPEG, default quality is 75, high quality is 95.
Need to copy quality, perhaps tables, and metadata to the new image, just as you are doing with the Exif.
Setup
I am using a custom RenderBox to draw.
The canvas object in the code below comes from the PaintingContext in the paint method.
Drawing
I am trying to render pixels individually by using Canvas.drawRect.
I should point out that these are sometimes larger and sometimes smaller than the pixels on screen they actually occupy.
for (int i = 0; i < width * height; i++) {
// in this case the rect size is 1
canvas.drawRect(
Rect.fromLTWH(index % (width * height),
(index / (width * height)).floor(), 1, 1), Paint()..color = colors[i]);
}
Storage
I am storing the pixels as a List<List<Color>> (colors in the code above). I tried differently nested lists previously, but they did not cause any noticable discrepancies in terms of performance.
The memory on my Android Emulator test device increases by 282.7MB when populating the list with a 999x999 image. Note that it only temporarily increases by 282.7MB. After about half a minute, the increase drops to 153.6MB and stays there (without any user interaction).
Rendering
With a resolution of 999x999, the code above causes a GPU max of 250.1 ms/frame and a UI max of 1835.9 ms/frame, which is obviously unacceptable. The UI freezes for two seconds when trying to draw a 999x999 image, which should be a piece of cake (I would guess) considering that 4k video runs smoothly on the same device.
CPU
I am not exactly sure how to track this properly using the Android profiler, but while populating or changing the list, i.e. drawing the pixels (which is the case for the above metrics as well), CPU usage goes from 0% to up to 60%. Here are the AVD performance settings:
Cause
I have no idea where to start since I am not even sure what part of my code causes the freezing. Is it the memory usage? Or the drawing itself?
How would I go about this in general? What am I doing wrong? How should I store these pixels instead.
Efforts
I have tried so much that did not help at all that I will try to only point out the most notable ones:
I tried converting the List<List<Color>> to an Image from the dart:ui library hoping to use Canvas.drawImage. In order to do that, I tried encoding my own PNG, but I have not been able to render more than a single row. However, it did not look like that would boost performance. When trying to convert a 9999x9999 image, I ran into an out of memory exception. Now, I am wondering how video is rendered as all as any 4k video will easily take up more memory than a 9999x9999 image if a few seconds of it are in memory.
I tried implementing the image package. However, I stopped before completing it as I noticed that it is not meant to be used in Flutter but rather in HTML. I would not have gained anything using that.
This one is pretty important for the following conclusion I will draw: I tried to just draw without storing the pixels, i.e. is using Random.nextInt to generate random colors. When trying to randomly generate a 999x999 image, this resulted in a GPU max of 1824.7 ms/frames and a UI max of 2362.7 ms/frame, which is even worse, especially in the GPU department.
Conclusion
This is the conclusion I reached before trying my failed attempt at rendering using Canvas.drawImage: Canvas.drawRect is not made for this task as it cannot even draw simple images.
How do you do this in Flutter?
Notes
This is basically what I tried to ask over two months ago (yes, I have been trying to resolve this issue for that long), but I think that I did not express myself properly back then and that I knew even less what the actual problem was.
The highest resolution I can properly render is around 10k pixels. I need at least 1m.
I am thinking that abandoning Flutter and going for native might be my only option. However, I would like to believe that I am just approaching this problem completely wrong. I have spent about three months trying to figure this out and I did not find anything that lead me anywhere.
Solution
dart:ui has a function that converts pixels to an Image easily: decodeImageFromPixels
Example implementation
Issue on performance
Does not work in the current master channel
I was simply not aware of this back when I created this answer, which is why I wrote the "Alternative" section.
Alternative
Thanks to #pslink for reminding me of BMP after I wrote that I had failed to encode my own PNG.
I had looked into it previously, but I thought that it looked to complicated without sufficient documentation. Now, I found this nice article explaining the necessary BMP headers and implemented 32-bit BGRA (ARGB but BGRA is the order of the default mask) by copying Example 2 from the "BMP file format" Wikipedia article. I went through all sources but could not find an original source for this example. Maybe the authors of the Wikipedia article wrote it themselves.
Results
Using Canvas.drawImage and my 999x999 pixels converted to an image from a BMP byte list, I get a GPU max of 9.9 ms/frame and a UI max of 7.1 ms/frame, which is awesome!
| ms/frame | Before (Canvas.drawRect) | After (Canvas.drawImage) |
|-----------|---------------------------|--------------------------|
| GPU max | 1824.7 | 9.9 |
| UI max | 2362.7 | 7.1 |
Conclusion
Canvas operations like Canvas.drawRect are not meant to be used like that.
Instructions
First of, this is quite straight-forward, however, you need to correctly populate the byte list, otherwise, you are going to get an error that your data is not correctly formatted and see no results, which can be quite frustrating.
You will need to prepare your image before drawing as you cannot use async operations in the paint call.
In code, you need to use a Codec to transform your list of bytes into an image.
final list = [
0x42, 0x4d, // 'B', 'M'
...];
// make sure that you either know the file size, data size and data offset beforehand
// or that you edit these bytes afterwards
final Uint8List bytes = Uint8List.fromList(list);
final Codec codec = await instantiateImageCodec(bytes));
final Image image = (await codec.getNextFrame()).image;
You need to pass this image to your drawing widget, e.g. using a FutureBuilder.
Now, you can just use Canvas.drawImage in your draw call.
HOW THE Viewports look after loading the file:
I am having an issue caused by extremely large objects (in terms of physical size not polycount etc.) that I imported from a game using ninjaripper (a script used for extracting 3d models from games). When I open the file containing these large objects, the objects are only rendered in the left orthographic viewport. All other viewports/views do not show the geometry regardless of which rendering mode (wireframe, edges faces etc.) I have selected on said viewports. The objects are also not visible in perspective views. When I unhide all items apart from a single object (of normal size) I am able to see the object in all viewports including perspective viewports. When I unhide all again, the object which could previously be seen disappears. When switching to perspective view when these extremely large objects are present, the 'viewcube' disappears for an unknown reason. Zooming in or out in a perspective viewport also results in the viewcube disappearing. This is the only scene I've had so far which shows these issues, all my graphics drivers are up to date (specs listed below). The scene contains 3602 objects and has 1,957,286 polygons and 1,508,550 vertices.
This is the furthest I could zoom out in 3ds max:
Viewcube has disappeared on top right and bottom right viewport:
I tried removing all of the extremely large objects by hand, after which the remaining (normal sizes) objects could be seen in 2 of the viewports (top left and top right viewport did render correctly).
Viewports after having deleted all extremely large objects:
I tried resetting the scene, after which I merged the scene containing all 'normal sized objects' into an empty scene. This resulted in all viewports rendering the objects correctly. However, after saving the file and re-opening the saved file, 2 of the 4 viewports did not render the objects as was the case after just having deleted all but the 'normal sized' objects.
My question is: how should I deal with these extremely large imported objects in order to fix the viewport rendering issues they cause?
I wrote a simple bit of maxscript code to print out the maximum size of the biggest object in the scene, which resulted in a value of 2.6*10^38 [generic units], which, according to my calculation corresponds to a value of 6.6*10^36 [meters], in summary: extremely large. (I suspect the ninjaripper script or the script which imports the files produced by the ninjaripper into 3ds max had some sort of error causing some of the vertices to have extremely large position values). When I switch to the measure tap in 'utilities' and press Ctrl+A to select all objects in the scene (the scene containing all objects including the extremely large objects), 3ds max crashes due to the large object size (error message: "Application error- An error has occured and the application will now close. No Scene changes have occured since your last save.").
I could write some maxscript code which deletes all objects which are larger then a certain size (for example: 10^5 [meters]). However, as afore mentioned this for some reason does not fix the issue completely (after saving the scene with only 'normal sized' objects and re-opening the scene only 2 of the 4 viewports render the objects correctly. I ran the code for measuring the max size of the largest object in the scene again after having deleted all extremely large objects to check if I had indeed not skipped over one of these large objects, the result was a value of: 121.28 [generic units] (corresponding to object: "Mesh_3598") which is a relatively normal size, however 2 of my 4 viewports are not rendering my objects even after deleting the large objects (only when the left orthographic view is selected they can be seen in the 2 viewports that do not render part of the time).
Code for checking largest object (also prints out maximum size of this object):
global_max=0
largest_obj=undefined
for obj in geometry do(
obj_max_x = (obj.max.x-obj.min.x)
obj_max_y = (obj.max.y-obj.min.y)
obj_max_z = (obj.max.z-obj.min.z)
local_max = amax(#(obj_max_x, obj_max_y, obj_max_z ))
if local_max > global_max do
global_max = local_max ; largest_obj = obj
)
messagebox ("global max = " + global_max as string)
messagebox ("largest obj = " + largest_obj as string)
See the following links for the 3ds max scene files I have mentioned:
https://drive.google.com/open?id=1bAilmaHAXDr4WuD8gGS4piQfPzzJM9MH
Any suggestions/help will be greatly appreciated. Thank you very much!
System specs:
-Autodesk 3ds max 2018 x64
-Windows 10 PRO x64
-i5 6600k #3.5ghz
-msi z170a gaming m7 - socket 1151 - atx
-coolermaster g750m -750watt
-msi radeon r9-390x gaming -8gb
-noctua NH-D15
-kingston hyper-x fury black 16gb-pc-21300-dimm-4x4gb#2666mhz
As it turns out the extremely large objects were indeed causing the viewport rendering error. After removing all object's with a maximum size of 100000 [generic units] the viewport rendering errors were gone. I suspect the issue was caused by the objects not being in between the viewport's far and near planes due to the extremely large object sizes.
I am making a simple test game in unity3d using c#, the size of the apk of my game is 70 MB.I have reduced the resolution of each and ever sprites, but its still 58 MB, how do i compress the game so that the apk file is of the least possible size.
Apart from following this short guide by Unity themselves, there are a couple things to keep in mind:
Files which are not used or dependent on are removed by Unity when building.
Textures, music and videos take up most of the size. Sound files should ideally be .mp3 format (otherwise .wav for very short clips).
I would recommend you go through the link above and properly analyse Editor.log as it provides valuable information to trim the build size.
You can also choose to set the Device filter to Arm7. This will exclude certain devices, but I believe the number is quite small and it does minimize the apk size a bit. (This is located in Player Setting -> Other Settings -> Device Filter). You could try a build and see how much it would reduce it by and decide whether it was worth it.
Some Info on device filter: http://answers.unity3d.com/questions/971648/device-filter-to-arm-7-only.html
Additionally, if you look in your editor build file you can find information on what is taking up the majority of space in your build (it is a long log so you'll have to search for the right parts). There should be a part in it after you do a build that will list how much space things are taking up. It will be followed by a list of the assets from largest to smallest so you can identify particular assets that may be too large.
E.g.
Build Report
Uncompressed usage by category:
Textures 81.1 mb 92.0%
Meshes 0.0 kb 0.0%
Animations 17.1 kb 0.0%
Sounds 0.0 kb 0.0%
Shaders 90.0 kb 0.1%
Other Assets 549.9 kb 0.6%
Levels 338.3 kb 0.4%
Scripts 993.0 kb 1.1%
Included DLLs 5.1 mb 5.8%
File headers 33.1 kb 0.0%
Complete size 88.2 mb 100.0%
How to find editor file: https://docs.unity3d.com/Manual/LogFiles.html
One most effective and important change for reduce image size is
Set your image size square and
Set unity suggested pixels.(32, 64, 128, 256, 512, 1024, 2048, 4096, 8192)
If your image size is 567x890 pixels then set this image in a 1024x1024 pixels background transparent blank image and save it as a png file.
Then in unity inspector set this image as a sprite and slice it by sprite editor.
This process will make your image size reduce minimum 20%.
Example image and changes given below.
Before: resolution 567x890 pixel, size 1.9MB
After: resolution 1024x1024 pixel, size 1.3MB
Result: size 0.6MB reduced, almost 32%.
Image file Link: https://drive.google.com/file/d/0B9zkzr6JdNYlaHhqcDVUSk9KNjA/view
It is also good to set texture / sprite compression format.
Check this website:
https://docs.unity3d.com/Manual/class-TextureImporterOverride.html
Most texture compression format needs image in power of 2 resolution (128, 256, 512, 1024, 2048). Resolutions 4096 and 8192 may not work on some android devices.
For example texture with no alpha in 1024x1024 resolution using RGB ETC2 compressions takes about 0,5MB in memory. Image 1280x800 with compression format RGB 16bit takes 2MB.
We are using tycho v0.13 and maven 3.0 for building our product.
We get the following error/warning when building
Error - 7 icon not replaced in C:\Users\AppData\Local\Temp\p2.brandingIron7115583353836584113\launcher.exe using D:\Builds\workspace\plugins\icons\app-icon.ico
the ico files are all proper.
as a result window icons are being replaced by the standard eclipse icons.
I'm not overly familiar with Tycho itself, but here I believe it is using the branding code that ships with p2 (and which originally came from PDE/Build).
The code extracts the icon images from the originating launcher executable and searchs for matching images in the provided ico file. If an image is found that matches the size and bit-depth exactly, then that image is replaced. There are 7 images embedded in the launcher and the provided ico should provide images that match those in size and bit-depth.
The error message indicates that 7 of the icons found in the executable did not have matching sizes/bit-depths in the provided ico file.
The launcher that shipped in 3.7.2 contains the following sizes (order does not matter):
48x48 8 bit (256 colors)
32x32 8 bit
24x24 8 bit
16x16 8 bit
48x48 32 bit (RGB + Alpha)
32x32 32 bit
16x16 32 bit
The launcher that is shipping in 4.2 (3.8) contains the following sizes:
256x256, 32 bit (RGB / Alpha Channel)
48x48, 32 bit (RGB / Alpha Channel)
32x32, 32 bit (RGB / Alpha Channel)
16x16, 32 bit (RGB / Alpha Channel)
48x48, 8 bit (256 colors)
32x32, 8 bit (256 colors)
16x16, 8 bit (256 colors)
We had some frustrating moments where we got the error about missing icons, so I decided to dig into it.
Below are my findings… basically adding extra information to Andrew Niefer's answer.
For Windows, the process of replacing the images in the native launcher is described below. The processing is done by p2 class: org.eclipse.pde.internal.swt.tools.IconExe
This class looks at the resources of native launcher and notes the bitmaps that are in there: their sizes and their color depth.
Then it looks at the provided images. This can be a list of separate BPMs or an ICO file containing multiple BMPs. Their sizes and color depths are also noted.
This only works when all provided images are uncompressed. When one or more of the images is compressed, the process stops and no bitmaps are replaced in the native launcher.
Next it tries to match the provided BMP sizes and color depths to the ones in the native launcher and where they match, they are replaced in the native launcher.
When one or more bitmaps in the native launcher are not available in the provided images, the following message is written to System.err:
Error - <n> icon(s) not replaced in […]using […]
The class IconExe has a main method and can be run as stand-alone. Its first argument is the native launcher that needs to be modified and the following arguments are the provided BPM or ICO files.
For Eclipse 4.3(.x), the native launcher contains 7 bitmaps:
256x256, 32 bit (RGB / Alpha Channel)
48x48, 32 bit (RGB / Alpha Channel)
32x32, 32 bit (RGB / Alpha Channel)
16x16, 32 bit (RGB / Alpha Channel)
48x48, 8 bit (256 colors)
32x32, 8 bit (256 colors)
16x16, 8 bit (256 colors)
So, for the process of replacing the images to be successful, 7 images with the same size and depth need to be provided, either as separate BMPs or inside an ICO.
However, when using the tycho-p2-publisher-plugin, you cannot provide 7 separate BPMs, since the tycho-p2-publisher-plugin is not aware of the 256x256x32 image when it is specified in the .product file.
Its class org.eclipse.tycho.model.Launcher only reads the other 6 image locations from the .product file and hence, the 7th image (the 256x256x32 one) is skipped.
Therefore, the list that IconExe gets is one image short and will always report:
Error - 1 icon(s) not replaced in […]using […]
The solution that worked for us was to combine the 7 BMPs into one ICO file and provide that in the .product file.
But note that some image manipulation applications, that can create ICO files, tend to compress the 256x256x32 image by default. This is what got us on the wrong foot!
So be careful that all images in the ICO file are uncompressed.
I had a similar problems with 3.7.2 when my ICO file contained
higher resolution images such as 512x512
some images were compressed.
I deleted the unused layers from my ICO file using Gimp.
Just to add to previous answers:
All of the images in the .ico file should be BMP format, not PNG. I've seen at least two utilities that wanted to use the PNG format for one or more of the images.
If you are targeting Eclipse 4.2 then you will have to wait for Tycho 0.16.0 (or use the SNAPSHOT version already available) to get a version that includes the latest IconExe that copes with 256x256 bitmaps. If your .ico file contains one of these then it causes a read error in the old IconExe and none of your icons get replaced (and you get the error as seen in the opening message). See https://bugs.eclipse.org/bugs/show_bug.cgi?id=384509.