Zoltan Erdokovy
![]() |
I'm trying to make a filter which (un)packs multiple 8 bit per
channel images into one HDR image. The encoding part kinda works, but I have difficulties with the decoding. The base idea is that we can store one image in the 0..1 domain, another one in the 0..256, a third in 0..32768 and so on. Please find the work in progress filter attached. It successfully decodes the first and third image but the second is screwed for some reason. I'd appreciate any help or suggestion. HDR_codec.ffxml |
|||
Posted: November 21, 2010 8:14 am | ||||
Sphinx.
![]() |
Hmm, I'm not sure if its possible to combine more than two sources in floating point format (i.e. in integer and fractional parts) - I tried, but the "middle" part always get scrambled. I could be wrong though...
But even just with two sources, you'd need an external encoder if you want to import multiple images. The "one image only" limitation is IMO the most annoying aspect of FF ![]() Hopefully when we get bitmap scripts we can write our own loaders ![]() |
|||
Posted: November 22, 2010 4:28 am | ||||
Zoltan Erdokovy
![]() |
I'm pretty sure that more than one image can be encoded.
FForge definitely has the required bit depth (32/64 bits per channel?). Here is my line of thinking, maybe one can point out a fundamental flaw in there. So, store the first image as decimals. Lose the integers to get the stuff. Second image: you divide the value of a pixel by 256, use fraction part. Yes, the first image is still present in the number but in so small fraction that it will be lost when the image is saved in a format which can only store 256 steps of brightness per channel. To get the third image you divide by 256x256, so the second and first images become insignificant, and so on. As for multiple input images, I thought copy-pasting 4 images to the 4 quadrants of the input image is a simple enough method. The filter then replaces one/all of them with the result. |
|||
Posted: November 22, 2010 4:45 am | ||||
Sphinx.
![]() |
Yes, as I said, combining two images is no problem, but strange things happen when you repeat the process. I think it is because of the way floating point numbers are constructed (the values are not precise as with integers, they are approximations). |
|||
Posted: November 22, 2010 7:31 am | ||||
Sphinx.
![]() |
LOL, let me correct that: strange things happen when the math is not correct ![]() It is possible. See attachment. 3 Source Composite.ffxml |
|||
Posted: November 22, 2010 12:26 pm | ||||
Zoltan Erdokovy
![]() |
Sweet mother...
/facepalm ...it's soo simple... /hides under the table in shame. |
|||
Posted: November 22, 2010 1:27 pm | ||||
Kraellin
![]() |
i believe someone already did something like this. they compiled a single image from four into the four quarters of the new image and then imported that into FF. from there they 'unpacked' it and did some stuff to it and composed it into one image as the final result. is that what you're after?
If wishes were horses... there'd be a whole lot of horse crap to clean up!
Craig |
|||
Posted: November 23, 2010 10:02 pm | ||||
Zoltan Erdokovy
![]() |
The original intention behind this was to batch together multiple
images for 3d work: diffuse, normal and specular maps. Then use that composite image the usual way: paint it on 3d models, transform them in PS, use the clone brush and so on. The final step would be the extraction of the separate surface properties. However I ran into a problem: Photoshop's "exposure" adjustment layer has limited range so it has difficulties handling a dynamic range this big. The result is an almost full white image which is not very user friendly to work with. I have a few ideas to try (storing extra data in the negative domain, storing channels in RRRGGGBBB order instead of RGBRGBRGB, etc) but haven't had the time to play with them yet. I really wish we could lose the shackles of the 4 channels per pixel limitation and have an arbitrary number of pixel properties... |
|||
Posted: November 24, 2010 3:31 am | ||||
Betis
![]() |
that would be awesome
![]() Roses are #FF0000
Violets are #0000FF All my base are belong to you. |
|||
Posted: November 24, 2010 3:44 am | ||||
Sphinx.
![]() |
The "negative domain" is really just indicated by one BIT in the floating point representation: either its negative or positive, it can't be both, so there is not like a whole extra set of bits that represents negative values.
However there might be a precision/range advantage in offsetting the final multi source composite so that it uses that BIT to double the precision. You can try it out by subtracting half of the max possible value (BITS^3 / 2 I think). Before you decompose the sources again in FF, you add that value. |
|||
Posted: November 24, 2010 4:01 am | ||||
Zoltan Erdokovy
![]() |
Yeah, the negative values idea does seem silly now, it probably
won't play well with PS anyway. However, storing the excess data in fractions (0..1, 0..1/256, 0..1/32768) might be worth a try...hmm... |
|||
Posted: November 24, 2010 4:54 am | ||||
IONclad |
HA! I just spent about 6 hours building a filter that does exactly this
It was rejected as 'too slow to render'... which I found really fishy since it took 20 minutes to render on my little Dell laptop sporting a blazing core duo mobility chip. If you want it, I can email it to you. Ian the artist formerly known as Bongo51 |
|||
Posted: November 29, 2010 1:26 pm | ||||
Zoltan Erdokovy
![]() |
Thanks IONclad, but I think it would be even better
if you could post the filter in this thread so other people (with more time and experience than me) could take a look and might give you some pointers. |
|||
Posted: November 30, 2010 1:59 am | ||||
IONclad |
yeah, that's true. Though keep in mind this filter just helps you with the mechanics of combining 4 images into one, plus, it had been released that this functionality will be available in V3.
The main down side to multiple images via workaround is that coming in each of the four sources is 1/4 the working resolution enlarged to full size. eg. 4 bitmaps put into a 2000x2000 pixel original to feed this filter would output a 2000x2000 pixel image containing 4, 1000x1000 bitmaps all now 4x the resolution. As long as you don't mind shrinking the FF to be 1000x1000 again. An imperfect solution for sure. So, I advise doubling the resolution of your source. This helps with the end sharpness... at least in my experience. Quick3DVisualizor.ffxml the artist formerly known as Bongo51 |
|||
Posted: November 30, 2010 12:10 pm | ||||
IONclad |
Also, keep in mind that this filter the way it sits was rejected for slow rendering. Though, likely it's the noise component, so....
the artist formerly known as Bongo51 |
|||
Posted: November 30, 2010 12:11 pm | ||||
Zoltan Erdokovy
![]() |
Cheers, I'll take a look when I can.
I'll also catch up on info regarding FF v3. ![]() |
|||
Posted: November 30, 2010 12:24 pm |
Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!
33,711 Registered Users
+18 new in 30 days!
153,533 Posts
+38 new in 30 days!
15,348 Topics
+73 new in year!
43 unregistered users.