Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Bumber]

Code: [Select]

for Ryblue in range (256):
    for Rxblue in range (256):
        bitmap[Rxblue][Ryblue][0] = floor((Rxblue/256)*Rblue)
           
for Gyblue in range(256):
    for Gxblue in range(256):
        bitmap[Gxblue][Gyblue][1] = floor((Gxblue/256)*Gblue)
       
for Byblue in range(256):
    for Bxblue in range(256):
        bitmap[Bxblue][Byblue][2] = floor((Bxblue/256)*Bblue)can be reduced to:

Code: [Select]

for yblue in range (256):
    for xblue in range (256):
        bitmap[xblue][yblue][0] = floor((xblue/256)*Rblue)
        bitmap[xblue][yblue][1] = floor((xblue/256)*Gblue)
        bitmap[xblue][yblue][2] = floor((xblue/256)*Bblue)
Same for y-axis. You could even do the x and y-axis at the same time:

Code: [Select]

for y in range (256):
    for x in range (256):
        bitmap[x][y][0] = ( (y/256)*Rpink + (x/256)*Rblue )//2
        bitmap[x][y][1] = ( (y/256)*Gpink + (x/256)*Gblue )//2
        bitmap[x][y][2] = ( (y/256)*Bpink + (x/256)*Bblue )//2(Double check this, I haven't run it.)

[methylatedspirit]

Code: [Select]

for yblue in range (256):
    for xblue in range (256):
        bitmap[xblue][yblue][0] = floor((xblue/256)*Rblue)
        bitmap[xblue][yblue][1] = floor((xblue/256)*Gblue)
        bitmap[xblue][yblue][2] = floor((xblue/256)*Bblue)

Works exactly as expected. No errors here.

Same for y-axis. You could even do the x and y-axis at the same time:

Code: [Select]

for y in range (256):
    for x in range (256):
        bitmap[x][y][0] = ( (y/256)*Rpink + (x/256)*Rblue )//2
        bitmap[x][y][1] = ( (y/256)*Gpink + (x/256)*Gblue )//2
        bitmap[x][y][2] = ( (y/256)*Bpink + (x/256)*Bblue )//2(Double check this, I haven't run it.)

It works. Also, it turns out that you don't need to use floor() or integer division at all if you're using Pillow. It's perfectly able to handle floating-point numbers in its images. One catch: the RGB values must be in the interval [0,255], or stuff like this happens:

(remove the division by 2 when adding the RGB values together)

No saturation arithmetic here, no siree!

[methylatedspirit]

I've implemented the ghettoest version of saturating arithmetic possible (technically only saturating at 255 but not 0) in my program, and I get this unsightly blue line going through where it would overflow. Here's the current code for cycling through the colors:

Code: [Select]

# cycling through x-axis (black to blue) + cycling through y-axis (black to pink)
for x in range (256):
    for y in range (256):
        R = (y/256)*Rpink + (x/256)*Rblue
        G = (y/256)*Gpink + (x/256)*Gblue
        B =  (y/256)*Bpink + (x/256)*Bblue
        # Ghettoest way of doing saturated arithmetic
        if R > 255:
            R = 255
        if G > 255:
            G = 255
        if B > 255:
            B = 255
        bitmap[x][y][0] = R
        bitmap[x][y][1] = G
        bitmap[x][y][2] = B

And the output is mostly what I wanted, but there's a blue streak going from bottom-left to top-right:


I'm not quite sure what happened, but I wouldn't be surprised if this hack job of a way of doing saturating arithmetic is part of the problem.

[Bumber]

You can use "min" instead of the if statements:

Code: [Select]

bitmap[x][y][0] = min(R,255)
You wanted blue on the x-axis, right? You could swap (y/256) with (x/256). You could also check if there's a setting in the Pillow functions that draws the axes differently.

[methylatedspirit]

I mean, a swapped axis never hurt anybody. I can always go to Paint, then use the right combination of flip vertical/horizontal and rotates to get everything right again. The "blue line" problem... for the time being, I'll just do a blur on the whole image and no-one's the wiser. It's sidestepping the problem (thus, inelegant), but it's good enough for my purposes. Maybe. The perfectionist in me's yelling that it's not an ideal solution, but what do they know?

[McTraveller]

Re swapped axes:

In almost all computer programming languages, an array like:

Code: [Select]

array[i1][i2]

does not store data with i1 as the x axis and i2 as the y axis - storage is row-major, so the 'x' axis is the rightmost array index.  That is, array(row, col) is coded as array[ col][ row]. So you really just want:

Code: [Select]

bitmap[y][x]...

You don't have to change any other formulae.

EDIT because this was still the last post:

FOR THE LOVE OF ALL THAT IS HOLY PEOPLE, PLEASE DO NOT USE O(N^2) ALGORITHMS INSTEAD OF A DICTIONARY. ALSO, Please CACHE THE RESULTS of a search for "find all items of this type" on a STATIC ARRAY instead of performing the same search 1000 times....

[WealthyRadish]

I stumbled into some fun with nested and recursive C++ lambdas this morning, while looking for ways to avoid typing out pointer null checks on an ostream* pointer:

Code: [Select]

bool loadFile(const std::string& fname, std::ostream* errLog = nullptr) {

auto err = [errLog](const auto& first, auto&&... rest)->void {
auto err_impl = [errLog](auto& func, const auto& f, auto&&... r)->void {
*errLog << f;
if constexpr (sizeof...(r) > 0) {               
func(func, r...);
}
};
if (errLog) { err_impl(err_impl, first, rest...); }
};

std::string str = "(and bay12) ";

err("Hello error! ", str, 3.14, " 0x", std::hex, 123456789);

return true;
}


Code: [Select]

Hello error! (and bay12) 3.14 0x75bcd15


[methylatedspirit]

I feel this question straddles the line between the Generic Computer Advice Thread and this one. It's about a Python 3 script. It automates the tedious process of interpreting raw video data as audio to be encoded (step 1), decoding it back to a raw format (step 2), then putting it into a lossless video codec for later use (step 3). It's an odd thing to do, but it produces interesting results, I think. Without it, those are 3 long and error-prone commands in FFmpeg.

I want to ask about how to implement error checking in the arguments. Here are the instructions:

Code: [Select]

Usage: vid-autoencode [resolution] [framerate] [pixel format] [filename w/ extension] [audio codec] [bitrate]
I want it to expect the following things and warn (raise an exception(?) and ask Y/N to continue) if it's out of range:

[resolution] : string in format n + "x" + m. n, m are unsigned integers. Example: 1920x1080.
[framerate] : positive integer (yes, this completely ignores edge cases like NTSC framerate (29.97... FPS), but I'm not working with those things yet.)
[pixel_format] : matches a list of possible pixel formats (there are too many to count; I will not list them here)
[filename w/ extension]: has ".raw" at the end.
[audio codec]: matches a list of possible audio codecs (again, too many to count)
[bitrate]: either unsigned integer, or in the form n + "k", n being an unsigned integer. Examples: 128k, 48000.

What's the best way to do these checks?

Spoiler: The code (click to show/hide)

Code: (vid-autoencode) [Select]

import subprocess
import sys
import os

## This script assumes you have FFmpeg installed in PATH. If editing directly, you MUST encase all parameters in quotes, including the numbers.
## No error-correction done on variables; the whole script expects string type.
## You will need at least 2.5 times the size of the original video file free on disk. Be warned!
## Only accepts raw video files.


## Prints usage information if given no parameters.
print(sys.argv)
if len(sys.argv) == 1:
    print("Usage: vid-autoencode [resolution] [framerate] [pixel format] [filename w/ extension] [audio codec] [bitrate]\n")
    sys.exit()

## Variables

#### Step 1

in_filename = os.path.splitext(sys.argv[4])[0]
in_extension = os.path.splitext(sys.argv[4])[1]
step1_format = "u8"
step1_out_extension = ".mkv"

## While tempting, it is inadvisable to set sample_rate any higher than 48000.
## Opus only supports sampling rates of up to 48 KHz, for instance.
sample_rate = "48000"
audio_codec = sys.argv[5]
bitrate_codec = sys.argv[6]

#### Step 2
# (no new variables; all recycled from Step 1)

#### Step 3.
## File-specific parameters. Set these equal to the original video's settings.
resolution = sys.argv[1]
framerate = sys.argv[2]
pixel_format = sys.argv[3]

## Final video encoder.
out_vid_codec = "ffvhuff"

## Combined filenames. Used for brevity.
in_file = str(in_filename + in_extension)
step1_out = in_filename + "-" + audio_codec + "-" + bitrate_codec
step2_out = in_filename + "-conv-" + audio_codec + "-" + bitrate_codec
step3_out = in_filename + "-" + out_vid_codec + "-" + audio_codec + "-" + bitrate_codec

## Step 1: Interpret raw RGB 24-bit video as if it were signed 8-bit PCM. Converts to an audio codec.
## 8-bit PCM is mandatory; you WILL get psychedelic artifacts with any other format and a lossy codec.
## Or maybe you want that. The variable to change is "step1_format", but I will not be responsible for any seizures that may occur.
step1_list = ["ffmpeg","-y","-f", step1_format,"-ar",sample_rate,"-i",in_file,"-c:a",audio_codec,"-b:a",str(bitrate_codec),step1_out + step1_out_extension]
print(step1_list)
subprocess.run(step1_list)


## Step 2: Decode the encoded "audio" back into raw 8-bit PCM.
step2_list = ["ffmpeg","-y","-i",step1_out+step1_out_extension,"-f",step1_format,"-ar",sample_rate,step2_out + in_extension]
print(step2_list)
subprocess.run(step2_list)

## Step 3: Push our new raw video into video, encoding to a video codec of your choice.
## For best results, use a lossless codec. ffvhuff is used here, and you may need to modify the command to use different codecs like x264 and x265.
## That is left as an exercise for the reader.
step3_list = ["ffmpeg","-y","-f","rawvideo","-s",resolution,"-r",framerate,"-pix_fmt",pixel_format,"-i",step2_out + in_extension,"-c:v",out_vid_codec,step3_out + step1_out_extension]
print(step3_list)
subprocess.run(step3_list)


[MagmaMcFry]

Resolution:

Code: [Select]

import re
regex = re.compile("^(\d+)x(\d+)$")
match = regex.match(resolution_arg)
if match:
  width = int(match[1])
  height = int(match[2])
  # do stuff
else:
  # error handling

Framerate:

Code: [Select]

try
  framerate = int(framerate_arg)
  if framerate <= 0:
    raise ValueError()
  # do stuff
except ValueError:
  # error handling

Pixel format:

Code: [Select]

valid_pixel_formats = ["format1", "format2", "format3"]
if format_arg in valid_pixel_formats:

Filename w/ extension:

Code: [Select]

if filename_arg[-4:] == ".raw":

Audio codec:

Code: [Select]

valid_audio_codecs = ["codec1", "codec2", "codec3"]
if codec_arg in valid_audio_codecs:

Bitrate:

Code: [Select]

try:
  bitrate = 1
  if bitrate_arg[-1] == 'k':
    bitrate = 1000
    bitrate_arg = bitrate_arg[:-1]
  bitrate *= int(bitrate_arg)
  if bitrate < 0:
    raise ValueError()
  # do stuff
except ValueError:
  # error handling


[McTraveller]

Just started reading the Rust book...

Wow it's disappointing for trivial reasons.

Aside from a name that conjures images of corrosion, inconvenient syntax (immutable is default, which is far less common than mutable, so will require lots of extra typing). And whoever decided that .expect() is what you do when a call fails, which seems semantically backwards, since I don't expect failure...

The other recommended things are just not my preference (a pox on spaces recommended over tabs! and double pox on opening brace not on its own line!).

I also just can't get over dumb things like requiring cargo (WTF?) or TOML (really? it's called "Tom's Obvious Minimalist Language"?  Reeks of hubris...) 


EDIT: ok there are some neat features, the ownership model is, in fact, pretty cool. I like match too.  Some of the syntax is goofy though, and again, I think the hubris is high.  I think I've said before, I think the use of 'unsafe' is incorrect - it may not actually be unsafe code. I think 'unchecked' or something would be accurate but not imply something that may not be true.

[MorleyDev]

(immutable is default, which is far less common than mutable, so will require lots of extra typing).

I'd disagree with you here. 90% of software programming is sequential and doesn't require prior state changes for values. 90% of 'variable' assignment isn't to mutate the variable later, but to save on typing or recalculation. Immutable-by-default should be standard for modern languages, only gone against with good reason.

Unchecked code is unsafe because it's not checked. The language isn't protecting the programmer, ergo it's unsafe. Like driving a car without as seat belt. Sure, you probably won't crash. But it's still unsafe.

[Telgin]

I don't know anything about Rust, but I'll agree that const/immutable should probably be the default for variables in most languages going forward.  As I've been rebuilding an API at work to use ES6 JavaScript features, I've found surprisingly few variables that couldn't be made const.

Immutable variables also have an advantage over protecting the programmer from accidentally clobbering values they didn't mean to: in theory compilers can optimize generated code using constant variables better than those with mutable variables.  The specifics vary by language and probably aren't massive, but it's there.

[McTraveller]

The immutable thing - I might concede that point given the way you put it.  It could be that the domain in which I code firstly doesn't have dynamic memory allocation at all and variables are always "variable" - which is likely an artifact of architecture and program domain.   "Extra variables to save typing later" are not popular in my line of work due to execution time and memory limitations.  Maybe it's just because I don't like "immutable variable" (or "const variable") - because that just causes me mental dissonance.

I will argue vehemently though that is not what 'safety' means.  Safety isn't about "protecting the programmer", it's an attribute of the code behavior.  Since it's demonstrably possible to have code that behaves safely without checks, and since it's demonstrable that code that is written with strong language checks can be "unsafe" in the real world, calling it 'safe' and 'unsafe' is actually more dangerous than some other word; I would call it 'managed' and 'unmanaged'.  If you argue instead that the checks make it easier to write safe code, I would agree - but the checks don't make safe code.

[bloop_bleep]

The immutable thing - I might concede that point given the way you put it.  It could be that the domain in which I code firstly doesn't have dynamic memory allocation at all and variables are always "variable" - which is likely an artifact of architecture and program domain.   "Extra variables to save typing later" are not popular in my line of work due to execution time and memory limitations.  Maybe it's just because I don't like "immutable variable" (or "const variable") - because that just causes me mental dissonance.

I will argue vehemently though that is not what 'safety' means.  Safety isn't about "protecting the programmer", it's an attribute of the code behavior.  Since it's demonstrably possible to have code that behaves safely without checks, and since it's demonstrable that code that is written with strong language checks can be "unsafe" in the real world, calling it 'safe' and 'unsafe' is actually more dangerous than some other word; I would call it 'managed' and 'unmanaged'.  If you argue instead that the checks make it easier to write safe code, I would agree - but the checks don't make safe code.

The future is now, old man.

[MorleyDev]

'value' and 'mutable value' is probably a better term than "variable", you just tend to see them used interchangably nowadays because the name of 'variable' is a bit of a historical artefact. Scala literally use 'val' and 'var' for differentiating between their mutable and immutables (values and variables), although that's visually a bit too indistinct for my liking. Although syntax highlighting can help with that (make mutable variables bright and ugly, F# dark theme has them bright orange).

As for safe and unsafe, the terminology in how Rust is using it is from a language/runtime pov. From the pov of the runtime, the code is 'unsafe' since it's being ran without the checks and guarantees of the runtime but is instead dealing in raw memory pointers.

This is a different context of safe/unsafe than when talking about mathematically proved safety of code, hence the same terms being used for different meanings.

Since Rust is about taking the lessons from newer managed languages that make them more pleasent to work in, and then applying that to a systems language, it inhereted that terminology. This usage of unsafe isn't an invention of Rust, but rather an accepted and standard usage of the term within this context.