Just want to make sure, if all the experts agree that jitter exportImage sucks.
It is a bit mysterious that there are a few threads where people ask about exporting images and pixelation and those threads have no replies.
It would be great to settle it all here so that others don't have to spend hours trying to find a way of exporting high def images to find out that they can't without external hardware.
As you can tell I am a bit sad since I thought jitter could do better image exports than the ones I am getting
Iam going from jit.gl.asyncread foo @layer 1000 to jit.matrix 4 char 11800 8850 @interp 1 and even though it takes me a couple of minutes to save it, the quality still sucks.
the fsaa 1 option does not work.
I haven't been able to find any other workflow,
if you do know of one, please enlighten me
Is there anything I can DO?
[attachment=152965,1760]
Attachments:
Hi
That a pretty small graphic you posted – yet you have a huge jit.marix? How big is the source ‘foo’?
High Def images need high def import – 640 480 will not scale up to 11800 8850 very well at all . . .
Really not sure what you are trying to achieve? Readback to a matrix or export an image . . .
Really need a lot more info here – maybe extract of patch
hi Macciza
yeah its a small graphic because its just a very small portion of the actual image 11800 8850. In other words, THis is a portion of the Actual Pixel of the 11800 8850 image.
even if I where to zoom out 50% that pixelated portion would still be visible. You can try this by downloading the image and zooming out.
I am not importing anything. it is all OpenGL graphics.
that is why I am capturing to matrix
here is an example of the patch,( might make some computers very slow)
to tell you the truth I don’t think it is even possible to get good quality since, we can only export 72 dpi from jitter.
jit.gl.asyncread’s output matrix is as a large as the render destination’s size, i.e. a jit.window. So it would make sense that connecting to a larger jit.matrix with @interp 1 would not give you the results you want. You need to make the jit.window larger, or use an image editing program like Photoshop or other special purpose plugins to do enlargements after export.
I do agree, however, that it would be nice to be able to set the dpi of the exportimage from jit.matrix to values higher than 72.
thanks for both replies Jesse. So if I get an external 30" monitor and capture from that, it would give me the best jitter results without getting a 500 capturing hardware. Up till now this seems the best solution
Hi
I think you need to do some research on dpi vs ppi. they are very different things
Your 11800 x 8850 image is over 100megapixels = roughly 40 x 30 inches @300ppi 160/120 at 72ppi
Screen metrics are a funny thing and 72dpi gets thrown around willynilly without regard to screen size or resolution. ! 512 pixel image is half of a 1024 pixel screen whether on a 17 or 27 inch monitor.
Your image is actually ignorant of dpi resolution – you can manipulate that in many ways post facto.
Your patch did not include foo, which defines the size of image that asyncread reads from as Jesse noted
It would want to be close to eventual size to avoid the artifacts you are seeing
What are you trying to achieve through all this? Output to a massive video wall? Large poster prints?
Edit: I don’t think the exportimage function sucks; it is simply misunderstood . . .
Yes, Macciza is right — render destinations (i.e. jit.window) can be any size, irrespective of the monitor size or its native pixel resolution. It’s easy to understand why you’d confuse these because typically you’d make a jit.window the same size as your monitor, or go fullscreen.
Jitter is ultimately very flexible in these cases – you can render therefore at arbitrary resolutions, but if you go as high as 11800 x 8850 your real-time frame rate will suffer. You may need to explore non-realtime rendering for this purpose.
Macciza thanks for the help. Iam sure the exportimage function is not that bad, nevertheless I am still getting better results capturing from my 1920 by 1080 screen with the fsaa on and zooming in , than turning fsa off and exporting an image using jit.matrix 4 char 7680 by 4320 with the foo also at 7680 by 4320, and seeing it actual pixels
It is for large prints, maybe I am still not getting what you are saying, am example patch would help.
cool Jesse, thanks for the help. Ill keep on exploring. I am already getting better results than I got when I started,
Hi
First – do a google search of ‘dpi vs ppi’ and read a bunch of the results . . .
Second – forget 72 dpi, it’s a misunderstood myth relating back to early Macs and typesetting standards
Third – research pixels, pixel aspect ratios, square vs rectangular etc
Confused still, probably, . . .????
As stated above Your 11800 x 8850 image is over 100megapixels = roughly 40 x 30 inches @300ppi – 60in@200dpi, 118in a@100dpi etc . . .
What size poster do you want to print?
What software are you using for viewing/ post-processing your image?
If you are rendering at 1920×1080 and you are reading back to a cpu side matrix/ "image" that is 7680×4320 you are *going* to get resizing artifacts. You are not rendering at your destination size, rather you are rendering at 1920×1080 and *resampling* up to some other size. Its like doing a resize in photoshop with linear or bi-linear filtering (thats probably what Jitter would do via @interp 1), and if you are not doing @interp 1, you are doing nearest neighbor which will give you jaggies up the wazoo.
You realistically have 2 options:
Continue using hardware OpenGL (ie, your graphics card) and render tiles (google will help you on how to set up tiled rendering for OpenGL), and then you export each tile and put them together post-process in say, Photoshop or image magic, etc. Basically you just render a portion of you scene, output an image, render another portion, output an image, etc.
Or use software OpenGL by rendering to a matrix, which is slower, but can support insanely large destination contexts, and do it all in one go.
Also, as others have said, DPI has nothing at all to do with it. A specific video frame/resolution has a constant number of pixels irrespective of the size of the output device (ie, screen). A 1920×1080 frame of video is the same frame, the same pixels, the same exact image on a 5" HD TV and a 60" HDTV. Its just that the TV is bigger, and thus the pixels….
Macizza- I want to print the biggest I can without jagged lines, but I guess I could settle with more or less 22" by 10", Iam usign – photoshop, photozoom(for upscaling)
Vade- thanks for the reply it was very helpful, and let me also thank you for all the open software you have developed (like syphon amongst others)
tile rendering seems very interesting indeed, since image capturing(command shift 4 ) a portion of 3071 x 1728 a at 1920 X 1080(size of my screen) seems higher resolution than exporting a whole image 3071 X 1728 and looking at 1920 x 1080 of the exported image.
the other solution would be like you said to export at higher rates but as soon as I try 7680 by 4320 if I am lucky and get something in the jit.window I get some weird very big bars across the screen (probably indicating that the nividia geoforce duo cannot support that export size) the bars are like a glitch thing.
but then again I might be doing something wrong.
I just noticed that the limit for osx Hard ware is 4096×4096, that would explain the glitches I am getting.
So to keep the fsaa on, I would have to tile it using jit.gl.sketch and viewport, frustum, modelview etc the problem is I am not gifted at opengl and don’t know exactly how to do this and it might be a steep learning curve.
The other solution like i stated above would be to use command shift 4 in my 1920 x 1080 screen and rotating the gridshape/meshes in the x and y axis by 180 and then doing another 1920 X 1080 screen capture, this seems a little tedious and might be a hassle to put together after, but seems like the only "quick" solution…. or doing this same thing an using exportimage with the fsaa on.
well thanks anyways, ill keep on working on the this technical stuff even though I rather work on some images!! :).
hi tsiwt. i think you are making this more complicated than it needs to be, unless i’m misunderstanding what you are trying to do.
rendering a frame of opengl to a large matrix, and then exporting that matrix as a large image is pretty straightforward.
see if this patch helps. please be aware, 10,000 x 10,000 takes a while to render and than export. obviously the actual dims of the matrix can be anything (limited only by the amount of memory in your computer).
Exactly, Rendering to a named matrix forces software OpenGL. OpenGL hardware limitations are completely dependent on your *Hardware*, and change based on what GPU you have installed, and possibly driver/OS revision. Mac OS X is not limited to 4096×4096, your computer might be however.
To check limitations and support, see the Mac OS X OpenGL compatibility matrix here:
http://developer.apple.com/graphicsimaging/opengl/capabilities/
Looks like 16384x 16384 is the software GL drivers limitation.
thanks guys, yes Rob your patch works, the problem is that once I include it in mine I get the jit.gl.texture : error attaching texture readback mechanism for capture, it seems to be a problem with the slab, it is name correctly.
ill keep on trying to debug it.
thanks again