I have set up the color scheme to identify the different system of the building services in Revit and Navisworks. When I uploaded to the forge viewer, the colors were shown correctly at the beginning. However, when I zoomed in, some of the colors were disappeared. Did anyone have this problem? How could the problem be solved?
Thank you.
Forge Display Error:
Zooming Lo01
Apologizing for any inconvenience caused, this might be a known issue of our model extraction service for the Revit, it has been logged as REVIT-120524 in our case system to let our dev team to allocate time to investigate it. You can send this id to forge.help#autodesk.com to inquire updates in the future.
BTW, the reason caused this issue I discovered is there are many MEP system type, and they have owned different colored material, fittings will take materail color from the first system type from corrosponding MEP systems. Currently, there is not formal solution to avoid this. We apology for this again. Fortunately, there is a workaroud you could try:
Split your MEP models into servral RVT files that contain single pipe system, duct system and others.
Upload them to the Forge for translation seperately.
Load translated models via the Forge Viewer.
Hope it helps.
This workaround is working on my live projects now, but might not suite for you. And it's not the formal solution, you might have to use it at your own risk.
Related
Do you know if there are unchangeable EXIF datas ?
In my case i want to know the real date of creation of a jpeg image. So I thought the EXIF's datas was the best way but I realized that with a software like XnView you can change it. So there is any way i can now the real date of the creation of an image ?
In another hand, is it possible to know if a EXIF datas has been modified ?
Thx fo all,
And sorry for my bad english
Have a good day !
:)
In principle, it is not possible to be sure the data hasn't been edited, although it may take a great deal of skill to do so indetectably. Some of the major camera makers (Canon and Nikon, possibly others) offer an "image authentication" feature in their pro model cameras which is designed to make it impossible to modify the image after it has been taken. They do this for the benefit of people doing legal work - evidence shots and the like. To use this, you have to switch it on (via the camera settings) before you take the picture. Even with these though, it is still possible to alter the data: both the Canon and Nikon authentication systems have been cracked (presumably with considerable difficulty).
As for normal pictures, yes, these are very easy to alter. However many (most?) programs which can edit EXIF data leave their own signs. For example, Adobe Photoshop always adds its own name somewhere in the EXIF, apparently whether you want it to or not. You can see this with many different EXIF viewers, especially with the more advanced ones like PhotoME. (Which, sadly, is no longer maintained.)
Short answer: yes, it is always possible to exit EXIF, and almost always possible to do it indetectably, but it may requite the right tools and quite a lot of skill. You can't ever be certain it has not been done.
Can someone explain in simple terms what an egl image is, and an example of when I would want to use one? I know it can significantly increase performance, but I'm having trouble finding documentation. Before I try and really figure it out, I want to make sure its even worth learning.
Thanks.
So a year later, I have become more of an expert in Android graphics and actually wrote a white paper about EGL Images. If my company lets me publish the paper externally, I'll post it here. For the time being, here is a short answer.
An EGL Image is simply a texture whose content can be updated without having to re-upload to VRAM (meaning no call to glTexImage2D). One of the only drawbacks, besides increased code complexity, is that the application developer has to handle synchronization themselves. In apps that I've written, I had to implement my own "internal" swapchain of EGL Images and manage all the locking primitives myself. Thus, a call to eglSwapBuffers swaps front and back framebuffers as usual, but in a seperate thread there are 2 EGL Images swapping front-to-back as new content becomes available.
The Khronos documentation is at:
http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_image.txt
http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_image_base.txt
On the other hand, given how opaque most Khronos documentation is, this may not help much. I haven't been able to figure them out myself.
This is one of my assignments and I need some help in getting started. The basic idea behind the assignment is that I have to design a self destructible email program that is capable of destructing the message after (n) time duration.
Speaking about self destructible emails, there are quite a few ones on the internet offering the same service. But what they do is, they just convert the email message into an image and store them on their servers. Now, they send the message attaching the image inline with it. After they receive a hit on that image (which means that the message was being opened), they simply delete the image and the inline image link breaks! BOOM!
IMO, that's not what a self destructing email should be like. Nevertheless, in my case, I have to take care of following points:
I have to do it for TEXT. No image, nothing else.
I have to assume that the systems used throughout the process will be UNIX based (I don't know how that is going to make a difference).
There are also some hints regarding the usage of various network layers in solving the problem.
This isn't supposed to be done "in general". What I mean by that is, I have to do that ONLY for one/two UNIX systems. Let me put it this way, all I have is two UNIX systems and nothing else. Now I want to create a program (in UNIX itself) that would do that self-destructing thing. I have total control of protocols and the network layers and I have to code anything and everything required at any level.
This is more geared towards the StackOverflow side of things but I have no problem getting you started.
The first thing I'd like to point out is that you seem to be heavily over-analyzing this. The services that have self-destructing e-mails which are image based are simply deleting a file after it is viewed. All you need to do differently is put that text in a file and get it's contents before deleting it. This fits well with the UNIX philosophy since so many programs already make use of flat files.
The part you seem to have left out is how you are building this. You describe it as an e-mail program and then talk about web services. Is this a web-based project or a program you are designing for Linux? Do you have to code everything from scratch or can you parse output from Linux utilities to grab the mail? These kinds of things really would simplify the process.
This is really unknown issue to many people. I would raise a question for it and make it easily accessible for other, and maybe someone of you know the solution for this problem.
All of us probably know that there is problem with alpha transparency in PNG24 in IE6 (still used by many people on web..). There are at least few known solutions how to solve that, but all of them got their problem that I would like to describe there:
1.Using progid:DXImageTransform.Microsoft.AlphaImageLoader:
This is most common trick to make images shown in IE6. Problem is that it uses DirectX to show it. So basically DX firstly need to download file from Net, then render it. This downloading block browser context for a while. But if you have alot of images - that means that you page can be freezed for even... few minutes (it happens to mine one project at least once).
http://blogs.cozi.com/tech/2008/03/transparent-pngs-can-deadlock-ie6.html
http://www.stum.de/2008/12/01/do-not-use-alphaimageloader-to-fix-transparent-pngs-in-ie6/
2.Using VML.
You can also use this workaround. However this has a nasty effect of rendering gray box in background, then a proper image, also causing to download image files twice - this however might be because of bad implementation so need to be checked.
3.Using PNG8.
Just forget about solutions and try use PNG8, if prepared correctly can still be looking good.
If anyone knows any other solution please give answer here!
You should definitely have a look at http://www.dillerdesign.com/experiment/DD_belatedPNG/
My custom homebrew photography processing software, running on 64 bit Linux/GNU, writes out PNG and TIFF files. These are to be sent to a quality printing shop to be made into fine art. Working with interior designers - it's important to get the colors just right!
The print shops usually have no trouble with TIFF and PNGs made from commercial software such as Photoshop. Even though i have the TIFF 6.0 specs, PNG specs, and other info in hand, it is not clear how to include color calibration data or implement color management system on linux. My files are often rejected as faulty, without sufficient error reports to make fixes.
This has been a nasty problem for a while for many. Even my contacts at the Hollywood postproduction studios are struggling with this issue. One studio even wanted to hire me to take care of their color calibration, thinking i was the expert - but no, i am just as blind and lost as everyone!
Does anyone know of good code examples, detailed technical information, or have any other enlightenment? Or time to switch to pure Apple?
Take a look at LittleCMS
http://www.littlecms.com/
This page has the code for applying it to TIFF
http://www.littlecms.com/newutils.htm
The basic thing you need to know is that Color profile data is something you need to store in the meta-data of the file itself.
There is a consultant called Charles Poynton who specialises in this area. I work for one of the post production studios you mention (albeit in london not hollywood), and have seen him speak on the subject a couple of times. His website contains a lot of the material he presents and you might find something of use there. He also has a book called Digital Video and HDTV Algorithms and Interfaces which is not as heavy as the title might suggest! While these resources might not answer your question directly, it might provide a spring board to other solutions.
More specifically, which libraries are you using to write the png and tif files - you mention they are homebrew, but how custom are they exactly? Postprocessing the images in an image manipulation program (such as ImageMagick or dcraw) might allow you to inject this information into the header more successfully.
Sorry, I don't have any specific answers, but maybe something that will point you a bit further in the right direction...
As a GNU/Linux user, you’ll want to consider DispcalGUI – http://dispcalgui.hoech.net/ – a GNOME-based GUI that centralizes color management, ICC profile management, and (crucially for your case) device calibration. It can talk to well-known pro- and mid-level hardware, e.g, i1, X-Rite, Spyder, etc.
But before you get into that – you say you are generating your files to spec; are you validating your output using a test suite specific to the format in question? If not, here are three to get you started:
imagetestsuite supports the well-known formats: https://code.google.com/p/imagetestsuite/w/list?can=1&q=
The Luminous* test suite is a JIRA plugin, if that’s your thing: https://marketplace.atlassian.com/plugins/com.luminouslead.plugin.jira.testsuite.LuminousTestSuite
FLOSS Decoder implementations often have one you can use, i.e. OpenJPEG – https://code.google.com/p/openjpeg/wiki/TestSuiteDocumentation
But even barring all of those, it seems like your problem is with embedded ICC data – which is two specs in one. First, there’s the host image-file format, and they all handle embedding differently (meaning the ICC data will likely look totally different when embedded in a TIFF than, say, a JPEG or WebP file). Second, there is the ICC spec itself. It is documented here: http://color.org/v4spec.xalter – and you may also want to look at the source for the aforementioned dispcalGUI, which includes a very legible and hackable ICC profile class in Python: http://sourceforge.net/p/dispcalgui/code/HEAD/tree/trunk/dispcalGUI/ICCProfile.py
Full disclosure: I have contributed to that very ICC profile class, to which I just linked in that last ¶
That’s the basics (many of which you have no doubt covered)... beyond that, if you post more information about what exactly is going wrong, I’d be interested to look it over. Good luck with it either way.
* NB. This project is unrelated to the long-standing photography website, “the Luminous Landscape”