Logo by Fiery - Contribute your own Logo!

END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Visit us on facebook
 
*
Welcome, Guest. Please login or register. March 29, 2024, 01:18:29 PM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: [1]   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: Sandstone - Zoom into the edge of the large Cardioid  (Read 2452 times)
Description: Download link for high quality
0 Members and 1 Guest are viewing this topic.
stardust4ever
Fractal Bachius
*
Posts: 513



« on: September 01, 2014, 09:12:51 AM »

<a href="http://www.youtube.com/v/_WfjrLupX_Y&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/_WfjrLupX_Y&rel=1&fs=1&hd=1</a>

High quality download:
https://mega.nz/#!j4dHlQoA!bc_NQ0x4spyXOgnMZi5aoUC-zbhMB3GpZNUJS-AhgKs

Moderately deep zoom into the crust on the main cardioid. Due to the extreme density of the iteration data in this area, the color bands are set very sparse. With the zero index color being black, the Mandelbrot fractal is nearly invisible during the opening seconds.

The dense fractal data in this area has a grainy sandstone look, with the negative areas appearing as cracks in the rock.

Zoom depth: 1E57
Max iterations: 10,000,000

Rendered in Kalles Fraktaler
3840x2160 frames scaled to 1280x720 for anti-aliased video.

EDIT: The source file uploaded was 1.85 Gbytes 720p using H264: High Profile, Film Preset, Constant Quantizer = 23. The grainy details contributed to large overall file size. I had a feeling YouTube would puke on the video quality; apparently I was right. The HD YouTube stream (136Mb) is less than one twelfth the filesize of the source... vomit; feeling sick

EDIT2: Video link has been updated with new 720p60 version uploaded to Mega. Slower, Grain preset, Constant Rate Factor = 24, Reduced CPU Decode. The reduced CPU flag was necessary because the resulting output video stuttered even on my 4.2Ghz bulldozer in WMP Classic. Barely squeaked by at 1.95Gbytes.
« Last Edit: April 10, 2016, 05:09:16 AM by stardust4ever » Logged
Chillheimer
Global Moderator
Fractal Schemer
******
Posts: 972


Just another fractal being floating by..


chilli.chillheimer chillheimer
WWW
« Reply #1 on: September 01, 2014, 11:01:02 PM »

mh.. yeah, youtube really sucks for mset-zooms..   undecided
it's hard to recognize how beautiful this density of detail probably looks.

do you have any chance to upload a better version, perhaps at a filehoster?
I'd really love to see this movie in detail..
Logged

--- Fractals - add some Chaos to your life and put the world in order. ---
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #2 on: September 02, 2014, 01:57:18 AM »

mh.. yeah, youtube really sucks for mset-zooms..   undecided
it's hard to recognize how beautiful this density of detail probably looks.

do you have any chance to upload a better version, perhaps at a filehoster?
I'd really love to see this movie in detail..
The video is mind-blowing in the detail depatment. I registered an account on Mega.co.nz. It's currently uploading right now, about half finished of 1.85Gb. Upload should complete around midnight. You'll need a fairly robust processor to view the video but any dually or 4-banger made in the last 5 years should do.
Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #3 on: September 02, 2014, 10:46:35 AM »

 Repeating Zooming Self-Silimilar Thumb Up, by Craig
Logged

Want to create DEEP Mandelbrot fractals 100 times faster than the commercial programs, for FREE? One hour or one minute? Three months or one day? Try Kalles Fraktaler http://www.chillheimer.de/kallesfraktaler
http://www.facebook.com/kallesfraktaler
panzerboy
Fractal Lover
**
Posts: 242


« Reply #4 on: September 03, 2014, 02:43:40 AM »

Youtube recommends a bitrate of 8,000 kbps h.264 encoded.
It will re-encode at that setting (or lower) and use a fairly brutal one-pass encoding.
You can tell this by the way the video 'blurs' at increasingly regular intervals the deeper and more complicated the zoom gets.
A two pass encoding would spread the degradation more evenly across the video.
Doing a very slow encode can get a much better looking video than YouTube's at the same bit rate but alas YouTube blindly re-encodes.
I tried this with a 5,000 kbps video that YouTube then re-encoded at an appalling 3,000 kbps.
I suspect its programs assume folks upload with older h.263 codecs therefore it always tries to at least half the supplied bitrate using h.264.

In my experience twice or at most 4 times the YouTube bitrate gives a much better looking video without extreme filesize.
So that's what I've used when uploading better versions to my mediafire account.
I wont be downloading 1.85GB, my cap is 40GB a month, lots of folks here in NZ have just 10GB
But if the file were 400MB I'd be tempted.
Logged
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #5 on: September 03, 2014, 03:56:30 AM »

Youtube recommends a bitrate of 8,000 kbps h.264 encoded.
It will re-encode at that setting (or lower) and use a fairly brutal one-pass encoding.
You can tell this by the way the video 'blurs' at increasingly regular intervals the deeper and more complicated the zoom gets.
A two pass encoding would spread the degradation more evenly across the video.
Doing a very slow encode can get a much better looking video than YouTube's at the same bit rate but alas YouTube blindly re-encodes.
I tried this with a 5,000 kbps video that YouTube then re-encoded at an appalling 3,000 kbps.
I suspect its programs assume folks upload with older h.263 codecs therefore it always tries to at least half the supplied bitrate using h.264.

In my experience twice or at most 4 times the YouTube bitrate gives a much better looking video without extreme filesize.
So that's what I've used when uploading better versions to my mediafire account.
I wont be downloading 1.85GB, my cap is 40GB a month, lots of folks here in NZ have just 10GB
But if the file were 400MB I'd be tempted.
Constant bitrate is bad for fractal data. Some areas can be extremely sparse while others are incredibly dense. If you encode at a high enough bitrate to make the detailed areas look good, then extra bits will be wasted where they are not needed during areas of sparser detail. I always use High Profile, Constant Quantizer. For Fractals I typically use CQ=17 as larger values (lower quality) result in slight tearing in areas of low gradient. DVDs, I use 18 for CGI, 20 for live action. For Sandstone, I used CQ=23 and the result for a 3 minute HD video was 1.85Gb. For comparison, my Avatar DVD was just over 2Gb mp4 854x480p 23.96Hz, with 320kbit AAC audio, with CQ=20. Just FYI, I don't pirate movies; those rips were of my own DVDs for my own private enjoyment.

My Sandstone zoom is an extreme example of dense areas within the set. Nearly every pixel of every frame has a different value to it's neighbors, and the image will be grainy even with intense antialiasing. No video codec in the world will compress the image data efficiently without artifacting. The fact a far shorter video segment encoded at such a massive bitrate goes to show how dense the iteration data is. Even BD players would probably choke on it. Not sure what the maximum bandwidth is on BluRay.
Logged
Dinkydau
Fractal Senior
******
Posts: 1616



WWW
« Reply #6 on: September 08, 2014, 08:56:46 PM »

Nice and thanks for the original file.
Logged

stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #7 on: September 09, 2014, 06:48:45 AM »

Nice and thanks for the original file.
Welcome. What's really fudged up is the youtube preview screenshot shows crystal clear fractal detail while the processed video is pukey.
Logged
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #8 on: October 02, 2014, 10:50:49 AM »

Constant bitrate is bad for fractal data. Some areas can be extremely sparse while others are incredibly dense. If you encode at a high enough bitrate to make the detailed areas look good, then extra bits will be wasted where they are not needed during areas of sparser detail. I always use High Profile, Constant Quantizer. For Fractals I typically use CQ=17 as larger values (lower quality) result in slight tearing in areas of low gradient. DVDs, I use 18 for CGI, 20 for live action. For Sandstone, I used CQ=23 and the result for a 3 minute HD video was 1.85Gb. For comparison, my Avatar DVD was just over 2Gb mp4 854x480p 23.96Hz, with 320kbit AAC audio, with CQ=20. Just FYI, I don't pirate movies; those rips were of my own DVDs for my own private enjoyment.
I just did a burning ship zoom video to 7E777 (22 minites, low density needle zone) and the high detail in the circles towards the last 10% of the video added nearly a gigabyte to the AVI file, going way over the limit to 2.8Gbyte (it was trending towards close to 2Gb before the circle regions).

So Panzerboy was partially right about bitrates. All future zoom movies will use CRF (constant rate factor) encode settings which yield a lower quantizer for sparce areas and a higher quantizer for detailed areas, possibly the best possible outcome for rendering in a single pass.
« Last Edit: October 02, 2014, 10:57:07 AM by stardust4ever » Logged
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #9 on: October 03, 2014, 09:04:00 AM »

just wondering how you guys are encoding your videos to h264? are you doing it manually or using a frontend?  a few FYIs:  h264 does not belong in avi, some examples of proper containers for h264 would be mkv and mp4.  also one-pass encoding with x264 is generally done nowadays with CRF, not CQ.  from the documentation:

The final ratecontrol method: Constant Ratefactor. While qp targets a certain quantizer, and bitrate targets a certain filesize, crf targets a certain 'quality'. The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space. The arbitrary unit of measure for crf values is the "ratefactor".

also the progressive blurring someone commented on isnt actually youtube doing that, thats kalles fraktaler doing that intentionally.  youtube itself doesnt render subregions of your video at progressively more terrible quality, it is happy to just go ahead and turn every single pixel of every frame into a smeary poopy featureless mess.  karl's idea was that you will only be uploading videos to youtube so in the end you wont notice anyway or maybe hopefully gives some sort of softening effect at the center of the image   kiss ...  he is a bit misguided in his thought process on that one.
« Last Edit: October 03, 2014, 09:06:51 AM by quaz0r » Logged
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #10 on: October 03, 2014, 10:29:57 AM »

just wondering how you guys are encoding your videos to h264? are you doing it manually or using a frontend?  a few FYIs:  h264 does not belong in avi, some examples of proper containers for h264 would be mkv and mp4.  also one-pass encoding with x264 is generally done nowadays with CRF, not CQ.  from the documentation:

The final ratecontrol method: Constant Ratefactor. While qp targets a certain quantizer, and bitrate targets a certain filesize, crf targets a certain 'quality'. The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space. The arbitrary unit of measure for crf values is the "ratefactor".

also the progressive blurring someone commented on isnt actually youtube doing that, thats kalles fraktaler doing that intentionally.  youtube itself doesnt render subregions of your video at progressively more terrible quality, it is happy to just go ahead and turn every single pixel of every frame into a smeary poopy featureless mess.  karl's idea was that you will only be uploading videos to youtube so in the end you wont notice anyway or maybe hopefully gives some sort of softening effect at the center of the image   kiss ...  he is a bit misguided in his thought process on that one.
The whole point is that H264 codec was designed for "normal" video data, including things like all manners of cinematography, real life video and animation, both CGI and cell drawn.

Fractal data by design is notoriously difficult to encode using existing codecs. the level of detail in a fractal is infinite, limited only by pixel resolution. The self-replicating shapes create extremely unnatrual patterns. Videos from normal sources typically consist of forground and background areas that often move at different rates of speed. H264 was specifically designed to track block areas of movement as they pan across a video frame as with any cinematography sequence as well as hand or computer generated animations, rather than relying on outdated codecs which only looked at the differences between static pixels on adjacent frames, often leading to tearing and pixelation of anything that moved considerably between frames. That Cinepak codec used to compress 320x240 (and smaller) videos across dial up for view on PCs with Pentium I processors. Your CPU was considered state of the art if it included MMX instructions.

But I digress. Fractal data has tons of repeating detailed areas of infinitely repeating patterns. Depending on the type of fractal or region within, the density of this fractal data can range from extremely sparse (Mandelbrot "utter west" needle for instance) to so dense it becomes space filling (the crust of the main cartoid like I zoomed in this video). Color palettes vary wildly based on artist preference, but generally tend to be smooth gradients to wild changes of brightly colorful bands in which the brightness, hue, and saturation values vary as wildly as their respective RGB values.

In real life cinematography as well as all types of animation, objects are typically made out of material which is solid in hue and saturation but light hits the textured object creating subtle variations in brightness. Our eyes likewise have more rods than cones so our eyes/brains perceive finer details in brightness fluctuations than in color. As a result, both real world / human perception often contain / percieve less data in hue/saturation compared to brightness, so using BHS instead of RBG just makes sense as a way to encode data. Jpeg format uses this and most photos have little loss of detail using decent compression ~90%. Video formats use this too and are further compressed into 4:2:0 color space to further reduce the data prior to compression.

Obviously, fractal data has very unnatural / unrealistic color space. The combination of smooth gradients with fine grainy detail makes compression tricky for static images. Often PNG creates a smaller file than Jpeg 100%, and the lossy artifacts due to Jpeg compression are noticable even at max settings due to the reduction of color space. Well, try to render a video out of this fractal soup and you've just opened pandora's box. H.264 has a number of things going for it, primarily an excellent motion prediction algorithm. Zoom movies consist almost entirely of endless zooming in, with features getting larger as they accelerate toward the edge of the screen. So the motion prediction effect of H.264 is by far the biggest space saver compared to obsolete codecs. Still, the higher the complexity of the image, the greater the data rate must be to prevent noticeable loss in quality.

Youtube is a streaming service, so any video, HD or not, has a bandwidth cap on it. VBR is the ideal format for fractal vids, contributing more bits to finer details and less bits to sparse details. But the disparity of image complexity in fractal zoom videos compared to "normal" videos can range in the orders of magnitude beyond anything that one would normally encounter in traditional media like film and animation. As a result, sometimes it takes a gig or more for a 1280x720p video a couple minutes in length (sandstone), other times a sparser video tens of minutes in length only needs a fraction of that bandwidth. Ad to that the complexity increases exponentially as you approach the minibrot at the end of the video, and you've got a nice video file with decent file size for it's length, with the bulk of the file size located towards the end or in a few other exceptionally complex areas. In other words, bitrate can change by orders of magnitude. Still, it's a nicely playable local file assuming your CPU can keep up to play it at 100% speed. Not good for streaming services where bandwidth is limited and compression efficiency is sacrificed to ensure the video is watchable on less powerful devices such as mobile, etc...

As for the rediculously dense and complex sandstone zoom, the allocated bandwidth is nowhere near being good enough hence the best option is to link the original download file for local playback.

Not sure where I'm going with this wall of text, but I don't think H.264 or any other current video codec is really ideal, but H264 CRF by far produces the best results. Fractal data is so bizarre by nature and I noticed H264 has custom tunings for common content types. Maybe efficiency could be improved by hand tweaking a set of custom parameters for fractal zoom videos? I generally select "none" but maybe the gurus can come up with some hting better, especially if deep zoom rendering becomes more mainstreamed.

And quit harping on the AVI format. AVI sucks. The 2Gb limit pisses me off, especially when dealing with HD resolutions. But 2Gb was bigger than most desktop harddrives when the AVI standard was established. Yes, Mp4 or (insert other container format here) would be infinitely better, but I am at the mercy of the software developers to code something that outputs a better file format. Sure people will advise to render lossless or near lossless compression (Huffy YUV 4.2.0 or other wierd crap) in smaller segments, then splice the videos back together with a program like VirtualDub or AVI Demux and separately encode, but dat's a b!tch to do and I'm lazy. As long as I have prerendered frames, I can reencode the video as many times as I want until I get an acceptable file under 2Gb.

Sorry for the wall of text. I overstate myself sometimes. Derp. sticking out tongue
Logged
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #11 on: October 03, 2014, 12:20:40 PM »

i like your passion for the art  grin  yeah i know its too easy to rip on youtube.  it was designed to stream skateboarding dogs to peoples phones and web browsers, not losslessly archive the most detailed of video art like fractal animations.  still as someone who is passionate about quality it is hard not to be down on it when it is what ends up getting used for such purposes anyway.  thats why i like to see people posting their original encodes to filehosting services instead as you have done  A Beer Cup

i think that you underestimate x264.  it is not just intended to be used on real life video.  computer generated stuff like fractal animations are perfect candidates for the sort of compression techniques employed here, just as how you describe png being well suited for it.  compared to real life video and obstacles to compression like film grain, things like computer generated fractal art are easy to encode.  though you are right different sets of parameters lend themselves to different sorts of source material.  there are a few x264 presets that are a good starting point, for example the --tune animation preset.  and theres a whole community of people out there that encode videos of video games that of course use x264 as again it is perfectly suited to such things.  you can look on their forums and whatnot to see what encoding parameters they are using nowadays, though it usually boils down to using as many reference and b frames as possible, lowering psyrd, using a higher rather than lower deblock setting, and lowering the aq strength.
Logged
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #12 on: April 10, 2016, 05:47:58 AM »

High. I just wanted to let everyone know that the MEGA download links are back up for all my Youtube videos that contained HQ download links. I have re-encoded the AVI file to 720p60, Slower, Grain, Constant Rate Factor =24, reduced CPU decode, and the resulting file for slightly over 3 minutes of video was 1.95Gb! dance moves

Why use reduced CPU decode? I tried re-rendering the video without it but the bitrate for this file was so extreme that I got stutters in WMP Classic with a 4.2GHz bulldozer. If my render machine choked on it, I'm pretty sure others would too. So you still probably need a fast HDD and decent processor to watch.

I'm not done with this thing yet. I would like sometime to rerender it with 7680x4320 frames for Super AA 1920x1080p60, or possibly even do 4k samples. It would make an excellent test render for encoding, seeing how youtube choked on it. Kalles Fraktaler suggested I use a zoom ratio less than 2 so that the rectangular borders are not so apparent.

I still don't understand the appeal of 4k video yet. I seriously doubt most CPUs could handle it, although UHD BluRay and TVs are a thing now. I imagine they must rely on some special ASIC to handle decoding the bit-stream. tease
Logged
Pages: [1]   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Weathered Sandstone Mandelbulb Renderings David Makin 3 1593 Last post December 26, 2009, 04:29:39 AM
by David Makin
Edge of the Pit Mandelbulber Gallery MarkJayBee 0 860 Last post May 31, 2010, 01:02:45 PM
by MarkJayBee
Sandstone minibrot Images Showcase (Rate My Fractal) Eric Bazan 0 554 Last post March 04, 2012, 07:08:38 PM
by Eric Bazan
Sea Ferns, Cardioid Tip Images Showcase (Rate My Fractal) Eric B 0 1282 Last post October 24, 2012, 01:46:53 AM
by Eric B
Optimizations for bulbs other than main cardioid and period-1 bulb? Mandelbrot & Julia Set Levi 2 2698 Last post May 24, 2013, 06:37:57 PM
by Levi

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.696 seconds with 27 queries. (Pretty URLs adds 0.071s, 2q)